【分布式】-理论篇 续

一、副本协议

中心化协议： 效率高，但是对中心节点的压力大，可用性低
去中心化协议：可用性高，但协议复杂，效率低

中心化副本控制协议

协议		应用
primary-backup	backup一般多为热备。通常是需要承担一部分读	主从复制：MySQL一主多从、Redis一主多从； raft协议；

去中心化副本控制协议

协议		应用
去中心化副本控制协议	所有的节点都是完全对等的	Paxos协议，Gossip协议；

• W+R>N，整个系统对于客户端的请求能保证强一致性。因为写请求和读请求一定存在一个相交的副本，读取的时候返回该副本的数据即可。
• W+R<=N，整个系统对于客户端的请求则不能保证强一致性。

二、一致性

write-all-read-one

WARO：在更新时写所有的副本，只有在所有的副本上更新成功，才认为更新成功

多数派

只要超过一半的节点写入成功，就返回成功

Quorum NWR机制 (动态一致性)

NWR是控制一致性级别的策略

N：分布式系统中，一个有多少个副本数据
W：处理一次写请求，需要更新多少个副本数据
R：处理一次读请求，需要读取多少个副本数据

主要针对更新操作

假设系统中有5个副本，W=3，R=3。	初始化数据为（V1,V1,V1,V1,V1） 成功提交的版本号为1

当发生更新操作在3个副本上成功后，就认为此次更新操作成功。
数据变为:（V2,V2,V2,V1,V1） 成功提交后，版本号变为2

因此，最多只需要读取3个副本，一定能够读到V2此次更新成功的数据，再根据版本号抉择。

分析

• 如何读取最新的数据：
  • 在已经知道最近成功提交的数据版本号的前提下，最多读R个副本就可以读到最新数据
• 如何确定最高版本号的数据是一个成功提交的数据：
  • 读取其他的副本，一直读到最高版本号副本出现了W次。
• 如何处理同步过程中冲突的数据：
  • 需要视情况分析：比如（V2,V2,V1,V1,V1）, R = 3,如果读取的3个副本是：（V1,V1,V1）则高版本的V2需要丢弃。
  • 如果读取的3个副本是(V2,V1,V1)，则低版本的V1需要同步到V2。

三、分片

分片方式

1.水平分片：hash等
2.垂直分片
3.混合分片

分片策略

五、心跳检测

由于网络分割，没有任何技术能可靠的判定节点状态！

普通心跳检测

在规定的时限内定期向检测节点发送存活性报告，若超出一段时间未能收到心跳报告，那么检测节点则判断节点可能失效，并采取一系列措施（报警）

Lease的心跳检测

原理：中心服务器发放密钥的时候，同时发放一个 lease 承诺在一定时间内不修改该密钥。

• 本地系统获取密钥时，同时根据 lease 的约定只在其有效期内使用密钥，lease 一旦过期立刻重新申请密钥。
• 当变更密钥时，在所有已颁发的 lease 全部过期前修改不能生效，并且在变更密钥生效期间不能颁发新的 lease，避免形成活锁（永远等不到所有 lease 失效）。

lease 机制的状态检测，可以避免【误判后引入新问题】。如果没有Lease，分布式环境中的锁可能会因为锁拥有者的失败而导致死锁，有了lease死锁 会被控制在超时时间之内。

时钟问题，lease 机制依赖于分布式环境下的服务器时钟同步
（1）中心服务器时钟比客户端系统快：这种情况下，中心服务器将 lease 过期时，客户端服务器还在使用。在这个时间差范围内如果中心服务器变更了密钥，会导致客户端服务器的密钥错误造成服务不可用。这种情况可以设置 lease 颁发者（中心服务器）的有效期设置的比接收者（客户端）更大，大过时钟误差。

（2）中心服务器时钟比客户端系统慢：这种情况下，客户端将 lease 过期时中心服务器还未过期，客户端只需重新发起新的 lease 申请即可，如果此时遇到中心服务器正在进行密钥更新锁定不能颁发 lease，则可只返回当前的密钥数据，而不颁发 lease。客户端将在这个时间窗口中退化为每请求一次性的使用该密钥数据。

lease机制 是一种协议承诺

如果协议内容是 确认客户端存活，那么这个租约就相当于心跳。
如果协议内容是 保证内容不会被修改，那么这个租约就相当于读锁。
如果协议内容是 保证只能被某个客户端修改，那么这个租约就相当于写锁。

调参：一般承诺有效期为1-10秒
应用：GFS采用了 lease 机制

参考

分布式一致性协议 - CAP、BASE、NWR
Lease的原始论文<<Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency>>
lease机制
分布式一致性协议Lease机制