系统通知，居然用拉取？

广义系统通知，有1对1的通知，以及一对多的通知，有相对实时的业务通知，也有能够容忍一定延时的系统通知。任何脱离业务场景的架构设计都是耍流氓，结合具体的场景来看下，这样的一些系统通知，究竟是推还是拉？

第一大类：系统对1的通知

典型业务，计数类通知：

（1）有10个美女添加了你为好友；

（2）有8个好友私信了你；

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

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

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

int getCountByType(int countType)

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

int addCountByType(int countType, int diff)

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

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

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

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

int getCountByType(int countType)

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

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

第二大类：系统对多的通知

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

（1）QQ登录弹窗新闻；

（2）QQ右下角弹窗广告；

先说IM登录弹窗新闻。

这个通知的需求是：

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

（2）每天第一次登录弹出新闻，当天的后续登录不出新闻；

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

t_msg(msg_id, date, msg_content)

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

t_user(user_id, user_info, …)

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

t_user_msg(user_id, msg_id, date)

这里的实现明显不能采用推送的方式：

（1）将t_user_msg里对于所有user_id推送插入一个msg_id，表示未读；

（2）在user每天第一次登录的时候，将当天的msg_id拉取出来，并删除，表示已读；

（3）在user每天非第一次登录的时候，就拉取不到msg_id于是不会再次弹窗；

这个笨拙的方式，会导致t_user_msg里有大量的脏数据，毕竟大部分用户并不会登录。

如果改为拉取的方式会好很多：

（1）在user每天第一次登陆时，将当天的msg_id拉取出来，并插入t_user_msg，表示已读；

（2）在user每天非第一次登陆时，则会插入t_user_msg失败，则说明已读，不再进行二次弹窗展现；

这个方式虽然有所优化，但t_user_msg的数据量依然很大。

还有一种巧妙的方式，去除t_user_msg表，改为在t_user表加一列，表示用户最近拉取的弹窗时间：

t_user(user_id, user_info, last_msg_date, …)

这样业务流程会升级为：

（1）在user每天第一次登录时，将当天的msg_id拉取出来，并将last_msg_date修改为今天；

（2）在user每天非第一次登录时，发现last_msg_date为今天，则说明今天已读；

这种方式不再存储消息与用户的笛卡尔关系，数据量会大大减少，是不是有点意思？

再说IM右下角弹窗广告。

这个通知的需求是：

（1）每天会对一批在线用户推送相同的弹窗TIPS广告，例如球鞋广告，手机广告等；

画外音：如果1个推送一块钱，5KW用户推送收入就有5KW收入哟，一天推个几次，实现1个亿的小目标居然如此简单。

最直观的感受，这是一个for循环批量推送的过程。如果是推送，必须要考虑的问题是，推送限速控制，避免短时间内对系统造成冲击，引发雪崩。

能不能用拉取呢？

完全可以，这是一个对实时性要求不太高的场景，用户早1分钟晚1分钟收到这个广告影响不大，其实可以借助IM原本已有的keepalive请求，在请求返回时，告之“有消息拉取”，然后采用拉取的方式拉取广告消息。

这个方案的好处是，由于5KW在线用户的keepalive请求是均匀的，所以可以很均匀的将广告拉取的请求同样均匀的分散到一段时间内，避免5KW集中推送对系统造成冲击。

总结

广义系统通知，究竟是推送还是拉取呢？不同业务，不同需求，实现方式不同。

系统对1的通知：

（1）实时性要求高，可以推送；

（2）实时性要求低，可以拉取；

系统对N的通知：

（1）登录弹窗新闻，拉取更佳，可以用一个last_msg_date来避免大量数据的存储；

（2）批量弹窗广告，常见的方法是推送，需要注意限速，也可以拉取，以实现请求的均匀分散；

学习，永无止境，希望大家有收获。

发布者：糖太宗，转载请注明出处：https://www.qztxs.com/archives/science/technology/6784

翁全强 2023年5月22日

我有美国1991年1元硬币，香港1997年10毫硬币，还有这个新加坡10毫硬币

评论于 2023年一分二分五分旧钱币回收价目表
苹果 2023年4月22日

我地处湖北潜江，去年十一月加入了易邮驿站，至今半年过去了，没有一家快递对接过来，没收到一个件。心里堵得慌，感觉自己走进了泥潭，交费加入后，他们是寄了一些资料和快递所用物件过来，诸如使用软件、视频头、台秤，贴单打印机，工作服，宣传海报，货架标签。可是有什么用呢，之前说的可以对接的八大家呢？一个货也对接…

评论于易邮站真实可靠吗？ Easy Post Post 是官方的吗？ Easy Post是骗子吗？
阿文 2023年3月15日

这个确定了是骗子行为，账号如果发展人多了，会给你封掉，要不就是给你标记为违规，骗你联系客服然后就让你提供各种东西信息后给你封禁账号

评论于乌托邦矿业是骗局吗？
ww 2023年3月9日

你这个dom型跨站脚本能不详细点？

评论于 AWVS漏洞复现小记
做好事不留名 2023年2月16日

贝复新药盒上面扫码就能买，很方便的

评论于贝复新能否修复受损的皮肤屏障？

系统通知，居然用拉取？

发表回复

联系我们

400-800-8888

系统通知，居然用拉取？

相关推荐

Docker 搭建Redis集群环境

WINSpect-基于Powershell的Windows安全审计工具

QT 连接MySQL数据库打不开

求解“微信群覆盖”的三种方法：暴力，染色，链表，并查集(文章没火，你有责任)

App反编译工具dex2jar、JD-GUI的使用

发表回复

联系我们

400-800-8888