nodejs

做聊天室需要抗住大量的写操作，想用 redis 但是，redis 能抗住吗？写的性能如何？另外 redis 是内存数据库，如果数据量大了，有必要把那些不活跃的数据载入内存吗？有啥好的方案

聊天室又不保存大量数据，需要抗住什么写操作？需要抗住的是大量广播消息以及很多长连接。nodejs 应该可以承受得住。并且聊天室是分房间的，比较容易 scale，以及可以做收发分离的 scale，应该问题不大。

我关心的是，就算你做出来了，你上什么地方去找这么多的用户？

#3 楼 @linjunhalida 可能我们不是那种广义的聊天室。。是那种类似论坛的形式，几个人聊一个主题，聊天记录需要持久化。

#4 楼 @lgn21st 暂时关心架构上的问题。。感觉把所有聊天记录放 redis 里不太合理

有时候在想用 mongodb 是不是会合适，不是很熟悉，另外用 mongodb，还得加个缓存之类。。

当前重点问题就 2 个，高并发写怎么抗住比较合适（可能需要分片），和如何做持久化。。

另外，什么样的场景适合完全使用 redis。网站初期？要么数据量大了，不活跃数据放里面太不合适了吧

从哪里能看出高并发

可能大量的用户会同时写消息。感觉有点类似 twitter 了？

就目前看来，redis 还是更适合做缓存而已。。

聊天室就是一个队列 + 广播，没有那么复杂吧。写数据的时候就异步丢传统数据库，保留部分热数据，需要查询旧数据的时候就去 hit 传统的。热点都在最新的数据上面，有个别用户翻垃圾的话就让他传统数据库慢慢查吧。

用了再改，改了再用，周而复此！等考虑完了，都做出来了，用自己最方便最熟悉的开始！

恩，先做起来再说。通常以前我们使用缓存和 DB 的思想可能是先更新 DB，再更新缓存，或者直接让缓存失效。最近听过现在有些架构的思想是，先更新缓存，再更新 DB。那么具体操作是怎样的呢？比如用 redis+mysql 1）对于新数据的策略是，直接插入 DB，再更新到缓存？

2）对于缓存中有的数据的策略是，先更新缓存，再异步写到 DB。

以上方案怎么避免单点故障防止写入了缓存没同步到 DB？通过 LOG 还是？怎么处理事务