消息顺序性为何这么难？

很多业务都需要考虑消息投递的顺序性：

• 单聊消息投递，保证发送方发送顺序与接收方展现顺序一致
• 群聊消息投递，保证所有接收方展现顺序一致
• 充值支付消息，保证同一个用户发起的请求在服务端执行序列一致
• 消息顺序性是分布式系统架构设计中非常难的问题，有什么常见优化实践呢？

折衷一：以客户端或者服务端的时序为准

不管什么情况，都需要一个标尺来衡量时序的先后顺序，可以根据业务场景，以客户端或者服务端的时间为准，例如：

• 邮件展示顺序，其实是以客户端发送时间为准的

画外音：发送方只要将邮件协议里的时间调整为1970年或者2970年，就可以在接收方收到邮件后一直“置顶”或者“置底”。

• 秒杀活动时间判断，肯定得以服务器的时间为准，不可能让客户端修改本地时间，就能够提前秒杀

折衷二：服务端生成单调递增id作为时序依据
对于严格时序的业务场景，可以利用单点写db的seq/aut