IM 架构设计03 读扩散 && 写扩散

https://blog.csdn.net/z50L2O08e2u4afToR9A/article/details/86746814

https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961230&idx=1&sn=b2ab831a72f54950498d43ac01e26453&chksm=bd2d02528a5a8b444050c242729f764d6435185feb015f81631d75b018b9760b1a90a467e817&scene=21#wechat_redirect

系统通知，究竟是推送还是拉取？

任何脱离业务场景的架构设计都是耍流氓。

 

广义系统通知，有1对1的通知，以及一对多的通知，有相对实时的业务通知，以及能够容忍一定延时的系统通知。结合具体的场景来看下，这样的一些系统通知，究竟是推还是拉？

 

一、系统对1的通知

典型业务，计数类通知：

• 有10个美女添加了你为好友

• 有8个好友私信了你

很多业务经常有这类计数通知，通知结果只针对你，这类通知是推送，还是拉取的呢？常见的有这样一些实践：

 

如果业务需求对计数需求需要实时展现，例如微博的加好友计数，假如希望实现不刷新网页，计数就实时变化：

• 登录微博时，会有一个计数的拉取，对网页端的计数进行初始化

int getCountByType(int countType)

• 在浏览微博的过程中，一旦有人加你为好友，服务端对网页端进行实时推送，告之增加了1个（或者N个）好友

int addCountByType(int countType, int diff)

这里的思路是，一开始得到初始值，后续推送增量值，由网页端计算最终计数并呈现最终结果。需要注意，针对不同业务，计数变化的差值可增可减。

 

上述方案的坏处是，一旦有消息丢失，网页端的计数会一直不一致，直至再次登录重新初始化计数。这个计算计数可以优化为在服务器直接计算并通知网页端最终的结果，网页端只负责呈现即可，这样网页端的逻辑会变轻。

 

如果业务对此类通知的展现不需要这么实时，完全可以通过拉取：

• 只有在链接跳转，或者刷新网页时，才重新拉取最新的通知，例如上述计数

int getCountByType(int countType)

这样系统的实现会最简单。需要注意，通知拉取要异步，不要影响主页面的快速返回。

 

系统对1的推送，例如针对1个用户的业务计数推送，计数的变化频率其实非常低，使用cache来存储这些计数能够极大提升系统性能。

更多计数系统架构实践可详见《计数系统架构实践一次搞定》。

 

二、系统对多的通知

系统对多的通知消息，会比系统对1的通知消息复杂一些，以两个场景为例：

• QQ登录弹窗新闻

• QQ右下角弹窗广告

 

IM登录弹窗新闻

这个通知的需求是：

• 同一天，用户登录弹出的新闻是相同的（很多业务符合这样的场景），不同天新闻则不一样（但所有用户都一样）

• 每天第一次登录弹出新闻，当天的后续登录不出新闻

 

不妨设有一个表存放弹窗新闻：

t_msg(msg_id, date, msg_content)

有一个表来存放用户信息：

t_user(user_id, user_info, …)

有一个表来存放用户收到的新闻弹窗：

t_user_msg(user_id, msg_id, date)

 

这里的实现明显不能