数据复制与一致性

基本原则与设计理念

原教旨CAP理论

CAP是什么：

1. C：强一致性，在分布式多副本情况加，对数据的根性与单副本是一样的。
2. A：可用性，即容错，任何时刻都能在一定事件内完成服务
3. P：分区容忍性，出现网络分区现象，即分区间的机器无法通信，这种情况仍然能够继续工作。

为什么CAP三者不能兼得？因为在通常网络下，P是必然会发生的，我们可以将问题转换为：若已得到P，那么C,A是否可以兼得。

我们可以分情讨论：

1. 如果只存在一个副本

这种情况我们显然可以得到C，但是如果集群中某些机器宕机，肯定不能得到A。
2. 如果集群中有多个副本

假设变量x=2存储在机器A，B上。某一时刻我们把机器A上的变量x更新为1。如果此时机器A，B之间的网络分区不可达，不能即使地将机器B也更新为1.我们不得不在A，C之间做权衡。如果选择A，那么此时x的值处于不一致状态；如果选择C，那么此时应该拒绝对机器B中x值的读请求。所以无论选择哪一个，必将抛弃另外一个。

CAP重新解读

1. P出现的概率很小，不应该为了P在一开始就放弃C，A。
2. 在设计之初应该为了同时满足CA而努力，如果出现网络分区，应该使系统进入P模式，进行取舍不一致状态提供服务，当网络分区现象结束，重新进入CA提供服务。

ACID原则

数据库中的基础理论。

这里的C也代表一致性，但是和分布式系统的一致性上不一样的。

BASE原则

关系数据库采用ACID，获得了强一致和高可用。然而在云存储系统中采用BASE原则。具体而言，BASE原则是指：

1. B(Basically Available)：大多数时间保证可用，偶尔失败
2. S(Soft State)：指数据状态不要求任何时候都保证完全同步，处于有状态(State)和无状态(Stateless)之间
3. 最终一致性(Eventual Consistency)：给定时间窗口内达到一致

BASE原则上通过牺牲强一致性来满足高可用性。目前一般的分布式系统采用的方案上在全局满足BASE原则，局部满足ACID。

CAP/ACID/BASE之间的关系

1. CAP中的强一致性表现为在任何时候都像单副本一样，是ACID中C的子集。
2. 当出现网络分区的时候，不可能满足事务，因为事务的序列化需要网络通信。
3. 当出现网络分区，应该尽可能地在每个分区执行ACID，等网络分区借宿后恢复。

• YY一个问题，为什么关系数据库的ACID不能兼容P:

因为事务需要序列化，不能容忍网络分区。

幂等性

很重要的一个概念，先记住吧：

调用方反复调用某个操作和一次调用某个操作的结果相同。

一致性模型分类

强一致性：如果某进程对数据进行了更新，所有进程的后续操作都以这个进程为基准。更新过程中可能会出现不一致的状态。

最终一致性：需要一段时间后才能达到强一致状态，这段事件称为不一致窗口。

因果一致性：

读你所写一致性：因果一致性的特例，相当于Notify(A, A)，自己通知自己。

会话一致性：读你所写一致性的特例，相当于在同一个会话内保证读你所写一致性，但是不同的会话不保证。

单调读一致性：保证读操作的序列化

单调写一致性：保证写操作的序列化

一般满足读你所写一致性和单调写一致性

副本更新策略

分为同时更新，主从更新，任意节点更新

同时更新

1. 不使用一致性协议：缺点，可能存在不一致状态；优点：速度快
2. 使用一致性协议：缺点：一致性协议延时高；优点：保证一致性

主从更新

1. 同步方式：主副本等所有副副本更新完成后才确认。
2. 异步方式：主副本在通知副副本之前即可确认。分为两种情况
   1. 所有读请求都通过主副本来响应，对副副本的请求会转到主副本，这样可以保证强一致性。
   2. 任意副本响应，可能出现不一致。
3. 混合方式：同步更新部分节点，然后异步更新剩余节点。
   1. 如果读请求必须从同步节点响应，强一致性
   2. 如果可以从异步节点响应，不一致状态

任意节点更新

数据请求先发给任意副本，再由这一副本同步

1. 同步方式：同主从更新同步方式
2. 异步方式：同主从更新异步模式

一致性协议

2PC（两阶段提交）

两阶段提交通常用于保证数据更新的原子性。由一个协调者和众多参与者组成

1. 协调阶段：

• 协调者视角：协调者向所有参与者提交一个VOTE_REQUEST消息
• 参与者视角：当参与者收到VOTE_REQUEST，参与者预先自身执行一遍事务（不提交），根据自身是否成功回应参与者

2. 提交阶段

• 协调者视角：如果所有参与者同意，那么向所有参与者发送提交请求；如果任意一个参与者不同意提交，参与者向所有协调者发送取消事务
• 参与者视角：如果收到GLOBAL_COMMIT，那么提交事务；如果受到GLOBAL_ABORT，取消本次事务

优点：原理简单，实现方便

缺点：同步阻塞，单点问题，脑裂，太过保守

1. 同步阻塞：两阶段提交是一个阻塞协议
2. 单点问题：协调者是单点，如果在提交阶段协调者宕机，参与者不能明确知道此时是否应该提交事务。
3. 数据不一致：在提交阶段，可能出现数据不一致
4. 太过保守：没有容错，任何一个节点失败导致整个事务的失败

3PC（三阶段提交）

核心思想是将协调阶段一份为二

阶段一：CanCommit

1. 协调者：向各个参与者发送CanCommit请求
2. 参与者：接受来自协调者的CanCommit请求，如果认为（应该不会预先执行）可以执行，返回yes，否则返回no

阶段二：PreCommit

• 如果所有参与者返回yes

1. 协调者：向所有参与者发送PreCommit
2. 参与者：收到PreCommit，参与者预先执行一遍事务（不提交），根据自身是否成功返回协调者

• 如果有参与者返回no

1. 参与者：发送abort请求
2. 协调者：收到abort或者等待超时，都终止事务

阶段三：doCommit

• 上一阶段都反馈yes

1. 协调者：发送提交请求，等待所有ACK，然后提交事务
2. 参与者：接受到协调者的请求，提交事务。完成事务后发送ACK。

• 上阶段有参与者反馈no，或者等待超时

1. 协调者：发送abort
2. 参与者：收到abort，终止提交；超时，提交

自己的理解：

向量时钟

向量时钟只有一个原则，发送，接受，进程内部事件，在当前进程的下标上加1。用于判断时间发生的先后顺序，不能完全判断所有事件。

RWN协议

1. N：在分布式系统中，有多少备份数据
2. R：代表一次成功读，至少有R份才算成功
3. W：代表一次成功写，至少有W份才算成功

如果 R + W > N，这样肯定能保证数据的强一致性。可以根据不同的需求，配置R，W，N

paxos协议

首先介绍副本状态机模型

一致性协议的作用就是保证各个Log副本数据的一致性，即所有服务器的内部状态保持一致，那么这种方式使得整个集群对于外部客户端就像单机一样。

paxos基本概念

1. 倡议者(Proposer)：倡议者可以提出提议以供投票表决。
2. 接受者(Acceptor)：接受者可以对倡议者提出的提议进行投票表决，从众多提议选出唯一的那个。
3. 学习者(Learner)：学习者无投票权，但可以从接受者获得哪个提议被选中。

1. 获取一个ProposalId,为了保证ProposalId递增，可以采用时间戳+serverId方式生成(我觉得这样生成id不保证可靠)；
2. 提议者向所有节点广播prepare(n)请求；
3. 接收者比较n和minProposal，如果n>minProposal,表示有更新的提议，minProposal=n；否则将(acceptedProposal,acceptedValue)返回；
4. 提议者接收到过半数请求后，如果发现有acceptedValue返回，表示有更新的提议，保存acceptedValue到本地，然后跳转1，生成一个更高的提议；
5. 到这里表示在当前paxos instance内，没有优先级更高的提议，可以进入第二阶段，广播accept(n,value)到所有节点；
6. 接收者比较n和minProposal，如果n>=minProposal,则acceptedProposal=minProposal=n，acceptedValue=value，本地持久化后，返回；否则，返回minProposal
7. 提议者接收到过半数请求后，如果发现有返回值>n，表示有更新的提议，跳转1；否则value达成一致。

• 另外一种表述

阶段一

1. 提议者：发起Prepare(n)
2. 接受者：
   1. if(n > all Prepare) return n;
   2. if(n < all Prepare) 无响应；
   3. 接受者已经Aceept，返回{Accept编号，值}

阶段二(提议者接受大多数有关提议编号n的回复)：

1. 提议者：发起Accept(提议编号n，提议值v)
   1. v选择已经Accept中编号最高的n的提议值，否则v任意
2. 接受者：
   1. if(n >= all Prepare) 接受，返回n
   2. if(n < all Prepare) 返回最大提议编号

注意：

1. 在提议阶段，接受者可能已经Accept
2. 在接受阶段，接受者可能收到新提议
3. 日志内容读取，也需要再走一遍basic paxos协议(因为paxos协议并不保证原子性，防止读到未提交的日志？)

Multi Paxos 协议

一个Basic Paxos运行完，通过多次协议交互，只能对一件事情达到一致。因此，为了加快达成一致的速度，multi-paxos协议通过选举出一个leader，只能由leader发起提议，这样跳过了第一阶段。Leader宕机重新选出Leader

raft

同样基于大多数投票的选举算法。它可以发起一系列日志，所以它对标的是multi-paxos。它将一致性协议分成几个关键模块，例如，领导人选举、日志复制和安全性。

安全性保证:

1. 只有包含所有已提交操作的命令的服务器才有权选举为行的领导者
2. 只有它自己提交当前term的操作才能看作是真正的提交。(leader只有提交了当前term号的日志后才能将之前的日志应用到状态机)