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

[hh3755]

大家好，最近做一个消息推送系统，批量推送到用户后，会有一个同时的大量拉取消息的行为，想法是做读写分离来支持瞬时较高并发。

实现时，从多个从库（只读）筛选出用户的消息，然后同时连主库（可写），更新对应消息的读取状态。这样就是在程序里同时配置两个数据库连接池，对此大家有什么更好的方案吗？

另外主库压力也不小。不知道大家有无相关经验分享。

[aru]

这部分用mongodb来做？

[zado]

用内存做缓存。

[zhicheng]

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

[virusdefender]

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

[hjxx]

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

[hh3755]

@aru
@zado

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

[invite]

写内存同步到数据库.

[zado]

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

[hh3755]

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

[hh3755]

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

[hh3755]

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

[zhicheng]

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