消息顺序性，究竟为什么这么难？

,​很多业务都需要考虑消息投递的顺序性：,消息顺序性是分布式系统架构设计中非常难的问题，有什么常见优化实践呢？,不管什么情况，都需要一个标尺来衡量时序的先后顺序，可以根据业务场景，以客户端或者服务端的时间为准，例如：,(1) 邮件展示顺序，其实是以客户端发送时间为准的；,画外音：发送方只要将邮件协议里的时间调整为1970年或者2970年，就可以在接收方收到邮件后一直“置顶”或者“置底”。,(2) 秒杀活动时间判断，肯定得以服务器的时间为准，不可能让客户端修改本地时间，就能够提前秒杀；,对于严格时序的业务场景，可以利用单点写db的seq/auto_inc_id生成单调递增的id，来保证顺序性。,画外音：这个生成id的单点容易成为瓶颈。,消息发送、帖子发布时间、甚至秒杀时间都没有这么精准时序的要求：,所以，大部分业务，长时间趋势递增的时序就能够满足业务需求，非常短时间的时序误差一定程度上能够接受。,于是，可以使用分布式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，这三条消息能否保证显示时序的一致性（发送与显示的顺序一致）？,方案设计思路如下：,,可能存在问题是：如果接收方B先收到msg3，msg3会先展现，后收到msg1和msg2后，会展现在msg3的前面。,群聊消息的需求，N个群友在一个群里聊，怎么保证所有群友收到的消息显示时序一致？,方案设计思路如下：,,如上图，此时群聊的发送流程为：,这个方法能实现，所有群友的消息展示时序相同。,缺点是，生成全局递增序列号的服务很容易成为系统瓶颈。,群消息其实也不用保证全局消息序列有序，而只要保证一个群内的消息有序即可，这样的话，“id串行化”就成了一个很好的思路。,,这个方案中，service层不再需要去一个统一的后端拿全局seq，而是在service连接池层面做细小的改造，保证一个群的消息落在同一个service上，这个service就可以用本地seq来序列化同一个群的所有消息，保证所有群友看到消息的时序是相同的。,此时利用本地时钟来生成seq就凑效了，是不是很巧妙？,思路比结论更重要，希望大家有收获。