消息“时序”及“一致性”为何这么难？.pdf

消息“时序”与“⼀致性”为何这么难？ 分布式系统中，很多业务场景都需要考虑消息投递的时序，例如： （1）单 消息投递，保证发送⽅发送顺序与接收⽅展现顺序⼀致 （2 ）群 消息投递，保证所有接收⽅展现顺序⼀致 （3 ）充值⽀付消息，保证同⼀个⽤户发起的请求在服务端执⾏序列⼀致 消息时序是分布式系统架构设计中⾮常难的问题，ta为什么难，有什么常见优化实 践，是本⽂要讨论的问题。 ⼀、为什么时序难以保证，消息⼀致性难？ 为什么分布式环境下，消息的时序难以保证，这边简要分析了⼏点原因： 【时钟不⼀致】 分布式环境下，有多个客户端、有web集群、service集群、db集群，他们都分布在不 同的机器上，机器之间都是使⽤的本地时钟，⽽没有⼀个所谓的“全局时钟” ，所以不 能⽤“本 时间”来完全决定消息的时序。 【多客户端 （发送⽅）】 多服务器不能⽤“本地时间”进⾏⽐较，假设只有⼀个接收⽅，能否⽤接收⽅本地时间 表⽰时序呢？遗憾的是，由于多个客户端的存在，即使是⼀台服务器的本 时间，也 ⽆法表⽰“绝对时序”。 如上图，绝对时序上，APP 1先发出msg 1，APP2后发出msg2 ，都发往服务器web 1，⽹ 络传输是不能保证msg 1⼀定先于msg2到达的，所以即使以⼀台服务器web 1的时间为 准，也不能精准描述msg 1与msg2的绝对时序。 【服务集群 （多接收⽅）】 多发送⽅不能保证时序，假设只有⼀个发送⽅，能否⽤发送⽅的本地时间表⽰时序 呢？遗憾的是，由于多个接收⽅的存在，⽆法⽤发送⽅的本 时间，表⽰“绝对时 序”。 如上图，绝对时序上，web 1先发出msg 1，后发出msg2 ，由于⽹络传输及多接收⽅的 存在，⽆法保证msg 1先被接收到先被处理，故也⽆法保证msg 1与msg2的处理时序。 【⽹络传输与多线程】 多发送⽅与多接收⽅都难以保证绝对时序，假设只有单⼀的发送⽅与单⼀的接收⽅， 能否保证消息的绝对时序呢？结论是悲观的，由于⽹络传输与多线程的存在，仍然不 ⾏。 如上图，web 1先发出msg 1，后发出msg2 ，即使msg 1先到达 （⽹络传输其实还不能保 证msg 1先到达），由于多线程的存在，也不能保证msg 1先被处理完。 【怎么保证绝对时序】 通过上⾯的分析，假设只有⼀个发送⽅，⼀个接收⽅，上下游连接只有⼀条连接池， 通过阻塞的⽅式通讯，难道不能保证先发出的消息msg 1先处理么？ 回答：可以，但吞吐量会⾮常低，⽽且单发送⽅单接收⽅单连接池的假设不太成⽴， ⾼并发⾼可⽤的架构不会允许这样的设计出现。 ⼆、优化实践 【以客户端或者服务端的时序为准】 多客户端、多服务端导致“时序”的标准难以界定，需要⼀个标尺来衡量时序的先后顺 序，可以根据业务场景，以客户端或者服务端的时间为准，例如： （1）邮件展⽰顺序，其实是以客户端发送时间为准的，潜台词是，发送⽅只要将邮 件协议⾥的时间调整为1970年或者2970年，就可以在接收⽅收到邮件后⼀直“置顶”或 者“置底” （2 ）秒杀活动时间判断，肯定得以服务器的时间为准，不可能让客户端修改本地时 间，就能够提前秒杀 【服务端能够⽣成单调递增的id】 这个是⽏庸置疑的，不展开讨论，例如利⽤单点写db 的seq/auto_inc_id肯定能⽣成单调 递增的id ，只是说性能及扩展性会成为潜在瓶颈。对于严格时序的业务场景，可以利 ⽤服务器的单调递增id来保证时序。 【⼤部分业务能接受误差不⼤的趋势递增id】 消息发送、帖⼦发布时间、甚⾄秒杀时间都没有这么精准时序的要求： （1）同1s内发布的 天消息时序乱了 （2 ）同1s内发布的帖⼦排序不对 （3 ）⽤1s内发起的秒杀，由于服务器多台之间时间有误差，落到A服务器的秒杀成功 了，落到B服务器的秒杀还没开始，业务上也是可以接受的 （⽤户感知不到） 所以，⼤部分业务，长时间趋势递增的时序就能够满⾜业务需求，⾮常短时间的时序 误差⼀定程度上能够接受。 关于绝对递增id ，趋势递增id的⽣成架构，详见⽂章 《细 分布式I ⽣成⽅法》，此 处不展开。 【利⽤单点序列化，可以保证多机相同时序】 数据为了保证⾼可⽤，需要做到进⾏数据冗余，同⼀份数据存储在多个 ⽅，怎么保 证这些数据的修改消息是⼀致的呢？利⽤的就是“单点序列化” ： （1）先在⼀台机器上序列化操作 （2 ）再将操作序列分发到所有的机器，以保证多机的操作序列是⼀致的，最终数据 是⼀致的 典型场景⼀：数据库主从同步 数据库