简介* *阿里梅的简介:跨地域，即“双重异地居住”和“多重异地居住”中的异地概念 * *在业务快速发展的情况下，我们的服务需要跨区域部署，以满足本地访问和跨区域容灾的需求。在这个过程中，不可避免地会涉及到跨区域的分布式一致性问题。 跨区域引起的网络延迟问题以及由此衍生的一系列问题对跨区域分布式一致性系统的设计和构建是巨大的挑战。业界有很多解决这个问题的方案，都是希望处理跨区域场景下的一致性问题。 面试官:如何处理跨区域场景下分布式系统的一致性？尴尬，本文参考了阿里巴巴女娲团队对跨区域场景下分布式一致性系统的探索，从“What How Future”三个方面，详细阐述了跨区域场景下需要承担的需求和挑战，行业内常见的系统和女娲团队对跨区域场景权衡点的思考，以及对跨区域一致性系统未来发展的设计和思考，从而发现和应对跨区域场景下更多的需求和挑战。 一、跨区域需求与挑战面试官:如何处理跨区域场景下分布式系统的一致性？尴尬1。跨区域需求是集团全球化战略下业务快速发展带来的挑战。 比如淘宝单元化业务或者全球速卖通区域化业务，有一个无法回避的问题——数据跨区域读写一致性。 其核心需求可以概括为:跨区域业务场景跨区域配置同步和服务发现是跨区域一致性协调服务的两个常见业务需求。跨区域部署可以提供就近接入的能力，减少服务延迟。根据具体业务场景，可分为多区域写入或简化单区域写入、强一致性读取或最终一致性读取。 跨区域的会话管理和基于它的跨区域分布式锁也需要提供成熟的解决方案。 服务和资源的扩展当一个区域内某个机房的服务能力达到上限但无法扩展时，一致性系统就需要在一个区域内的多个机房进行横向扩展，并进行跨区域扩展。 跨区域容灾能力当遇到某个机房或某个区域的灾难性故障时，需要一个一致的系统，通过跨区域的服务部署，将业务从一个区域快速迁移到另一个区域，从而完成容灾逃生，实现高可用。 2.挑战综合网络时延和业务需求，可以总结出跨区域一致性系统需要解决的挑战:时延:几十毫秒甚至更长时间的网络时延导致的核心问题是网络时延高。以我们跨区域在线部署的集群为例，集群中的机器属于杭州、深圳、上海、北京的机房。实际测试表明，从杭州机房到上海的延迟约为6ms，从深圳到北京的延迟可达近30 ms。 一般同一区域的机房或机房的网络延迟都在毫秒以内，相比跨区域访问的延迟，增加了一个数量级。 水平扩展:法定服务器的规模有限。基于Paxos理论及其变种的分布式一致性系统在扩展节点时不可避免地会遇到复制开销的问题。一般情况下，一个Quorum中的节点数量不超过9个，因此不可能简单地将一致性系统的节点部署在多个区域中。系统需要不断横向扩展，以满足服务和资源的扩展需求。 存储上限:单个节点的存储数据有限，故障转移恢复缓慢。无论是基于MySQL还是基于Paxos的一致性系统，单个节点都会维护和加载足量的镜像数据，这将受到单个集群容量的限制。 同时，在故障切换恢复期间，如果数据版本滞后很多，将很长时间无法通过拉动其他区域镜像来恢复。 二。我们的询价1行业处理方案行业对于跨区域一致性系统的设计有很多，主要参考论文[1]和少数开源实现。以下细节比较常见:跨区域部署面试官:如何处理跨区域场景下分布式系统的一致性？尴尬图1直接跨区域部署直接跨区域部署，read请求直接读取区域节点，速度快，一致性和可用性由Paxos保证，不存在单一问题。 缺点也很明显，会遇到第一部分提到的横向扩展问题，即Quorum扩展时会遇到复制开销问题。 并且随着Quorum节点数量的增加，在极高的跨区域网络延迟下，多数每次达成一致需要很长时间，写入效率很低。 单一区域部署+学习者角色面试官:如何处理跨区域场景下分布式系统的一致性？尴尬图2引入学习者角色通过引入学习者角色(如zk中的Observer和etcd [2]中的Raft Learner)，即只执行数据同步但不参与多数表决的角色，将写请求转发到某个区域(如图2中的A区)，避免了直接多节点部署的表决延迟问题。 这种方法可以处理水平扩展和延迟的问题，但是由于投票角色都部署在一个区域内，当这个区域的机房遇到灾难性的时候，写服务将无法使用。 这种模式就是Otter[3]采用的部署模式 服务+分区&单区域部署+学习者面试官:如何处理跨区域场景下分布式系统的一致性？尴尬图3多个服务解析分区将数据按照规则划分到不同的分区。每个区域有一个法定人数提供服务。不同地区的定额负责不同的分区。不同区域的Quorums使用Learner同步填充和转发不同分区的数据请求，保证某个区域的问题只影响该区域分区的可用性。 同时，这种方案下还会有正确性的问题，即运算不符合序列一致性[4](见论文[1])。 在实际操作中，根据业务场景有各种处理方案，会进行优化和权衡，以弥补缺陷。 业内常见的方案是单区域部署+学习者角色的方案，通过同城多活动和学习者跨区域数据同步来保证高可用性和高效率。 其他方案也有自己的优化方案。跨区域部署可以通过减少达成解析时的跨区域通信来减少延迟和带宽问题，如TiDB的follower replication[5]；服务+分区&单区域部署+学习者方案的正确性也可以通过在读取前增加同步操作来保证，牺牲一些读取的可用性，如论文[1]所述。 最终结论如下，重点项目后面会详细说明:面试官:跨区域场景下分布式系统的一致性如何处理？尴尬2跨区域权衡。通过第一部分总结的需求和挑战，以及之前业界对跨区域一致性系统解决方案的研究，可以总结出跨区域场景下基于Paxos的分布式一致性系统的核心权衡:写操作发生跨区域一致性协议太慢，无法达成解析；该地区的多项活动在极端情况下无法提供可用性；要求分布式系统的核心水平扩展能力。为了解决这三个问题，我们设计了一个日志镜像解耦的跨区域一致性系统。 3跨地域日志镜像解耦面试官:如何处理跨地域场景下分布式系统的一致性？如图3所示，我们的系统分为后台日志同步通道和前端全尺寸状态机——日志和镜像解耦架构。 后台跨区域全局日志同步通道，负责保证各区域请求日志的强一致性；前端状态机部署在各个区域，可以解决用户的请求，与后端日志服务交互，对外提供全局强一致性元数据访问服务。该接口可以根据业务需求快速修改状态机来实现。 在全局日志和局部镜像分离的框架下，除了解耦本身带来的系统运行和可扩展性的提升，还可以处理很多非解耦框架下的问题。下面的分析是如何处理之前在这个框架下考虑的一些主要问题:从部署方式上看，写操作效率单看起来类似于直接多区域多节点部署，然后在每个区域添加学习者角色的做法。它是直接多节点部署和引入学习者的组合，集成了 最大的区别是我们的日志和镜像是解耦的，也就是说跨区域部分是简单的日志同步足够轻量高效，而且由于每个区域只有一个节点，可以节省跨区域带宽(类似TiDB的跟随者复制)。 同时，后台日志同步通道还可以实现多组的功能，将数据划分为分区，每个一致性组负责一个不同的分区。 因为大部分业务场景都是读取本地数据，各种方式差别不大，所以主要进行写操作的延迟分析。下面是写操作(或强一致性读)的延迟分析:RTT(往返时间)，可以简单理解为发送方从发送请求到得到响应的时间。 因为跨区域网络时延较大，所以后面的RTT主要是指跨区域的RTT。 (1)直接跨区域调配。对于与师父的共同约定，我们的请求分为两种情况:拜访领袖所在区域RTT(暂时忽略该区域的轻微延迟)客户端->；leader-& gt；追随者-& gt；leader-& gt；拜访客户跟随者所在地区的2个RTT客户->:跟随者->；leader-& gt；追随者-& gt；leader-& gt；追随者-& gt；客户端(2)在单区域部署+学习者同步的方案中，在区域内活动，区域间学习者同步，我们的延迟是:本地区域0 RTT客户端-->；法定人数->；1客户端之间的RTT客户端->:学习者->；法定人数->；学习者-& gt；客户端(3)多服务分区，单域部署+学习者同步(类似结果B)，在本地域分区写0 RTT *跨分区写1 RTT(4)日志镜像解耦架构(类似结果A)，写1 RTTClient ->本地域分区->:Frontend->；日志通道(本地)-& gt；日志通道(对等)-& gt；日志通道(本地)-& gt；前端-& gt；跨客户端分区写入2个RTT (Paxos两阶段提交/转发leader)Client->:Frontend->；日志通道(本地)-& gt；日志通道(对等)-& gt；日志通道(本地)-& gt；日志通道(对等)-& gt；日志通道(本地)-& gt；前端-& gt；经过上面的客户端对比，可以看出，只要使用一致性协议进行跨区域写入，就会有至少一个RTT的延迟。但是，如果Paxos Quorum部署在单个区域，则无法保证在任何极端情况下的可用性。 所以根据业务需求，可以在可用性和书写效率之间做一个权衡。日志镜像解耦架构可以确保在多区域部署场景中的极端可用性和正确性。当然效率会比单区域部署+学习者略差。但是，如果多融合比直接多区域部署更轻便、更高效，投票效率不会受到影响，因为法定人数规模不会因横向扩张而增加。 采用多服务分区部署的方案没有效率优势，但在可移植性、可维护性、正确性和可用性方面有优势。 满足跨区域部署和单区域部署+学习者的强一致性。zookeeper和etcd都有相应的细节，这里就不赘述了。 这种多服务分区和子分区的方案不满足顺序一致性，主要是因为多服务不能保证每次写操作提交的顺序。见下图:面试官:如何处理跨地域场景下分布式系统的一致性？尴尬的序列一致性在图5中我们可以看到，当两个客户端同时修改X和Y时，写操作的并发性高时，序列一致性无法保证。 一致性可以按照正确的顺序安排每个客户端的操作。在图4的例子中，set1 (x，5)= >:get1(y)-& gt；0 = & gtset2(y，3)= & gt；get 2(x)-& gt；Or set2 (y，3)= >:get 2(x)-& gt；0 = & gtset2(y，3)= & gt；get1(y)-& gt；3与订单一致。 镜像解耦架构的一致性可以简单理解为跨区域部署+学习者，写操作有sync选项，只有后台日志提交成功且拉取了对应的日志才会返回成功，所以肯定可以在此操作之前拉取其他客户端写操作对应的日志，所以符合顺序一致性。 可用性类似于直接跨区域多节点部署的可用性。前台状态机可以在某个区域的后台节点挂机时转发请求，也可以在后台全局日志服务不可用时提供读取的可用性，可以保证极端情况下读写的高可用性。 同时，由于图像存储在各个区域的状态机中，当某个前台状态机挂起时，用户可以切换到前台的其余部分，当故障转移恢复时，可以直接从后台拉取数据进行恢复。当滞后太多时，需要从局部区域的前景其余部分拉取图像，这样就不需要跨区域同步图像，这样可以使前景不可用的时间极短。 横向扩展能力横向扩展能力是分布式服务的核心能力。前述方案中，直接跨区域部署的横向扩展能力极差，其余都是依靠学习者的方式，这也处理了横向扩展的问题。然而，去耦设计是干净的，没有对数镜像去耦。 总结对比以上关键问题:面试官:如何处理跨区域场景下分布式系统的一致性？尴尬三。跨区域的更多可能性。在后台日志和前台镜像解耦的状态下，我们对跨区域场景的探索分为两部分:轻量高效的后台日志同步和灵活丰富的前台状态机。 轻量级，表现在架构上，只在后台同步日志给后台存储带来的压力不大，只同步轻量级增量日志。 *高效，表现在后台的一致性协议上。因为是轻量级的，只要考虑投票选举的逻辑，只需要关注日志同步效率的提升，其余的业务逻辑不需要消耗后台资源。 *灵活，表现在架构上，前台可以设置自己的上传日志、CAS、交易等。可以打包成日志由前台解析解决。 *丰富，主要在前台状态机，因为日志的灵活性给我们留下了巨大的探索和构建空间，我们可以根据自己的需求封装状态机解决各种复杂的事务。 新架构下有新问题。这部分主要探索如何吸收现有系统的优点，利用日志镜像解耦的轻便性和灵活性，实现跨地域场景下一致性协议和状态机的高效性和丰富性。对后续跨区域一致性系统的开发也会有一个思路和规划。 总体目标是完善后台一致性协议，把前端状态机做大做强。 1高效的后台一致性协议基于我们之前对写入效率的讨论，在多个区域写入相同数据的场景下，延迟只能控制在2RTT。 由于跨区域的场景，延期的比例主要在跨区域的网络通信中，无论是有大师的转发还是有大师的Paxos两阶段提交，延期都是2RTT T。 但如果使用无主协议，比如Paxos变种EPaxos[6]，就可以尽可能提高跨区域场景下的写入效率。它的延迟分为两种情况:快速路径和慢速路径，快速路径的延迟为1 RTT，慢速路径的延迟为2 1RTT。 具体引用EPaxos文章中的一句话:如果并发提案的日志之间没有冲突，EPaxos只要需要运行预接受阶段就可以提交(快速路径)，否则需要运行接受阶段才能提交(慢速路径)。 与分区操作相比，如果选择后台一致性协议为EPaxos，可以保证极端情况下的可用性，大多数情况下延迟到1RTT。这就是无主一致性协议在跨区域场景下的优势，主要是省略了转发首领操作的RTT。 目前，我们的系统使用的是最基本的Paxos实现。理论上，多位置写入场景的延迟与托管协议的延迟没有太大区别。后续开发期望使用EPaxos来加快跨区域场景下写操作的效率。 因为不需要实现各种业务逻辑，所以高效率是后台一致性协议的最大需求，当然其正确性和稳定性也是必不可少的。对于前端状态机来说，有丰富的场景可以设计和发挥。 操作CAS这个架构下CAS操作的实现是很自然的，因为后台只有一致性日志，所以每个CAS请求自然会有提交的顺序。举个例子。 两个客户端同时写同一个键值:面试官:如何处理跨地域场景下分布式系统的一致性？尴尬图6示出了在CAS操作开始时key的值为0。此时，客户端1和客户端2同时对密钥进行CAS操作，即CAS(key，0，1)和CAS(key，0，2)。当这两个操作同时提交和提交时，因为后台Quorum已经达到了一个解析，复制日志肯定会有一个顺序，那么自然这两个并发的CAS操作就转换成顺序执行了。 当前端同步到这两个操作的日志时，会将这两个操作依次应用到本地状态机。自然CAS(key，0，1)成功，升级键值为1，但是CAS(key，0，2)升级失败。此时，前台将向相应的请求客户端返回其CAS请求成功或失败的结果。 其原理是将一个并发操作变成一个顺序的串行过程，从而避免了跨区域场景下的锁操作。可想而知，如果在后台维护一个kv结构数据，需要添加一个跨区域的分布式锁来完成这个操作，相对来说更加繁琐，效率也没有保证。 通过只同步日志将复杂的计算转移到前端，可以灵活构造前台状态机，更好地实现CAS或更复杂的事务功能(这种架构请参考pravega的StateSynchronizer[7])。 ID全局ID全局ID是一个常见的要求。分布式系统生成唯一的ID，通常使用UUID、雪花算法或基于数据库、redis和zookeeper的方案。 使用类似于zookeeper的znode的数据版本来生成全局ID。在这个日志镜像分离架构中，可以调用CAS接口生成一个key作为全局ID，每次都在全局ID上执行原子操作。 基于上面提到的CAS设计，跨区域并发场景下无需锁定，使用方式类似redis对key的原子操作。 2手表操作订阅功能是分布式协同服务不可或缺的，是业务最常见的需求。以下是zk和etcd的调查结果:目前业内比较成熟的已经实现订阅通知的分布式协同系统有ETCD和ZooKeeper。我们将以这两个系统为例来说明各自的解决方案。 ETCD将存储数据的多个版本历史(MVCC ),并且版本号将单调增加以指示新版本和旧版本。客户端只需要导入自己关注的版本历史，服务器就可以把所有后续事件推送给客户端。 Zookeeper不保存数据的多个版本历史，只保存当前数据状态，用户无法订阅数据的版本历史，所以用户只能订阅当前状态之后的变更事件，所以订阅伴随着读取，服务器将当前数据发送给用户，然后推送后续事件。同时，为了防止用户在故障转移等异常场景下订阅旧数据和事件，用户会拒绝使用旧数据连接服务器(这取决于服务器在每次请求时返回当前服务器的全局XID)。 面试官:如何处理跨区域场景下分布式系统的一致性？尴尬的是，上述研究结果表明，ETCD更符合我们的界面设计。目前ETCDv3采用HTTP/2 TCP链路复用，watch性能有所提升。 因为是日志加状态机结构，所以ETCD v3在设计函数的时候主要是借鉴，借鉴了它如何订阅多个键和返回所有历史事件的两个特点。 实现etcd订阅的功能，前端状态机同步分析日志时，如果有日志写入，会同时升级kv结构的状态机Store和专门为watch接口提供的watchableStore。具体实现完全可以参考etcd，然后根据日志版本号将订阅版本之后的所有历史事件返回给客户端。 订阅多键还使用段树作为观察者的范围键存储结构，可以实现观察者的范围键的观察者通知。 3租赁机制在无主系统中实现有效的租赁机制是一个很大的挑战。无主系统中没有领导者，任何节点都可以保持租用。租约分布在所有节点上，当一些节点不可用时，需要平滑切换到其他节点。 在无主系统中实现高效租赁机制的难点在于如何避免后台一致性协议中大量的租赁维护消息，影响系统性能。最好是让租赁维护消息直接在前台本地解决，不用经过后台。 所以我们的思路是把客户端和前台的租用聚合到前台和后台的租用，这样租用维护消息就可以直接在前台本地解决。 四。结语随着全球化战略的推进，跨区域方面的需求肯定会越来越迫切，跨区域场景的真实痛点也会越来越清晰。希望我们跨区域的研究和探索能给大家一个思路和参考，在跨区域日志镜像分离的框架下继续探索更多的可能性。 希望对你学习分布式系统一定有帮助，喜欢的朋友可以帮LZ转发+关注。谢谢大家！(LZ也会尽力给你有学习价值的参考资料！)