Category: 分布式

阅读本文大约需要 20 分钟。 你好，我是 Kaito。 在软件开发领域，「异地多活」是分布式系统架构设计的一座高峰，很多人经常听过它，但很少人理解其中的原理。 异地多活到底是什么？为什么需要异地多活？它到底解决了什么问题？究竟是怎么解决的？ 这些疑问，想必是每个程序看到异地多活这个名词时，都想要搞明白的问题。 有幸，我曾经深度参与过一个中等互联网公司，建设异地多活系统的设计与实施过程。所以今天，我就来和你聊一聊异地多活背后的的实现原理。 认真读完这篇文章，我相信你会对异地多活架构，有更加深刻的理解。 这篇文章干货很多，希望你可以耐心读完。 01 系统可用性 要想理解异地多活，我们需要从架构设计的原则说起。 现如今，我们开发一个软件系统，对其要求越来越高，如果你了解一些「架构设计」的要求，就知道一个好的软件架构应该遵循以下 3 个原则： 高性能 高可用 易扩展 其中，高性能意味着系统拥有更大流量的处理能力，更低的响应延迟。例如 1 秒可处理 10W 并发请求，接口响应时间 5 ms 等等。 易扩展表示系统在迭代新功能时，能以最小的代价去扩展，系统遇到流量压力时，可以在不改动代码的前提下，去扩容系统。 而「高可用」这个概念，看起来很抽象，怎么理解它呢？通常用 2 个指标来衡量： 平均故障间隔 MTBF（Mean Time Between Failure）：表示两次故障的间隔时间，也就是系统「正常运行」的平均时间，这个时间越长，说明系统稳定性越高 故障恢复时间 MTTR（Mean Time To Repair）：表示系统发生故障后「恢复的时间」，这个值越小，故障对用户的影响越小 可用性与这两者的关系： 可用性（Availability）= MTBF / (MTBF + MTTR) * 100% 这个公式得出的结果是一个「比例」，通常我们会用「N 个 9」来描述一个系统的可用性。 从这张图你可以看到，要想达到… Continue reading 搞懂异地多活，看这篇就够了

关注与点赞是我最大的动力！ 分布式一致性 想象一下，我们有一个单节点系统，且作为数据库服务器，然后存储了一个值（假设为X）。然后，有一个客户端往服务器发送了一个值（假设为8）。只要服务器接受到这个值即可，这个值在单节点上的一致性非常容易保证： 单击环境 但是，如果数据库服务器有多个节点呢？比如，如下图所示，有三个节点：a，b，c。这时候客户端对这个由3个节点组成的数据库集群进行操作时的值一致性如何保证，这就是分布式一致性问题。而Raft就是一种实现了分布式一致性的协议（还有其他一些一致性算法，例如：ZAB、PAXOS等）： 分布式环境 一些概念 讲解Raft算法之前，先普及一些Raft协议涉及到的概念： term：任期，比如新的选举任期，即整个集群初始化时，或者新的Leader选举就会开始一个新的选举任期。 大多数：假设一个集群由N个节点组成，那么大多数就是至少N/2+1。例如：3个节点的集群，大多数就是至少2；5个节点的集群，大多数就是至少3。 状态：每个节点有三种状态，且某一时刻只能是三种状态中的一种：Follower（图左），Candidate（图中），Leader（图右）。假设三种状态不同图案如下所示： 节点状态图 初始化状态时，三个节点都是Follower状态，并且term为0，如下图所示： 初始化 Leader选举 Leader选举需要某个节点发起投票，在确定哪个节点向其他节点发起投票之前，每个节点会分配一个随机的选举超时时间（election timeout）。在这个时间内，节点必须等待，不能成为Candidate状态。现在假设节点a等待168ms , 节点b等待210ms , 节点c等待200ms 。由于a的等待时间最短，所以它会最先成为Candidate，并向另外两个节点发起投票请求，希望它们能选举自己为Leader：   发起投票请求 另外两个节点收到请求后，假设将它们的投票返回给Candidate状态节点a，节点a由于得到了大多数节点的投票，就会从Candidate变为Leader，如下图所示，这个过程就叫做Leader选举（Leader Election）。接下来，这个分布式系统所有的改变都要先经过节点a，即Leader节点： 如果某个时刻，Follower不再收到Leader的消息，它就会变成Candidate。然后请求其他节点给他投票（类似拉票一样）。其他节点就会回复它投票结果，如果它能得到大多数节点的投票，它就能成为新的Leader。 日志复制 假设接下来客户端发起一个SET 5的请求，这个请求会首先由leader即节点a接收到，并且节点a写入一条日志。由于这条日志还没被其他任何节点接收，所以它的状态是uncommitted。 为了提交这条日志，Leader会将这条日志通过心跳消息复制给其他的Follower节点：   日志复制 一旦有大多数节点成功写入这条日志，那么Leader节点的这条日志状态就会更新为committed状态，并且值更新为5： Leader节点然后通知其他Follower节点，其他节点也会将值更新为5。如下图所示，这个时候集群的状态是完全一致的，这个过程就叫做日志复制（Log Replication）： 两个超时 接下来介绍Raft中两个很重要的超时设置：选举超时和心跳超时。 选举超时 为了防止3个节点（假设集群由3个节点组成）同时发起投票，会给每个节点分配一个随机的选举超时时间（Election Timeout），即从Follower状态成为Candidate状态需要等待的时间。在这个时间内，节点必须等待，不能成为Candidate状态。如下图所示，节点C优先成为Candidate，而节点A和B还在等待中：   选举超时 心跳超时 如下图所示，节点A和C投票给了B，所以节点B是leader节点。节点B会固定间隔时间向两个Follower节点A和C发送心跳消息，这个固定间隔时间被称为heartbeat timeout。Follower节点收到每一条日志信息都需要向Leader节点响应这条日志复制的结果：   心跳超时 重新选举 选举过程中，如果Leader节点出现故障，就会触发重新选举。如下图所示，Leader节点B故障（灰色），这时候节点A和C就会等待一个随机时间（选举超时），谁等待的时候更短，谁就先成为Candidate，然后向其他节点发送投票请求：   re-election 如果节点A能得得到节点C的投票，加上自己的投票，就有大多数选票。那么节点A将成为新的Leader节点，并且Term即任期的值加1更新到2：   新Leader节点… Continue reading 图解Raft：最简单易懂的分布式一致性算法

前言 Raft 也是一个 一致性算法，和 Paxos 目标相同。但它还有另一个名字 – 易于理解的一致性算法。Paxos 和 Raft 都是为了实现 一致性 产生的。这个过程如同选举一样，参选者 需要说服 大多数选民 (服务器) 投票给他，一旦选定后就跟随其操作。Paxos 和 Raft 的区别在于选举的 具体过程 不同。 正文 小试牛刀 在进入正题前，给大家分享一个《数学发散思维》中的一个故事，站在不同思维角度上，了解对一个问题理解的差异性。 问题: 甲乙两人轮流在一张圆桌上平放黑白围棋子，每次放一子，棋子不许重叠，谁先没有地方放就输。请问怎样放才能赢？ 这个问题有两层意思，第一，有没有一种放法保证必赢？第二，如果有怎么证明？     上图回答了这个问题，那就是先行者必胜，这里使用了三种不同的思维方式来阐述: 假如桌子只有一个围棋子那么大。 假如桌子无限大，先行者先占住圆心。由于圆是对称图形，所以只要对手还能找到位置放，你总能在对称的另一面找到位置放。 一个圆中可画单数个直径相等且互切的小圆。 三种不同的思维方式在可理解性难度上逐渐加深。 第一种是 极简化思维，但数学上是 不严谨 的。 第二种是 极限思维，和第一种结合起来就是 数学归纳法，在数学上是 严谨 的。 第三种是 形象思维，使用了 几何学概念，但对于没有几何学基础知识的人就很难理解了。 什么是Raft协议 Raft 协议将 Server 进程分成三类，分别是 Leader，Candidate，Follower。一个 Server 进程在某一时刻，只能是其中… Continue reading 分布式理论(六) – 一致性协议Raft

前言 世界上只有一种一致性算法，就是 Paxos。出自一位 Google 大神之口。Paxos 也是出名的 晦涩难懂，推理过程极其复杂。 Paxos 有点类似之前说的 2PC，3PC，但是解决了这两种算法各种硬伤。该算法在很多大厂都得到了工程实践，比如阿里的 OceanBase 的 分布式数据库，底层就是使用的 Paxos 算法。再比如 Google 的 chubby 分布式锁 也是用的这个算法。可见该算法在分布式系统中的地位，甚至于，Paxos 就是 分布式一致性 的代名词。 正文 1. Paxos算法是什么 Paxos 算法是 基于消息传递 且具有 高效容错特性 的一致性算法，目前公认的解决 分布式一致性问题 最有效的算法之一. 2. Paxos算法产生背景 2.1. 拜占庭将军问题 拜占庭是古代东罗马帝国的首都，由于地域宽广，守卫边境的多个将军（系统中的多个节点）需要通过信使来传递消息，达成某些一致的决定。但由于信使中可能存在叛徒（系统中节点出错），这些叛徒将努力向不同的将军发送不同的消息，试图会干扰一致性的达成。 2.2. Paxos算法由来 故事背景是古希腊 Paxos 岛上的多个法官在一个大厅内对一个议案进行表决，如何达成统一的结果。他们之间通过服务人员来传递纸条，但法官可能离开或进入大厅，服务人员可能偷懒去睡觉。 2.3 产生背景 在常见的 分布式系统 中，总会发生 节点宕机 或 网络异常 (包括消息的 重复、丢失、延迟、乱序、网络分区) 等情况。… Continue reading 分布式理论(五) – 一致性算法Paxos

前言 由于二阶段提交存在着诸如同步阻塞、单点问题、脑裂等缺陷。所以，研究者们在二阶段提交的基础上做了改进，提出了三阶段提交。 与两阶段提交不同的是，三阶段提交有两个改动点。 引入超时机制 – 同时在协调者和参与者中都引入超时机制。 在第一阶段和第二阶段中插入一个准备阶段，保证了在最后提交阶段之前各参与节点的状态是一致的。 正文 1. 三阶段提交的定义 三阶段提交（Three-phase commit），也叫三阶段提交协议（Three-phase commit protocol），是二阶段提交（2PC）的改进版本。 所谓的三个阶段分别是：询问，然后再锁资源，最后真正提交。 第一阶段：CanCommit 第二阶段：PreCommit 第三阶段：Do Commit 2. 三阶段提交的过程 2.1. 阶段一：CanCommit 3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。 a. 事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。 b. 响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态；否则反馈No。 2.2. 阶段二：PreCommit 协调者在得到所有参与者的响应之后，会根据结果执行2种操作：执行事务预提交，或者中断事务。 2.2.1. 执行事务预提交 a. 发送预提交请求 协调者向所有参与者节点发出 preCommit 的请求，并进入 prepared 状态。 b. 事务预提交 参与者受到 preCommit 请求后，会执行事务操作，对应 2PC 准备阶段中的 “执行事务”，也会 Undo 和 Redo 信息记录到事务日志中。 c.… Continue reading 分布式理论(四) – 3PC协议

前言 由于BASE理论需要在一致性和可用性方面做出权衡，因此涌现了很多关于一致性的算法和协议。其中比较著名的有二阶提交协议（2 Phase Commitment Protocol），三阶提交协议（3 Phase Commitment Protocol）和Paxos算法。 本文要介绍的2PC协议，分为两个阶段提交一个事务。并通过协调者和各个参与者的配合，实现分布式一致性。 两个阶段事务提交协议，由协调者和参与者共同完成。 角色 XA概念 作用 协调者 事务管理器 协调各个参与者，对分布式事务进行提交或回滚 参与者 资源管理器 分布式集群中的节点 正文 1. 分布式事务 分布式事务是指会涉及到操作多个数据库的事务，其实就是将对同一库事务的概念扩大到了对多个库的事务。目的是为了保证分布式系统中的数据一致性。 分布式事务处理的关键是： 需要记录事务在任何节点所做的所有动作； 事务进行的所有操作要么全部提交，要么全部回滚。 2. XA规范 2.1. XA规范的组成 XA规范是由 X/Open组织（即现在的 Open Group ）定义的分布式事务处理模型。 X/Open DTP 模型（ 1994 ）包括： 应用程序（ AP ） 事务管理器（ TM ）：交易中间件等 资源管理器（ RM ）：关系型数据库等 通信资源管理器（ CRM ）：消息中间件等 2.2. XA规范的定义 XA规范定义了交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。而XA接口函数由数据库厂商提供。… Continue reading 分布式理论(三) – 2PC协议

前言 BASE理论是由eBay架构师提出的。BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网分布式系统实践的总结，是基于CAP定律逐步演化而来。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，才用适当的方式来使系统打到最终一致性。 正文 1. CAP的3选2伪命题 实际上，不是为了P（分区容错性），必须在C（一致性）和A（可用性）之间任选其一。分区的情况很少出现，CAP在大多时间能够同时满足C和A。 对于分区存在或者探知其影响的情况下，需要提供一种预备策略做出处理： 探知分区的发生； 进入显示的分区模式，限制某些操作； 启动恢复过程，恢复数据一致性，补偿分区发生期间的错误。 2. BASE理论简介 BASE理论是Basically Available(基本可用)，Soft State（软状态）和Eventually Consistent（最终一致性）三个短语的缩写。 其核心思想是： 既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。 3. BASE理论的内容 基本可用（Basically Available） 软状态（Soft State） 最终一致性（Eventually Consistent） 下面展开讨论： 3.1. 基本可用 什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言： 响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。 3.2. 软状态 什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。 软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。 3.3. 最终一致性 上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。 而在实际工程实践中，最终一致性分为5种： 3.3.1. 因果一致性（Causal consistency） 因果一致性指的是：如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。 3.3.2. 读己之所写（Read your writes） 读己之所写指的是：节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。 3.3.3. 会话一致性（Session consistency） 会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现… Continue reading 分布式理论(二) – BASE理论