所谓的同等性，在IM中常日指的是时序的同等性，那便是：
1）谈天的高下文连续性；
2）谈天的绝对韶光序。
再详细一点，IM的同等性表示在：
1）单聊时：要担保发送方发出谈天的顺序与吸收方看到的顺序同等；
2）群聊时：要担保所有群员看到的谈天，与发送者发出时的绝对韶光序是同等的。
IM系统中时序的同等性问题是个看似大略，实则非常有难度的技能热点话题之一，本文只管即便以普通简显的笔墨为你讲解IM时序同等性问题的产品意义、发生缘故原由、办理思路等。
学习互换：
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK
（本文同步发布于：http://www.52im.net/thread-3189-1-1.html）
2、系列文章《零根本IM开拓入门(一)：什么是IM系统？》
《零根本IM开拓入门(二)：什么是IM系统的实时性？》
《零根本IM开拓入门(三)：什么是IM系统的可靠性？》
《零根本IM开拓入门(四)：什么是IM系统的时序同等性？》（ 本文）
《零根本IM开拓入门(五)：什么是IM系统的安全性？ (稍后发布)》
《零根本IM开拓入门(六)：什么是IM系统的的心跳机制？ (稍后发布)》
《零根本IM开拓入门(七)：如何理解并实现IM系统未读数？ (稍后发布)》
《零根本IM开拓入门(八)：如何理解并实现IM系统的多端漫游？ (稍后发布)》
3、时序的同等性，对付IM的意义现如今，由于移动互联网的遍及，当代人的实际社交关系，险些完备是靠IM这种即时通讯社交工具所组织起来的，IM这种工具的主要性不言而喻。
IM在当代人的生活中，越来越主要，但也越来平常。现在想联系一个人，第一韶光想到的不是打个电话，而是发个“微信”或“QQ”。是的，IM这玩意承载的意义越来越多。
时序的同等性问题，对付IM的意义，毫无疑问带来的不但是简大略单的所谓用户体验问题。我们来看看例子。
假设：你跟女神的表白正进入到关键阶段，聊着聊着就由于这烂IM，导致谈天序言不搭后语，此刻1000公里外你的女神真一脸蒙逼的盯动手机看你的“醉话”，后果是多么严重——这半年来的“舔狗”生活、忍辱负重，算是白白被程序员这群“格子衫”、“地中海”们给祸害了。
再往严重了说，就由于这烂IM，让你失落去了这难得的借助女神优秀基因，改造家族后代颜值的绝佳机会，无不让人咬牙切齿。。。
上面这个例子，说的还只是单聊，如果是群聊，则问题可能还会被无限放大：试想一个技能互换群，正在激烈的争吵着“php是天下最好措辞”这种话题的时候，忽然就想砸手机了，不是由于吵的太凶，而由于顺序全乱完备没法看，已经严重影响键盘侠们积极揭橥个人见地了。
4、凭什么说担保时序的同等性很困难？4.1 基本认知
在普通IM用户的眼里，无非是从一台手机通报到另一台手机而已，担保时序有何困难？
是的，普通用户这么认为，从技能上讲，他只是纯挚的将IM的收发过程理解为单线程的事情模式而已。
实际上，在IM这种高性能场景下，做事端为了追求高吞吐、高并发，用到了多线程、异步IO等等技能。
在这种情形下，“高并发”与“顺序”对付IM做事端来说，本来便是抵牾的，这就有点鱼与熊掌的味道了（两者很难兼得）。
以是，要实现IM场景下的时序同等性，须要做出权衡，而且要考虑的技能维度相称多。这就导致详细技能履行起来没有固定的套路，而由于开拓者技能能力的参差不齐，也就使得很多IM系统在实际的效果上会有较大问题，对付用户而言也将直接在产品体验上反应出来。
下面将详细解释技能难点所在。
4.2 没有全局时钟如上图所示，一个真正堪用的生产系统，显示不可能所有做事都跑在一台做事器上，分布式环境是肯定的。
那么：在分布式环境下，客户端+做事端后台的各种后台做事，都各自分布在不同的机器上，机器之间都是利用确当地时钟，没有一个所谓的“全局时钟”（也没办法做到真正的全局时钟），那么所谓的时序也就没有真正意义上的时序基准点。以是时序问题显然不是“本地韶光”可以完备决定的。
4.3 多发送方问题做事端分布式的情形下，不能用“本地韶光”来担保时序性，那么能否用吸收方本地韶光表示时序呢？
遗憾的是，由于多个客户真个存在（比如群聊时），纵然是一台做事器确当地韶光，也无法表示“绝对时序”。
如上图所示：绝对时序上，APP1先发出msg1，APP2后发出msg2，都发往做事器web1，网络传输是不能担保msg1一定先于msg2到达的，以是纵然以一台做事器web1的韶光为准，也不能精准描述msg1与msg2的绝对时序。
4.4 多吸收方问题多发送方不能担保时序，假设只有一个发送方，能否用发送方确当地韶光表示时序呢？遗憾的是，由于多个吸收方的存在，无法用发送方确当地韶光，表示“绝对时序”。
如上图，绝对时序上，web1先发出msg1，后发出msg2，由于网络传输及多吸收方的存在，无法担保msg1先被吸收到先被处理，故也无法担保msg1与msg2的处理时序。
4.5 网络传输与多线程问题既然多发送方与多吸收方都难以担保绝对时序，那么假设只有单一的发送方与单一的吸收方，能否担保的绝对时序同等性呢？
结论是悲观的，由于网络传输与多线程的存在，这仍旧弗成。
如上图所示，web1先发出msg1、后发出msg2，纵然msg1先到达（网络传输实在还不能担保msg1先到达），由于多线程的存在，也不能担保msg1先被处理完。
5、如何担保绝对的时序同等性？通过上一章内容的总结，我们已经对IM中时序同等性问题所产生的缘由，有了较为深刻的认识。
从纯技能的角度来说，假设：
1）只有一个发送方；
2）一个吸收方；
3）高下游连接只有一条socket连接；
4）通过壅塞的办法通讯。
这样的情形下，难道不能担保先发出的被先处理，进而被先展示给的吸收者吗？
是的，可以！
但实际生产情形下不太可能涌现这种IM系统，必竟单发送方、单吸收方、单socket连接、壅塞办法，这样的IM一旦做出来，产品经理会立马去世给你看。。。
6、实用的优化思路6.1 一对一单聊的同等性担保思路假设两人一对一谈天，发送方A依次发出了msg1、msg2、msg3三条给吸收方B，这三条该怎么担保显示时序的同等性（发送与显示的顺序同等）？
我们知道，发送方A依次发出的msg1、msg2、msg3三条，到底做事端后，再由做事端中转发出时，这个顺序由于多线程的网络的问题，是有可能乱序的。
那么结果就可能是这样：
如上图所示，会涌现与发出时的时序不一致问题（收到的顺序是：msg3、msg1、msg2）。
不过，实际上一对一谈天的两个人，并不须要全局时序的同等（由于谈天只在两人的同一会话在发生），只须要对付同一个发送方A，发给B的时序同等就行了。
常见优化方案，在A往B发出的中，加上发送方A本地的一个绝对时序（比如本机韶光戳），来表示吸收方B的展现时序。
那么当吸收方B收到后，纵然极度情形下可能存在乱序到达，但由于这个乱序的韶光差对付普通用户来说体感是很短的，在UI展现层按照中自带的绝对时序排个序后再显示，用户实在是没有太多感知的。
6.2 多对多群聊的同等性担保思路假设N个群友在一个IM群里谈天，该当若何担保所有群员收到的显示时序同等性呢？
首先：不能像一对谈天那样利用发送方的绝对时序来担保顺序，由于群聊发送方不单点，韶光也不一致。
或许：我们可以利用做事器的单点做序列化。
如上图所示，此时IM群聊的发送流程为：
1）sender1发出msg1，sender2发出msg2；
2）msg1和msg2经由接入集群，做事集群；
3）service层到底层拿一个唯一seq，来确定吸收方展示时序；
4）service拿到msg2的seq是20，msg1的seq是30；
5）通过投递做事讲给多个群友，群友纵然吸收到msg1和msg2的韶光不同，但可以统一按照seq来展现。
这个方法：
1）优点是：能实现所有群友的展示时序相同；
2）缺陷是：这个天生全局递增序列号的做事很随意马虎成为系统瓶颈。
还有没有进一步的优化方法呢？
从技能角度看：群实在也不用担保全局序列有序，而只要担保一个群内的有序即可，这样的话，“id序列化”就成了一个很好的思路。
上图这个方案中，service层不再须要去一个统一的后端拿全局seq（序列号），而是在service连接池层面做眇小的改造，担保一个群的落在同一个service上，这个service就可以用本地seq来序列化同一个群的所有，担保所有群友看到的时序是相同的。
关于IM的系统架构下利用怎么样实现序列化，或者说全局ID的天生方案，这又是另一个很热门的技能话题。
有兴趣，可以深入阅读下面这个系列：
《IMID技能专题(一)：微信的海量IM谈天序列号天生实践（算法事理篇）》
《IMID技能专题(二)：微信的海量IM谈天序列号天生实践（容灾方案篇）》
《IMID技能专题(三)：解密融云IM产品的谈天ID天生策略》
《IMID技能专题(四)：深度解密美团的分布式ID天生算法》
《IMID技能专题(五)：开源分布式ID天生器UidGenerator的技能实现》
《IMID技能专题(六)：深度解密滴滴的高性能ID天生器(Tinyid)》
这个系列中，尤其微信的趋势递增ID天生思路（把稳：趋势递增不是严格递增，趋势递增意味着中问有ID被跳过也没事），对付分布式IM的ID来说是非常切实可行的。
是的，对付IM系统来说，绝对意义上的时序很难担保，但通过做事端天生的单调递增ID的办法，利用递增ID来担保时序性，也是一个很可性的方案。
7、小结一下IM系统架构下，的绝对时序是很困难的，缘故原由多种多样，比如：没有全局时钟、多发送方、多吸收方、多线程、网络传输不愿定性等。
一对一单聊时，实在只须要担保发出的时序与吸收的时序同等，就基本能让用户觉得不到乱序了。
多对多的群聊情形下，担保同一群内的所有吸收方时序同等，也就能让用户觉得不到乱序了，方法有两种，一种单点绝对时序，另一种实现id的序列化（也便是实现一种全局递增ID）。
8、参考资料[1] 如何担保IM实时的“时序性”与“同等性”？，作者：沈剑
[2] 一个低本钱确保IM时序的方法磋商，作者：封宇
附录：更多IM开拓热门技能点《移动端IM开拓者必读(一)：普通易懂，理解移动网络的“弱”和“慢”》
《移动端IM开拓者必读(二)：史上最全移动弱网络优化方法总结》
《当代移动端网络短连接的优化手段总结：要求速率、弱网适应、安全保障》
《移动端IM中大规模群的推送如何担保效率、实时性？》
《移动端IM开拓须要面对的技能问题》
《开拓IM是自己设计协议用字节流好还是字符流好？》
《叨教有人知道语音留言谈天的主流实现办法吗？》
《如何担保IM实时的“时序性”与“同等性”？》
《一个低本钱确保IM时序的方法磋商》
《IM单聊和群聊中的在线状态同步该当用“推”还是“拉”？》
《IM群聊如此繁芜，如何担保不丢不重？》
《谈谈移动端 IM 开拓中登录要求的优化》
《移动端IM登录时拉取数据如何作到省流量？》
《浅谈移动端IM的多点登录和漫游事理》
《完备自已开拓的IM该如何设计“失落败重试”机制？》
《微信对网络影响的技能试验及剖析（论文全文）》
《IM开拓根本知识补课(五)：普通易懂，精确理解并用好MQ行列步队》
《微信技能分享：微信的海量IM谈天序列号天生实践（算法事理篇）》
《IM开拓根本知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！
》
《IM里“附近的人”功能实现事理是什么？如何高效率地实现它？》
《IM的扫码登录功能如何实现？一文搞懂主流运用的扫码登录技能事理》
《IM开拓宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》
本文已同步发布于“即时通讯技能圈”"大众号。
（同步发布链接：：http://www.52im.net/thread-3189-1-1.html）
