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）离线消息过多，可以分页拉取（按需拉取）优化。
