最近阅读了《SRE Google运维解密》的第23章，有一些感触，记录一下。

日常工作中，我们经常需要一些服务分布式的运行。跨区域如跨城、跨洲部署运行分布式系统往往是容易的，但是如何保证各系统间状态的一致是困难的。如何保证服务的高可靠、高可用，就是服务提供的数据是准确的，关键在于一些状态的传递，这个时候就需要利用分布式共识系统来维护相关状态，确保大家拿到的状态信息最终是一致的。

要想实现一个分布式共识系统，需要采用一些经过理论验证的方案，最基础的就是CAP理论。

CAP 理论

CAP原则是指对于一个分布式系统，Consistency 一致性、Availability 可用性、Partition tolerance 分区容错性 三者是不可能同时满足的，换成通俗的说法就是：

1. 每个节点上的所见数据是一致的
2. 每个节点都可以访问数据
3. 可以承受网络分区问题

CAP理论指出，对于分布式系统，最多能实现上面两点。同时由于现实环境中，网络分区问题迟早会发生（如光纤断、延时、丢包等问题），构建分布式系统就需要在高可用和一致性之间选择。

BASE 理论

我们对于传统的ACID数据存储语义(原子性、一致性、隔离性、持久性)很熟悉，这种方案为我们提供了数据的强一致性。但是分布式系统提供了的是另外一套语义，BASE语义(基本可用 basic available、软状态 soft state、最终一致性 eventual consistency)。ACID的问题在于遇到超大的数据集和事物时，需要很高的硬件成本，BASE就是用来解决此类问题，它是对CAP理论中可用性和一致性权衡的结果，其核心思想是即使无法做到强一致性，但应用可以根据自身的特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

• 基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。
• 软状态：和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
• 最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。

分布式系统出现问题的场景

分布式系统出现问题主要是因为网络问题。

脑裂

对于使用心跳机制来提供高可用的服务，遇到网络问题时，可能存在服务同时提供主写或者同时挂掉的情况。这个问题说明，领头人选举不能通过简单的心跳来实现。

需要人工干预的灾备切换

对于 Mysql 的主从复制模式，利用外部程序监控主实例，根据主实例状态决定是否提升从节点成为主实例。这种解决方法提供了CP，没办法保证可用性A。

有问题的小组成员算法

使用 Gossip 算法进行领头人选举，在网络问题时，不能满足C，可以满足AP。

分布式共识问题解决方案 Paxos 协议

Paxos 协议本书没有详细的介绍，说的也不是很形象。可以参考生活中的Paxos，原来你我都在使用——对Paxos生活化的解读以及Paxos算法细节详解(一)–通过现实世界描述算法。
下面这个图概括了协议中的几个角色及关系。

分布式共识算法是很底层、很原始的，真正有用的是基于此之上的系统组件，包括：数据存储、配置存储、队列、锁机制和领头人选举服务。

后面介绍了分布式共识的系统架构模式，包括了几个组件：可靠的复制状态机、领头人选举机制、分布式协调和锁服务、分布式队列和消息传递。

可靠的复制状态机

RSM (replicated state machine) 是一个能在多个进程中用同样顺序执行同样的一组操作的系统。

可靠的数据存储

领头人选举机制

分布式协调和锁

可靠的分布式队列和消息传递

性能问题

文中介绍了几种分布式共识问题提高性能的方法，没有最优的方案，需要根据不同的因子和场景来进行选择。
参考资料
1、[SRE Google运维解密](SRE Google运维解密)
2、生活中的Paxos，原来你我都在使用——对Paxos生活化的解读
3、Paxos算法细节详解(一)–通过现实世界描述算法
4、CAP原则
5、CAP原则(CAP定理)、BASE理论