分布式理论一

分布式系统原理

如何保证数据一致性

1.分布式一致性解决方案

2.分布式事务2PC和3PC详解

3.分布式一致性算法（Paxos，Raft，ZAB）

4.鸽巢原理+NWR读写模型+Quorum议会制

5.CAP定理 和 BASE理论

1. 分布式一致性问题

1.1 分布式一致性解决方案产生背景

​ 分布式一致性解决方案产生背景：

​ 为了解决从集中式服务扩展到分布式服务时使用多副本手段为了保证数据和服务高可用而产生的副本间数据状态不一致的问题

1.2 集中式服务

所谓的集中式服务就是指，由一台或多台主计算机组成中心节点，数据集中存储于这个中心节点，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统所有的功能均由其集中处理，也就是说，集中式系统中，每个终端或客户端及其仅仅负责数据的录入和输出，而数据的存储与控制处理完全交由主机来完成

集中式服务的优点

1.组成结构简单
2.应用部署简单
3.项目架构简单

集中式服务的缺点

1.大型主机的研发人才和维护人才培养成本非常高
2.大型主机非常昂贵
3.单点故障问题，主机一挂，所有服务终止
4.大型主机的性能扩展受限于摩尔定律

摩尔定律：

摩尔定律是英特尔（Intel）创始人之一 戈登·摩尔（Gordon Moore）提出。主要内容为：价格不变时，集成电路上可容纳的元器件的数目，约每隔18 - 24个月便会增加一倍，性能也将提升一倍。换言之，每一美元所能买到的电脑性能，将每隔18-24个月翻一倍以上

摩尔定律所述：纵向扩展在理论上是受限，所以只能考虑横向扩展，而且理论上来说，横向扩展理论不受限

纵向扩展：提升服务器性能，上限的
横向扩展：提升服务器数量（分布式）

1.3 分布式服务

在《分布式系统概念与设计》注 一书中，对分布式系统做出了如下定义：分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。将来的spark计算引擎把这个通过消息传递来实现分布式系统的内部沟通协调实现的非常出色

简单来说就是一群独立服务器集合共同对外提供服务，但是对于普通用户来说，就像是一台超级服务器在提供服务一样

1.结构：由多台服务器组成的一个逻辑整体
2.作用：肯定是用来解决单台服务器解决不了的费时费资源的复杂需求
	集群：
		1.业务集群：nginx + tomcat 请求多，单台服务器的并发不够，所以需要增加服务器来均摊巨量的请求处理压力，但是每个请求的处理其实不复杂
		2.架构集群：无论给多长时间，单台服务器都没法在有限的时间内解决。只有多台服务器联合解决才能实现，每台独立服务器实现复杂需求的其中一部分呢功能实现
3.原理：内部必然会有联系，然后对外提供服务，从而达到处理事情的一致性

分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源也就越多，能够处理的并发访问量也就越大

一个由分布式系统实现的电子商城，在功能上可能被拆分成多个应用，分别提供不同的功能，组成一个分布式系统对外提供服务，而系统内的各个子系统之间通过网络进行通信和协调，如异步消息或者RPC/HTTP 请求调用等

所以，分布式系统中的计算机在空间上几乎没有任何限制，这些计算机可能被放在不同的机柜上，也可能被部署在不同的机房中，还可能在不同的城市中，对于大型的网站甚至可能分布在不同的国家和地区

简单来讲，逻辑上整体，实际上分布

分布式系统的特点：

• 分布性：分布式系统中的多台计算机都会子啊空间上随意分布，同时，它们的分布情况也会随时变动
• 对等性：集群中的每隔工作节点的角色是一样的，主要是副本概念
• 并发性：多个机器可能同时操作一个数据库或者存储系统，可能引发数据不一致的问题
• 缺乏全局时钟：分布式系统中的多个主机上的事件的先后顺序很难界定（分布式场景中最复杂的一个问题之一）
• 故障发生频繁：组成分布式系统的所有计算机都有可能发生任何形式的故障，比如服务器宕机、网络拥堵和延迟

和集中式系统相比，分布式系统的性价比更高、处理能力更强、可靠性更高，也有很好的扩展性。但是，分布式在解决了网站的高并发问题的同时也带来了一些其他问题

首先，分布式的必要条件就是网络，一个集群中服务器数量越多，有服务器宕机的概率也越大，由于服务器在集群中的分布式部署，用户的请求只会落到其中一台机器上，所以，一旦处理不好就会很容易产生数据一致性问题

1.4 分布式系统常见异常问题

分布式系统在功能上，确实要比单机系统强大太多，但是分布式系统的设计实现和维护的难度大大提升了

以下是常见问题及解决方案

通信异常：网络不可用（消息延迟或者丢失），会导致分布式系统内部无法顺利进行一次网络通信进行沟通协调，所以可能造成多节点数据丢失和状态不一致，还有可能造成数据乱序。解决方案：重试机制

网络分区：网络不联通，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个独立的区域，分布式系统就会出现局部小集群造成数据不一致。解决方案：把数据状态不是最新的下线掉

节点故障/机器宕机：服务器节点出现的宕机或者“僵死”现象，这是常态，而不是异常。解决方案：数据副本协议，异步复制

分布式三态：即成功、失败和超时，分布式环境中的网络通信请求发送和结果响应都有可能丢失，所以请求发起方无法确定消息是否成功处理，分布式的可用性：在用户能忍受的时间范围内，给出一定响应。解决方案：超时处理

存储数据丢失：对有状态节点来说，数据丢失就意味着状态丢失，通常只能从其他节点读取、恢复储存的状态。解决方案

1.5 衡量分布式系统的性能指标

1.性能：三个性能指标（吞吐、延迟、并发）往往会互相制约，追求高吞吐，往往很难做到低延迟，系统平均响应时间长，也很难提高QPS

1.系统的吞吐能力，指系统在某一时间可以处理的数据/请求总量，通常可以用系统每秒处理的总数据/总请求量来衡量；
2.系统的响应延迟，指系统完成某一功能需要的时间
3.系统的并发能力，指系统可以同时完成某一功能的能力，通常也叫OPS（query per second）衡量

2.可用性：系统的可用性（availability）是指，在系统面对各种异常时可以正常提供服务的能力，系统的可用性可以用系统停服务的时间与正常服务的时间比例来衡量，也可以用某功能的失败次数与成功次数的比例来衡量，，可用性是分布式的重要指标，衡量了系统的鲁棒性，是系统容错能力的体现。（5个9的可靠性：一年只有5分钟的宕机时间，6个9的可靠性，也就是31秒，99.9999%）

3.可扩展性：系统的可扩展性（scalability）指分布式系统通过扩展集群机器规模提高系统性能（吞吐、延迟、并发）、存储容量、计算能力的特性，好的分布式系统总在追求线性扩展性，也就是使得系统的某一指标可以随着集群中的机器数量线性增长，最期望的情况：动态热部署

4.一致性：分布式系统为了提高可用性，总是不可避免的使用副本机制，从而引发副本一致性的问题，越是强的一致性的模型，对于用户使用来说使用起来越简单

1.6 一致性理解

1.强一致性；写操作完成后，读操作一定能够读到最新数据，在分布式场景中，很难实现，后续讲解的Paxos算法、Quorum机制、ZAB协议都是解决方案

2.弱一致性：不承诺立即可以读到最新写入的值，也不承诺多久之后数据能够达到一致，但会尽可能保证某个时间级别（比如秒级别）后，数据能够达到一致状态

3.读写一致性：用户读取自己写入结果的一致性，保证用户永远能够第一时间看到自己更新的内容，比如发一条朋友圈，朋友圈的内容是不是第一时间被朋友看到无所谓，但一定要第一时间显示在自己列表上

4.单调读一致性：本次读到的数据不能比上次读到的数据旧，多次刷新返回旧数据出现灵异事件。解决方案：将请求通过hash映射到同一台机器

5.因果一致性：如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值，和节点A无因果关系的节点C的数据访问则没有这样的限制

6.最终一致性：是所有分布式一致性模型中最弱的，不考虑中间的任何状态，只保证经过过一段时间后，最终系统内数据正确，它最大程度上保证了系统的并发能力，因此在高并发场景下，他也是使用最广的一致性模型

简单来讲，一致性就是看要写入所有副本后再返回（保证数据安全，成本代价大）（强一致性）还是写入一个副本就返回（速度）（最终一致性）

1.7 分布式一致性的作用

• 为了提高系统的可用性，以防止单点故障引起的系统不可用
• 提高系统整体性能，通过负载均衡技术，让分布在不同地方的数据副本都能为用户服务

HDFS 为了保证数据的安全性，提供了两个解决方案：

• 副本机制：更多地消耗磁盘资源

  • 一个数据三个副本的安全性接近100%
  • 如果为了应对分布式计算，推荐参与分布式计算的数据都是用副本机制存储

• 纠删码：如果一个数据块要保证安全，默认是3个副本，所以占用了三倍的磁盘资源。纠删码，消除了副本机制，每个数据块都只有一个副本，那么要保证安全，就要往原始数据文件中，插入一些辅助数据后进行编码，任何拆开多个数据块进行存储，如果丢失了一个数据块，就从这个文件的剩下的数据块内容通过逆编码来恢复，加入的辅助数据大概是原始数据的40%就能保证3个副本一样的安全级别

  • 膨胀辅助数据为源数据的40%安全性也是接近100%，膨胀辅助数据越大安全级别越高
  • 膨胀辅助数据比副本机制更节省资源，原先300%资源才能达到的效果，只需要140%即可
  • 如果为了存储基本不用的冷数据，推荐使用纠删码进行存储

​ 逆运算（逆编码）的计算逻辑就是矩阵乘法

​ 假设A * B = C（源数据是A，辅助数据是B），如果其中数据块丢了，可以通过剩下的数据块进行逆运算恢复：更多地消耗CPU

对于分布式系统的数据的一致性的问题

解决方案：

1.事务 + 分布式事务
2.分布式一致性算法 + 分布式共识算法
3.Quorum机制 + NWR机制

2.分布式事务 2PC 和 3PC 详解

事务：单机存储系统中，用来保证存储系统的数据状态的一致性

1.广义上的概念：一个事务的所有操作，要么都成功，要么都失败，没有中间状态
2.狭义上的概念：数据库的事务

特征：

ACID:原子性、一致性、持久性、隔离性

分布式事务：

在分布式系统中，每个节点都知道自己的事务状态，但无法知道其他节点的事务状态，这可能导致节点之间的状态不一致，因此事务需要跨越服务器节点，并且保证事务的ACID特性时，就需要一个“协调者”，各个进行事务操作的节点就是”参与者“

两种典型的分布式事务提交模式：2PC 和 3PC

2PC：两阶段提交	操作简单，事务的一致性保证没有明确，事务操作效率较低
3PC：三阶段提交	数据的一致性和执行效率更好

2.1 2PC两阶段提交

2PC （two-phase commit protocol，两阶段提交协议），2PC 是一个非常经典的强一致、中心化的原子提交协议，这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（partcipant）

简单来讲，两阶段提交就是

第一阶段做准备（发起事务、下派任务、执行任务）

第二阶段做提交（决定是否提交）

2.1.1 执行过程

第一阶段：请求/表决阶段

1.在分布式事务发起者向分布式事务协调者发送请求的时候，事务协调者向所有参与者发送事务预处理请求（vote request)
2.这个时候参与者会开启本地事务并开始执行本地事务，执行完成后不会commit，而是向事务协调者报告是否可以处理本次事务

在所有参与者都返回了正反馈后，协调者才会进入第二个阶段，否则收到了一个负反馈就通知所有参与者回滚事务

第二阶段：提交/执行/回滚阶段

分布式事务协调者收到所有参与者反馈后，所有参与者节点均响应可以提交，则同志参与者和发起者执行commit（提交），否则rollback（回滚）

2.1.2 2PC的优点

2PC原理简单，实现方便，有很多其他分布式技术都是基于2PC进行了改进，或者提供补偿方案来设计实现的

2.1.3 2PC的问题

第一点：性能问题（参与者同步阻塞）

从流程上可以看出，最大的缺点就是在执行过程中节点都处于阻塞状态，各个操作数据库的节点都占用着数据库资源，只有所有节点都准备完毕，事务协调者才会通知进行全局 commit/rollback，参与者进行本地事务 commit/rollback 之后才会释放资源，对性能影响较大

第二点：单点故障问题（协调者可能宕机）

事务协调者是整个分布式事务的核心，一旦事务协调者出现故障，会导致参与者收不到 commit/rollback 的通知，从而导致参与者节点一直处于事务无法完成的中间状态

第三点：数据不一致（消息丢失）

在第二阶段时，如果发生局域网络问题，一部分事务参与者收不到 commit/rollback 消息，那么就会导致节点间数据不一致

第四点：太过保守（没有容错机制）悲观

必须收到所有参与者的正反馈才提交事务，如果任意一个事务参与者的响应没有被收到，则整个事务失败回滚。没有容错机制

第五点：二阶段无法解决的问题

协调者在发出 commit 消息之后宕机，而唯一接收到这条消息的参与者也同时宕机了，那么即使协调者通过选举协议产生新的协调者，那么这条事务的状态也是不确定的，没有人知道是否已被提交

2.2 3PC三阶段提交

3PC（three - phase commit protocol，三阶段提交协议），是2PC的改进版，将其二阶段提交协议的”提交事务请求“一分为二，形成 cancommit、precommit、docommit三个阶段

除了在2PC的基础上增加了CanCommit阶段吗，还引入了超时机制，解决协调者的单节点故障问题，一旦事务参与者在指定时间内没有收到事务协调者的 commit/rollback 指令，就会自动本地 commit，这样可以解决协调者单点故障问题

1.相较于2PC来说，3PC在执行任务之前询问了各个参与者是否具备执行条件

如果有一个不具备条件则当前事务直接取消

2.在第二阶段时，在一定时长后依旧么有收到协调者的命令时，会自动进行本地模式提交

如果在超时之前收到了某个节点的负反馈，则执行回滚

第一阶段：CanCommit阶段（提交询问）

第二阶段：PreCommit阶段（预提交）

第三阶段：doCommit阶段（最终提交）

3PC的优点：

• 降低了二阶段的同步阻塞范围：只要接到了preCommit就会执行事务，此后除了回滚操作以外，就只有提交这一种选择，不会卡死在等待这个流程上
• 解决了单点问题：超时机制

1.3 其他分布式事务解决方案

在大数据的一些技术应用场景中，一般都是Paxos + 2PC 的改进实现

常见的分布式事务方案：2PC、3PC、TCC、本地消息、事务消息。还有阿里云开源的Seata分布式事务解决方案，PoW区块链共识算法等

3.分布式一致性算法详解

在分布式系统中，网络通信的异常情况是一定存在的（通信的延迟和中断，消息的丢失和延迟）但是上述的2PC和3PC依然有数据不一致的情况，意味着我们并不能在生产中直接使用2PC或者3PC，所以我们需要确保数据一致性的算法或者协议

分布式一致性算法：就算发生了网络分区（网络分区一定存在：消息的延迟和丢失的可能性一定有），也能保证分布式数据状态一致

3.1 Paxos算法

Paxos算法是莱斯利·兰伯特 1990年提出的基于消息传递且具有高度容错特性的一致性算法

是目前公认的解决分布式一致性问题最有效的算法之一**。Paxos算法解决的问题是一个分布式系统如何就某个值（决议）达成一致**。如何证明的具有高度容错——拜占庭将军问题

分布式系统中的节点通信存在两种模型：共享内存和消息传递。基于消息传递通信模型的分布式系统，不可避免会发生进程变慢被杀死、消息延迟、丢失、重复等问题，Paxos算法就是在存在以上异常的情况下仍能保持一致性的协议

Paxos 之于分布式一致性算法 类似于 Hadoop 之于大数据。自问世以来一直保持垄断地位

Mike Burrows 说过这个世界上只有一种一致性算法，那就是Paxos，其他算法都是Paxos不完美的版本

谷歌的很多大型分布式系统（）都采用了Paxos 算法来解决分布式一致性问题，ZK、mysql5.7的主从复制等都采用Paxos解决分布式一致性问题

Paxos以及Raft都假设不存在拜占庭将军问题，只考虑节点宕机、网络分区、消息不可靠等问题。属于CFT（Crash Fault Tolerance）算法

Paxos将系统中的角色分为 提议者（Proposer），决策者（Acceptor）和最终决策学习者（Learner）

• Proposer：提出提案（Proposal）。Proposal信息包括提案编号（Proposal ID）和提议的值（Vlaue）
• Acceptor：参与决策，回应Proposer 的提案，收到Proposal后可以接受提案，若Proposal获得多数Acceptors的接受，则称该Proposal被批准
• Learner：不参与决策，从Proposers/Acceptors 学习最新达成一致的提案（Value）

paxos算法通过一个决议分为两个阶段（Learn阶段之前决议已经形成）：

• 第一阶段：Prepare 阶段

  • Proposer 选择一个提案编号N，然后向半数以上的 Acceptor 发送编号为 N 的 Prepare 请求

  • 如果一个 Acceptor 收到一个编号为N的Prepare请求，且 N 大于该 Acceptor 已经响应过的所有 Prepare请求的编号，那么它就会将它已经接受过的编号最大的提案（如果有的话）作为响应给 Proposer，同时承诺不再接受任何编号小于N的提案

• 第二个阶段：Accept 阶段

  • 如果 Proposer 收到半数以上 Acceptor 对其发出的编号为 N 的 Prepare 请求的响应，那么它就会发送一个针对 [N,V] 提案的 Accept 请求给半数以上的 Acceptor。注意：V就是

• 第三个阶段：Learn 阶段

  • Proposer 在收到多数 Acceptors 的 Accept之后，标志着本次 Accept 成功，决议形成，将星辰高度决议发送给所有 Learners

Proposer 可以随时丢弃提案，并且提出新的提案；Acceptor 也可以随时响应，接受编号更大的提案。ZK巍峨了解决出现系统中出现多个Proposer互相提出你编号更大的提案而陷入”活锁“死循环状态的问题，提供了选举算法从众多 Acceptor推举一个唯一的proposer 用来主持分布式事务，从而解决分布式系统缺乏全局时钟的问题

映射到ZK上：

系统	提议者	决策者	学习者
Paxos	Proposer	Acceptor	Learner
ZooKeeper	Leader	Follower	Observer

在ZK内部，所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务 proposal，并将proposal分发给集群中所有的Follower服务器，之后Leader服务器需要等待所有的Follower服务器的反馈，一旦超过半数的Follower服务器进行了正反馈后，Leader再次向所有的Follower服务器分发commit消息，要求其将前一个proposal提交

paxos特点就是晦涩难懂，连作者Lamport的第一篇Paxos论文都没人看懂，工程时间落地也极其困难，所以Paxos算法衍生了多种变种实现，比如Basic-Paxos、Cheap Paxos、Fast-Paxos、Multi-Paxos等

• 所有Paxos都是Basic Paxos的变种
• Cheap Paxos是引入了辅助节点在那时替代宕机的工作节点，保证系统的可用，即节省资源又可以保证节点正常共识
• Fast-Paxos是在Basic Paxos的基础上直接让Acceptor Accept 而不必要经历proposer阶段，从而提高效率
• Multi-Paxos 是为了解决Basic Paxos一次只能就一个值达成共识的问题，高并发情况下 Basic Paxos 就不够用了，所以衍生出 Multi-Paxos可用一次执行多个Basic Paxos实例，就一系列值达成共识。Raft算法就是基于Multi-Paxos思想的共识算法

Paxos最终解决的问题：

• 当一个提议被多数派接受后，这个提议对应的值被Chosen（选定），一旦有一个值被Chosen，那么只要按照协议的规则继续交互，后续被Chosen的值都是同一个值，也就是Chosen值的一致性问题
• Paxos的目标：保证最终有一个提案被选定，提案被选定后，其他议员最终也能获取到被选定的提案
• Paxos协议用来解决的问题可以用一句话来简化：将所有节点都写入同一个值，且被写入后不再更改

3.2 Raft算法

Etcd 的底层实现：Raft 算法

http://thesecretlivesofdata.com/raft/

网页里：

Follower：没有边线：刚上线，大家都是Follower，每个节点启动之后，都有一个随机时间的倒计时器

Candidate：黑色虚线：如果 Follower 状态的节点倒计时结束了，则自动成为：Candidate候选人

Leader：黑色实线：当 Candidate 发起选举，并且成功当选 Leader的话，则更改状态为：Leader

过程：

1.所有节点一上线都是 Follower，并且拥有一个随机时间的计时器，当时间内没有收到Leader请求，则最快结束计时的Follower成为Candidate（候选人）

2.Candidate 发起选举请求，询问所有Follower是否同意Candidate成为Leader

3.Follower 反馈结果，正反馈为半数以上则当前 Candidate 成为 Leader

4.Leader 崩溃或出现异常时，其他 Follower 在随机时间内没有收到 Leader 请求时，成为 Candidate 并向其他Follower发送选举请求

5.数据请求发送给 Leader（每一次改变都会在节点日志中追加一条日志）

6.Leader 提交数据和日志请求给其他 Follower 节点，由 Follower 进行反馈，想要进行下一步需要 Follower 的正反馈超过半数

7.Leader 发送提交命令，Follower 接收命令后进行提交（如果超时未接到提交命令，Follower 自动提交）

Kafka-2.8.0开始使用Raft算法替换ZK的作用，从而摆脱对ZK的依赖

Raft是能够实现分布式系统强一致性的算法，每个节点有三种状态：Follower、Candidate（候选人）、Leader，Raft算法的最重要的两个工作：

• 选主：Leader Election
• 日志复制：Log Replication

3.3 ZAB协议

ZAB 全称 ZooKeeper Atomic Broadcast（ZAB,zookeeper 原子消息广播协议），是一种专门为了ZK设计的一种支持崩溃恢复 的 原子广播协议 是ZK保证数据一致性的核心算法，它的设计实现借鉴了 Paxos 算法原理，但是并不是一种通用一致性算法，是专门为了ZK设计实现的

ZAB协议的核心是 定义了对于那些会该改变ZK服务器数据状态的事务请求的处理方式，所有事务必须由一个 全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，余下的服务器则被称为 Follower服务器

• Leader 服务器负责将一个客户端事务请求转换为一个事务 Porposal（提案），并将 Proposal 分发给集群中所有的 Follower服务器
• Leader 服务器等待所有 Follower 服务器的反馈，一旦超过半数的 Follower 服务器进行了正反馈后，Leader 就会向所有的 Follower 服务器发送commit 消息，要求将前一个 Proposal 进行提交

Zookeeper 的底层工作机制，就是依靠ZAB实现的，实现 崩溃恢复 和 消息广播 两个主要功能

• 崩溃恢复：在整个服务框架启动过程中，如果 Leader 服务器出现 网络中断、崩溃退出或者重启 等情况，ZAB 协议就会进入 崩溃恢复模式，同时选举出新的 Leader 服务器，当产生了新的 Leader 服务器，同时集群中已有半数机器完成 状态同步（数据同步）后，ZAB协议会退出 恢复模式。选举算法通过 FastLeaderElection 实现
• 消息广播：当ZAB 退出崩溃恢复模式（LOOKING状态），就进入到 消息广播模式 （非LOKKING 状态：LEADING 或者 FOLLOWING 状态）在消息广播模式中，ZK集群可以接受客户端的读写请求，进行业务处理。消息广播通过 原子广播 实现

在ZK的源码实现中 有四个状态：

ELECTION 选举：各位ZK Server 一上线都是 LOOKING 则执行选举：已选举成功但是没有就任，即尚未确认，需要当前集群超过半数节点追随 Leader 才是合法的 Leader

DISCOVERY 发现：当选举算法结束（选举得到一个Leader），各位ZK Server 切换自己的状态未 LEADING 或者 FOLLOWING，需要超过半数节点确认该 Leader

SYNCHRONIZATION 同步：所有的 Follower 节点需要和 Leader 节点进行状态同步

BROADCAST 广播：当ZK集群中，有半数以上的节点完成了和 Leader 的状态同步之后，集群进入 BROADCAST 工作模式，处理客户端读写请求

总体流程：在Leader产生后不马上就任任务，先获得超过半数的Follower的追随，然后互相同步状态，最后接受读写请求

ZAB协议最终确保那些已经在 Leader 服务器上提交的事务最终被所有服务器都提交

ZAB协议需要确保丢弃那些只在 Leader 服务器上被提出的事务

如果让 Leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群中所有机器最高事务编号（ZXID）的事务 proposal，那么就可以保证这个新选举出来的 Leader 一定具有所有已提交的提案

4.抽屉原理/鸽巢原理

鸽巢原理，又名狄利克雷抽屉原理、鸽笼原理

其中一种简单的表述法为：

• 若有n个笼子和n+1只鸽子，所有的鸽子都被关在鸽笼里，那么至少有一个笼子有至少2只鸽子

另一种为

• 若有n个笼子和kn+1只鸽子，所有的鸽子都被关在鸽笼里，那么至少有一个笼子有至少k+1只鸽子

鸽巢原理与 Quorum 机制很类似

一个分区内最多放置两个数据，现在有三个数据，那么一个分区内至少有两个数据

将这个概念衍生

存在两个分区，一个分区放置两个有效数据，一个分区放置两个无效数据，当取分区时获取三个数据，那么无论如何，我们都可以获取到一个有效数据，这就不需要获取全部数据了

5.Quorum NWR 机制

Quorum NWR：Quorum 机制是分布式场景中常用的，用来保证数据安全，并且在分布式环境中实现最终一致性的投票算法，这种算法的主要原理来源于鸽巢原理，它最大的优势，即能实现强一致性，而且还能自定义一致性级别

N：复制的节点数，即一份数据被保存的副本数

W：写操作成功的节点数，即每次数据写入写成功的副本数。W肯定是小于等于 N 的

R：读操作获取最新版本数据所需的最小字节点数，即每次读取成功至少需要读取的副本数

NWR模型：N 个备份、至少要写入 W 份才算成功、至少读取 R 个备份

重要结论：这三个因素决定了 可用性、一致性 和 分区容错性。只需要保证（W + R > N）就一定能读到最新的数据，数据一致性级别完全可以根据读写副本数的约束来达到强一致性

6. CAP 定论 和 BASE 理论详解

6.1 CAP 理论

2000年7月份被首次提出，CAP 理论告诉我们，一个分布式系统不可能同时满足 C,A,P 三个需求

• **C：Consistency，强一致性：**分布式环境中多个数据副本保持一致
• **A：Availability，高可用性：**系统提供的服务必须一直处于可用，对于用户的每一个操作请求总是能在有限时间内返回结果
• **P：Partition Tolerance，分区容错性：**分布式系统在发生以外时，仍然需要保证对外提供满足一致性和可用性的服务

CAP只能三选二，因为在分布式系统中，容错性 P 是一定要有的，所有这时候无非就两种情况，网络问题导致的要么返回错误，要么阻塞等待，前者牺牲了一致性，后者牺牲了可用性

经验：

• 不要花费精力浪费在设计同时满足CAP的分布式系统
• 分区容错性往往是分布式系统必然要面对和解决的问题，所以应该把精力放在如何在 A 和 C 之间寻求平衡
• 对于单机软件，因为不用考虑 P，所以肯定是 CA 型，比如 MySQL
• 对于分布式软件，因为一定会考虑 P ，所以又不能兼顾 A 和 C 的情况下，只能在 A 和 C 之间做权衡，比如 Hbase，Redis等，做到服务基本可用，并且数据最终一致即可

基于以上考虑，产生了 BASE 理论

6.2 BASE 理论

多数情况下，并非一定要求强一致性，部分业务可以容忍一定程度的延迟一致，所以为了兼顾效率，发展出来了最终一致性的理论 BASE ，来自 ebay 的架构师提出，BASE 理论全称：Basically Available(基本可用)，
Soft state(软状态) 和 Eventually consistent(最终一致性) 三个短语的缩写。

既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式ilai使系统达到最终一致性（Eventual consistency），一句话概括，拒绝极端的 CAP 目的。

BASE 是对 CAP 理论中的 C 和 A 进行权衡得到的结果

1.不是强一致性，而是最终一致性
2.不是高可用，而是基本可用