【分布式】分布式基础知识

分布式系统

基本知识

CAP

概念

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本)

可用性（A）：保证每个请求不管成功或者失败都有响应。

分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。

在一个分布式系统中，三者不可兼得，要么AP，要么CP，要么AC。

例子

• AP：Eureka
• CP：Zookeeper

2PC

概念

是一个原子提交协议。由一个协调器（coordinator）来协调参与者（participant）之间的分布式事务。有两个阶段：

1. 投票阶段

   （1）coordinator询问各个participant，是否可以进行事务，等待participant回复。

   （2）participant进行事务准备工作，并返回Yes/No给coordinator。

   （3）如果coordinator接收到了No，事务不执行；全部为Yes，进入下一阶段。

2. 提交阶段

   （1）coordinator发出提交命令，participant进行事务提交，如果participant中有提交失败的就返回No，否则返回Yes。

   （2）当coordinator接收到No或者等待超时后，发布Rollback命令；否则事务成功。

   （3）参与者接收到Rollback命令后，进行事务回滚。

缺点

• 单点故障：太依赖coordinator，当coordinator宕机后，participant无法完成事务。
• 性能问题：在2PC过程中，participant只有当接收到提交命令才会提交，而在这之前，会导致资源一致被占有，从而降低性能。

3PC

概念

是2PC的升级版。也是由一个协调器（coordinator）来完成，只是对协调器的依赖没2PC大。将2PC额外分了一个阶段：

1. 投票阶段：与2PC类似
2. 预提交阶段：在participant上也加了超时，时间一过还没提交的话就会释放资源。当参与者收到预提交命令后，都会进入预提交状态，返回Yes；否则返回No。
3. 提交阶段：与2PC类似

与2PC的区别

避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题。

Paxos

概念

是一个解决分布式系统中，多个节点之间就某个值（提案）达成一致的通信协议。它能够处理在少数节点离线的情况下，剩余的多数节点仍然能够达成一致。主要有三种角色：

1. Proposer（提议者）：向集群提出提案
2. Acceptor（接收者）：对提案进行投票，当票数比一半多的时候，就会被接受
3. Learner（提议接受者）：记录接受的值，不参与投票

一个服务器既可以是Proposer也可以是Acceptor。

Paxos主要分为两个阶段：

1. Prepare阶段

   （1）Proposer发送全局唯一且递增的提案编号给所有Acceptor服务器。

   （2）Acceptor收到编号后，在本地持久化当前编号，做出以下逻辑：

   if id > oldId then oldId = id;
   return acceptedProposal;	//返回已经接受的提案内容（可能为null）
   

   并保证：

    不再回应 <= 当前编号的prepare请求（当Proposer被拒绝的时候，会提高编号继续提交）
    不再回应 < 当前编号的accept请求
   

2. Accept阶段

   （1）Proposer收到Prepare阶段多数派的应答之后，选择其中编号最大的提案内容，作为本次Accept的提案内容，如果内容为null，就自己决定提案内容，然后以当前编号发送给所有Acceptor服务器。

   （2）Acceptor收到Accept请求，在上述保证的前提下，返回已接受的提案内容和编号。
   

缺点

当某一个Proposer提交提案被拒绝时，会增加当前提案编号，继续提交，若在上一个Proposer的accept请求前完成，会导致上一个Proposer失败，提升它的提案编号，从而形成提案编号一直增加的情况。

解决方法：可以通过延迟（不同时间）提交的方法解决。

Raft

http://thesecretlivesofdata.com/raft/

概述

是一个用于管理日志一致性的协议协议，分为三种角色：

Leader（领导者）：接受请求，向Follower通过请求日志。

Follower（跟从者）：接受并持久化Leader的日志，当收到Leader的日志提交之后，提交日志。

Candidate（候选者）：临时角色，当Follower超时没收到Leader的信息后，会自动成为Candidate。

Raft使用逻辑时间term来记录Leader的任期，保证每个任期内最多只有一个Leader。

Leader选举

1. 当一个Leader宕机或者因为网络原因影响之后，Follower超时时间（150~300ms）内没收到Leader的信息，就会成为Candidate，向每个其他节点发送投票信息。
2. 当其他节点收到投票信息后，只会同一第一个收到的投票信息。
3. Candidate收到投票信息后，如果票数为多数，就成为Leader；如果当时也有其他Candidate并且票数相同，就在随机的一段不同时间间隔之后，重写进行投票选举。
4. 此时若上一个Leader重新恢复，这时系统中有两个Leader（脑裂问题），他们会根据term进行比较，大的为Leader。

日志复制

1. 客户端发起一个请求，Leader收到并记录到日志中，向其他Follower同步日志。
2. Follower将该记录添加到日志中并反馈给Leader
3. Leader若收到大多数的同步成功，就将应用该记录到状态机中，并将结果返回给客户端同时给Follower发送提交信息。
4. Follower收到提交请求并将该记录提交，反馈给Leader。如果Leader在一段时间内没收到大多数的提交成功，就会继续发送。