任何脱离业务场景的架构设计都是耍流氓。
广义系统通知,有1对1的通知,以及一对多的通知,有相对实时的业务通知,以及能够容忍一定延时的系统通知。结合具体的场景来看下,这样的一些系统通知,究竟是推还是拉?
一、系统对1的通知
典型业务,计数类通知:
很多业务经常有这类计数通知,通知结果只针对你,这类通知是推送,还是拉取的呢?常见的有这样一些实践:
如果业务需求对计数需求需要实时展现,例如微博的加好友计数,假如希望实现不刷新网页,计数就实时变化:
int getCountByType(int countType)
int addCountByType(int countType, int diff)
这里的思路是,一开始得到初始值,后续推送增量值,由网页端计算最终计数并呈现最终结果。需要注意,针对不同业务,计数变化的差值可增可减。
上述方案的坏处是,一旦有消息丢失,网页端的计数会一直不一致,直至再次登录重新初始化计数。这个计算计数可以优化为在服务器直接计算并通知网页端最终的结果,网页端只负责呈现即可,这样网页端的逻辑会变轻。
如果业务对此类通知的展现不需要这么实时,完全可以通过拉取:
int getCountByType(int countType)
这样系统的实现会最简单。需要注意,通知拉取要异步,不要影响主页面的快速返回。
系统对1的推送,例如针对1个用户的业务计数推送,计数的变化频率其实非常低,使用cache来存储这些计数能够极大提升系统性能。
更多计数系统架构实践可详见《计数系统架构实践一次搞定》。
二、系统对多的通知
系统对多的通知消息,会比系统对1的通知消息复杂一些,以两个场景为例:
IM登录弹窗新闻
这个通知的需求是:
不妨设有一个表存放弹窗新闻:
t_msg(msg_id, date, msg_content)
有一个表来存放用户信息:
t_user(user_id, user_info, …)
有一个表来存放用户收到的新闻弹窗:
t_user_msg(user_id, msg_id, date)
这里的实现明显不能采用推送的方式:
这个笨拙的方式,会导致t_user_msg里有大量的脏数据,毕竟大部分用户并不会登录。
如果改为拉取的方式会好很多:
这个方式虽然有所优化,但t_user_msg的数据量依然很大。
还有一种巧妙的方式,去除t_user_msg表,改为在t_user表加一列,表示用户最近拉取的弹窗时间:
t_user(user_id, user_info, last_msg_date, …)
这样业务流程会升级为:
这种方式不再存储消息与用户的笛卡尔关系,数据量会大大减少,是不是有点意思?
IM右下角弹窗广告
这个通知的需求是:
画外音:如果1个推送一块钱,5KW用户推送收入就有5KW收入哟,一天推个几次,实现1个亿的小目标居然如此简单。
最直观的感受,这是一个for循环批量推送的过程。如果是推送,必须要考虑的问题是,推送限速控制,避免短时间内对系统造成冲击,引发雪崩。
能不能用拉取呢?
完全可以,这是一个对实时性要求不太高的场景,用户早1分钟晚1分钟收到这个广告影响不大,其实可以借助IM原本已有的keepalive请求,在请求返回时,告之“有消息拉取”,然后采用拉取的方式拉取广告消息。
这个方案的好处是,由于5KW在线用户的keepalive请求是均匀的,所以可以很均匀的将广告拉取的请求同样均匀的分散到一段时间内,避免5KW集中推送对系统造成冲击。
三、总结
广义系统通知,究竟是推送还是拉取呢?不同业务,不同需求,实现方式不同。
系统对1的通知:
系统对N的通知:
系统通知究竟是推还是拉,是一个相对比较简单的场景。对于feed流,单聊群聊,状态同步会更为复杂,这些场景,下期分解。