Rails 如果要做一个并发量比较高的聊天室,大家会设计怎样的方案?

ihlayy · 2012年11月28日 · 最后由 ihlayy 回复于 2012年12月01日 · 7606 次阅读

如果要做一个并发量比较高的聊天室,大家会设计怎样的方案?

聊天记录要求持久化

做聊天室需要抗住大量的写操作,想用 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 还是? 怎么处理事务

需要 登录 后方可回复, 如果你还没有账号请 注册新账号