http://www.52im.net/thread-294-1-1.html
13、总结
1)im系统是通过超时、重传、确认、去重的机制来保证消息的可靠投递,不丢不重;
2)切记,一个“你好”的发送,包含上半场msg:R/A/N与下半场ack:R/A/N的6个报文。
个人消息是一个1对1的ack,群消息就没有这么简单了,群消息存在一个扩散系数,im群消息的可靠投递问题感兴趣的可查阅相关资料。
正如本文中所列举的问题所描述的那样,保证“离线消息”的可达性比大家想象的要复杂一些,常见优化总结如下:
1)对于同一个用户B,一次性拉取所有用户发给ta的离线消息,再在客户端本地进行发送方分析,相比按照发送方一个个进行消息拉取,能大大减少服务器交互次数;
2)分页拉取,先拉取计数再按需拉取,是无线端的常见优化;
3)应用层的ACK,应用层的去重,才能保证离线消息的不丢不重;
4)下一页的拉取,同时作为上一页的ACK,能够极大减少与服务器的交互次数。
我们都知道,一个典型的分布式系统中,很多业务场景都需要考虑消息投递的时序,例如:
IM中单聊消息投递:保证发送方发送顺序与接收方展现顺序一致;
IM中群聊消息投递:保证所有接收方展现顺序一致;
电商充值支付消息:保证同一个用户发起的请求在服务端执行序列一致。
5、本文小结
1)分布式环境下,消息的有序性是很难的,原因多种多样:时钟不一致,多发送方,多接收方,多线程,网络传输不确定性等;
2)要“有序”,先得有衡量“有序”的标尺,可以是客户端标尺,可以是服务端标尺;
3)大部分业务能够接受大范围趋势有序,小范围误差;绝对有序的业务,可以借助服务器绝对时序的能力;
4)单点序列化,是一种常见的保证多机时序统一的方法,典型场景有db主从一致,gfs多文件一致;
5)单对单聊天,只需保证发出的时序与接收的时序一致,可以利用客户端seq;
6)群聊,只需保证所有接收方消息时序一致,需要利用服务端seq,方法有两种,一种单点绝对时序,另一种id串行化。
个人建议的方式是:
好友状态,如果对实时性要求较高,可以采用推送的方式同步;如果实时性要求不高,可以采用轮询拉取的方式同步;
群友的状态,由于消息风暴扩散系数过大,可以采用按需拉取,延时拉取的方式同步;
系统消息/开屏广告等对实时性要求不高的业务,可以采用拉取的方式获取消息;
“消息风暴扩散系数”是指一个消息发出时,变成N个消息的扩散系数,这个系数与业务及数据相关,一定程度上它的大小决定了技术采用推送还是拉取。
8、本文小结
群消息还是非常有意思的,可达性、实时性、离线消息、消息风暴扩散等等等等,做个总结:
1)不管是群在线消息,还是群离线消息,应用层的ACK是可达性的保障;
2)群消息只存一份,不用为每个用户存储离线群msg_id,只需存储一个最近ack的群消息id/time;
3)为了减少消息风暴,可以批量ACK;
4)如果收到重复消息,需要msg_id去重,让用户无感知;
5)离线消息过多,可以分页拉取(按需拉取)优化。
网友评论