大量的消息拉取并发方案讨论

这部分用mongodb来做？

用内存做缓存。

静态化，并使用 hash 做多机分布。

这个使用缓存比较好吧，比如 redis，然后高峰期过后统一写入数据库。

热点公共数据 上缓存 不用每次去库里查询

@aru
@zado

你们两位都是说的是指将现在的从库（只读库）用内存缓存的方式来实现吧，不知有没理解错。但是对于主库的写压力有什么好的建议吗，因为比如一些群推消息，会记录某某用户已经拿过，这时会有一些写入，而且需同步，因为要避免同一用户拿到两次数据。

写内存同步到数据库.

读写都用内存去做，不存在同步的问题。需要持久保存的数据，有空的时候再慢慢写到数据库里面去。

@zado 但是用内存。如果程序挂了。不能从内存中恢复，一些状态丢失了，尤其是一些写的状态丢失了，会给人感觉程序很不稳定。

@zhicheng 静态化是指将什么静态化呢，是指将数据hash到不同数据库吗。但是hash有个不好的地方，一旦做调整就很麻烦。

@virusdefender 对此有成熟的框架或项目可以参考吗。
@hjxx 对更新有何建议。就是更新消息读取状态这种写操作。看大家都建议写操作也写内存。

@hh3755 如果是广播类的消息，随机分布就可以了。
如果是指定 client 的消息，那每个 client id ，相当于一个 subdomain 。在 DNS 层用 hash 做分布确保一个 id 永远分配到同一个机器。这样写和读对 publisher 和 consumer 就是透明的。
静态化指的是，对于推送的消息，一般没有修改的需求，可以根据 client id 直接把消息存文件。
只要能够实现得好，几十亿几百亿几万亿的消息系统都能做出来。