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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 4013 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

消息

方案

并发

12 条回复 • 2015-01-18 21:02:37 +08:00

aru

2015 年 1 月 17 日

这部分用mongodb来做？

zado

2015 年 1 月 17 日

用内存做缓存。

zhicheng

2015 年 1 月 17 日

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

virusdefender

2015 年 1 月 17 日

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

hjxx

2015 年 1 月 18 日

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

hh3755

2015 年 1 月 18 日

@aru
@zado

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

invite

2015 年 1 月 18 日

写内存同步到数据库.

zado

2015 年 1 月 18 日

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

hh3755

2015 年 1 月 18 日

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

hh3755

2015 年 1 月 18 日

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

hh3755

2015 年 1 月 18 日

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

zhicheng

2015 年 1 月 18 日

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