分布式理论

1 CAP定理

1. 一致性（Consistency）：所有节点访问时都是同一份最新的数据副本（强一致性）。
2. 可用性（Availability）：每次请求都能获取到非错的响应，但是不保证获取的数据为最新数据。
3. 分区容错性（Partition tolerance）：分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。

CAP三者如何权衡

1. 分布式系统下，经常会出现网络问题，所以分区容错性是比须满足。不然容易因为网络分区导致系统不可用。
2. CP：满足分区容错性之后选择一致性，会牺牲一部分未同步数据节点的可用性。适用于一些银行业务要求强一致性的场景。
3. AP：满足分区容错性和可用性，可能会出现节点数据不一致场景。适用于电商对可用性要求高的业务。
4. CA：放弃分区容错性。不能容忍网络错误或者分区问题，一旦出现就会拒绝请求。

2 Base理论

Base理论是对CAP理论一致性和可用性权衡的结果。

1. Basically Available(基本可用)：允许响应上的损失，响应时间变长；允许功能上的损失，降级处理。
2. Soft state（软状态）：允许数据存在中间状态，就是节点之间允许存在短暂的数据不一致。
3. Eventually consistent（最终一致性）：数据允许一定期限的软状态，期限过后，所有副本的数据需要达到一致。

3 分布式一致性协议

两阶段提交协议（2PC）

1. 2PC协议存在Prepare和Commit两个阶段
2. Prepare阶段：协调者向各参与者询问是否可以正常执行事务，参与者执行事务，但未提交事务，然后向协调者进行响应。
3. Commit阶段：协调者根据参与者的响应决定事务是commit还是callback。向参与者发送commit或callback请求。
   

2PC存在问题

1. 同步阻塞：在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，即当参与者占有公共资源时，其他节点访问公共资源会处于阻塞状态。
2. 单点问题：若协调器出现问题，那么整个二阶段提交流程将无法运转，若协调者是在阶段二中出现问题时，那么其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成事务操作
3. 数据不一致：2阶段commit时候，如果有部分参与者未收到协调者进一步的请求，会导致数据不一致情况。
4. 太过保守：协调者收不到参与者响应时，只能通过超时机制进行判断是否需要中断事务。

三阶段提交协议（3PC）

1. 第一阶段（CanCommit 阶段）：协调者询问参与者事务是否可以正常执行。
2. 第二阶段（PreCommit 阶段)：协调者根据参与者的反应情况来决定是否可以执行事务的PreCommit操作。决定是进行事务预提交还是abort中断事务请求。
3. 第三阶段（doCommit 阶段）：根据二阶段响应决定提交事务还是回滚事务。此阶段若参与者超时未收到协调者的请求，则会自己进行事务的提交。
   

3PC的优缺点

1. 协调者也引进了超时机制，避免了长时间未收到协调者的请求导致的资源占用。
2. 增加了一个阶段进行事务提交前的确认。
3. 依旧未解决数据一致性问题。

4 NWR协议

1. N：在分布式存储系统中，有多少份备份数据
2. W：代表一次成功的更新操作要求至少有w份数据写入成功
3. R： 代表一次成功的读数据操作要求至少有R份数据成功读取
4. 当W+R>N时，可以保证数据的强一致性。这样成功写和成功读的数据保证有交集。

5 Gossip协议

1. Gossip 协议也叫 Epidemic 协议 （流行病协议）。原本用于分布式数据库中节点同步数据使用，后被广泛用于数据库复制、信息扩散、集群成员身份确认、故障探测等。
2. gossip 协议利用一种随机的方式将信息传播到整
   个网络中，并在一定时间内使得系统内的所有节点数据一致。Gossip 其实是一种去中心化思路的分布式协议，解决状态在集群中的传播和状态一致性的保证两个问题。

传播模式

1. 反熵传播：是以固定的概率传播所有的数据。所有参与节点只有两种状态：Suspective(病原)、Infective(感染)。过程是种子节点会把所有的数据都跟其他节点共享，以便消除节点之间数据的任何不一致，它可以保证最终、完全的一致。缺点是消息数量非常庞大，且无限制；通常只用于新加入节点的数据初始化。
2. 谣言传播：是以固定的概率仅传播新到达的数据。所有参与节点有三种状态：Suspective(病原)、Infective(感染)、Removed(愈除)。过程是消息只包含最新 update，谣言消息在某个时间点之后会被标记为 removed，并且不再被传播。缺点是系统有一定的概率会不一致，通常用于节点间数据增量同步

6 Paxos协议

Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一。
Paxos通过引入多个协调者，解决2PC和3PC协调者单点的问题。

Basic Paxos

1. Proposer提出一个提案,编号为N, 此N大于这个Proposer之前提出所有提出的编号, 请求Accpetor的多数人接受这个提案
2. 如果编号N大于此Accpetor之前接收的任提案编号则接收, 否则拒绝
3. 如果达到多数派, Proposer会发出accept请求, 此请求包含提案编号和对应的内容
4. 如果此Accpetor在此期间没有接受到任何大于N的提案,则接收此提案内容, 否则忽略

存在问题

1. 需要两次RPC调用
2. 多个提案者并发时可能存在活锁问题。可通过随机时间进行避免

Multi-Paxos

1. 首次提案时确定Acceptor议员的leader，后续直接由leader确定提案是否成功。只有首次提案需要次RPC，后续只需要一次RPC调用
2. Multi-Paxos协议的落地方案有Raft和ZAB

7 Raft协议

1. 竞选阶段：Follower会有一个定时时间，这个时间到达还未收到Leader节点的心跳信息，Follower就会成为 Candidate节点。 Candidate会向其他节点发送投票信息（携带任期），当收到过半票数就会成为Leader，并且会周期性的向其他节点发送心跳。
2. 多个 Candidate节点：当同时出现多个 Candidate时，可能会出现相同票数导致重新选举，这样通过给一个随机竞选超时时间，避免出现多个 Candidate。
3. 日志复制：Leader节点收到数据更新请求后，修改数据后并不会立刻提交，需要同步多数的Follower节点进行修改后，才会进行提交，然后通知Follower节点提交。
4. 网络分区：网络问题导致部分节点收不到Leader节点心跳，这些节点会重新进行选举。
5. 网络分区日志复制：分区下节点数量少的，可能因为更新数据时候达不到过半节点的同意，导致无法更新数据。当分区合并时，选取任期大的分区主节点作为Leader节点，然后进行数据的同步。

8 Lease机制

1. 什么时Lease机制？节点向Lease颁发者申请Lease，申请成功的作为Leader节点，Lease保证这个节点这段时间内都会是主节点。
2. 解决了什么问题？防止主节点因为网络短暂问题（未宕机），与其他从节点失去联系，而其他从节点马上进行了选举新的主节点。采用Lease机制，在主节点Lease的有效期内，其他节点无法申请到Lease。保证同一时刻只有一个主节点。
3. Lease的租期不宜过长，不然主节点真出现问题，系统可用性就降低了。