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

V2EX = way to explore

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

现在注册

已注册用户请登录

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

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

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

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

消息

方案

并发

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

aru

2015-01-17 22:10:09 +08:00

这部分用mongodb来做？

zado

2015-01-17 23:09:17 +08:00

用内存做缓存。

zhicheng

2015-01-17 23:11:44 +08:00

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

virusdefender

2015-01-17 23:25:33 +08:00

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

hjxx

2015-01-18 01:04:34 +08:00

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

hh3755

2015-01-18 10:03:12 +08:00

@aru
@zado

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

invite

2015-01-18 10:35:11 +08:00

写内存同步到数据库.

zado

2015-01-18 13:08:30 +08:00

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

hh3755

2015-01-18 20:43:39 +08:00

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

hh3755

2015-01-18 20:46:18 +08:00

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

hh3755

2015-01-18 20:50:29 +08:00

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

zhicheng

2015-01-18 21:02:37 +08:00

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