摘要：不管什么情况 ，都 需要一个标尺 来衡量时序的先后顺序，可以根据业务场景，以客户端或者服务端的时间为准，例如：
《架构师之路：架构设计中的100个知识点》
91.消息时序一致性
很多业务都需要考虑消息投递的顺序性：
1. 单聊 消息投递，保证 发送方发送顺序与接收方展现顺序一致；
2. 群聊 消息投递，保证所有 接收方展现顺序一致；
3. 充值支付消息 ，保证 同一个用户发起的请求在服务端执行序列一致；
消息顺序性是分布式系统架构设计中非常难的问题，有什么常见优化实践呢？
折衷一：以客户端或者服务端的时序为准。
不管什么情况 ，都 需要一个标尺 来衡量时序的先后顺序，可以根据业务场景，以客户端或者服务端的时间为准，例如：
邮件展示顺序，其实是以客户端发送时间为准的；画外音：发送方只要将邮件协议里的时间调整为1970年或者2970年，就可以在接收方收到邮件后一直“置顶”或者“置底”。
*
*
2. 秒杀活动时间判断，肯定得以服务器的时间为准，不可能让客户端修改本地时间，就能够提前秒杀；
折衷二：服务端生成单调递增 id 作为时序依据。
对于严格时序的业务场景 ，可以利用单点写 db 的 seq/auto_inc_id 生成单调递增的 id，来保证顺序性。
画外音：这个生成 id 的单点容易成为瓶颈。
折衷三：假如业务能接受误差不大的趋势递增 id。
消息发送、帖子发布时间、甚至秒杀时间都没有这么精准时序的要求：
同1s内发布的聊天消息时序乱了，没事；同1s内发布的帖子排序不对，没事；同1s内发起的秒杀，由于服务器多台之间时间有误差，落到A服务器的秒杀；成功了，落到B服务器的秒杀还没开始，业务上也是可以接受的（用户感知不到）所以，大部分业务，长时间趋势递增的时序就能够满足业务需求，非常短时间的时序误差一定程度上能够接受。
于是，可以使用分布式 id 生成算法来生成 id，作为时序依据。
折衷四：利用单点序列化，可以保证多机相同时序。
数据为了保证高可用，需要做到进行数据冗余，同一份数据存储在多个地方，怎么保证这些数据的修改消息是一致的呢？
先在一台机器上序列化操作；再将操作序列分发到所有的机器 ，以保证多机的操作序列是一致的，最终数据是一致的；典型场景一：数据库主从同步。
数据库的主从架构，上游分别发起了 op1,op2,op3三个操作，主库 master 来序列化所有的 SQL 写操作 op3,op1,op2，然后把相同的序列发送给从库 slave 执行，以保证所有数据库数据的一致性，就是利用“单点序列化”这个思路。
典型场景二：GFS 中文件的一致性。
GFS (Google File System) 为了保证文件的可用性，一份文件要存储多份，在多个上游对同一个文件进行写操作时，也是由一个主 chunk-server 先序列化写操作，再将序列化后的操作发送给其他 chunk-server，来保证冗余文件的数据一致性的。
单对单聊天，怎么保证发送顺序与接收顺序一致呢？
单人聊天的需求，发送方 A 依次发出了 msg1，msg2，msg3三个消息给接收方 B，这三条消息能否保证显示时序的一致性（发送与显示的顺序一致）？
方案设计思路如下：
如果利用 服务器单点序列化时序 ，可能出现服务端收到消息的时序为msg3，msg1，msg2，就会与发出序列不一致。业务上不需要全局消息一致，只需要 对于同一个发送方A，ta发给B的消息时序一致 ，常见优化方案，在A往B发出的消息中， 加上发送方A本地的一个绝对时序，来表示接收方B的展现时序。msg1{ sender:A, seq:10 , receiver:B, msg:content1}
msg2{ sender:A, seq:20 , receiver:B, msg:content2}
msg3{ sender:A, seq:30 , receiver:B, msg:content3}
可能存在问题是：如果接收方 B 先收到 msg3，msg3会先展现，后收到 msg1和 msg2后，会展现在 msg3的前面。
群聊消息，怎么保证各接收方收到顺序一致？
群聊消息的需求，N 个群友在一个群里聊，怎么保证所有群友收到的消息显示时序一致？
方案设计思路如下：
假设和单聊消息一样，利用发送方的seq来保证时序，因为发送方不单点，seq无法统一生成，可能存在不一致。画外音：发消息的是多个人，没法利用客户端 seq，必须使用服务端 seq。
于是，可以利用服务器的单点做序列化。如上图，此时群聊的发送流程为：
sender1发出msg1，sender2发出msg2；msg1和msg2经过接入集群，服务集群；service层到底层拿一个唯一seq，来确定接收方展示时序；service拿到msg2的seq是20，msg1的seq是30；通过投递服务将消息给多个群友，群友即使接收到msg1和msg2的时间不同，但可以统一按照seq来展现；这个方法能实现，所有群友的消息展示时序相同。
缺点是，生成全局递增序列号的服务很容易成为系统瓶颈。
还有没有进一步的优化方法呢？
群消息其实也不用保证全局消息序列有序，而 只要保证一个群内的消息有序即可 ，这样的话，“id 串行化”就成了一个很好的思路。
这个方案中，service 层不再需要去一个统一的后端拿全局 seq，而是在 service 连接池层面做细小的改造，保证一个群的消息落在同一个 service 上 ，这个 service 就可以用本地 seq 来序列化同一个群的所有消息，保证所有群友看到消息的时序是相同的。
画外音：连接池升级一个策略，由随机拿链接，升级为 gid 取模拿链接就可以了，修改非常简单。
此时利用 本地时钟 来生成 seq 就奏效了，是不是很巧妙？
总结
要“有序”，先得有 衡量“有序”的标尺 ，可以是客户端标尺，可以是服务端标尺；大部分业务能够接受大范围趋势有序，小范围误差 ；绝对有序的业务，可以借助服务器绝对时序的能力；单点序列化 ，是一种常见的保证多机时序统一的方法，典型场景有db主从一致，gfs多文件一致；单对单聊天，只需保证 发出的时序与接收的时序一致 ，可以利用客户端seq；群聊，只需保证 所有接收方消息时序一致 ，需要利用服务端seq，方法有两种，一种单点绝对时序，另一种id串行化；那么问题来了，明明技术上可以做到，那微信为什么没有实现，群消息接收展示时序的一致性呢？
答案只有一个，产品经理认为，没有必要！
知其然，知其所以然。
思路比结论更重要。
==全文完==
有架构合集吗？
合集一：《 流量从10万到10亿，一定会遇到的80个架构问题（8000字长文） 》
合集二：《 关于即时通讯架构的一切！》
画外音：职业生涯前5年，都在做 IM 架构。
有技术交流的社群吗？（免费）
有深度链接的社群吗？（付费）
欢迎深度链接，一起思考，一起进步
《 40岁，创业2个月了，人生总得做点啥... 》
社群一年至少50场活动，欢迎大家加入。
8月社群直播，程序员如何快速晋升 ，欢迎预约：
来源：墨码行者