分布式系统原理介绍读书笔记

一、数据分布方式

1. 哈希方式：1）按照数据的某一特征计算哈希值 2）哈希值与服务器建立对应关系

优点：需要记录的元数据信息非常简单，只需要知道哈希函数的计算方式和服务器的数量

缺点：1）扩展性不好，服务器数量增加，数据都需要迁移 2）万一某一特征值的数据分布不均匀，会导致数据倾斜

2. 按数据范围分布：1）将数据按特征值划分为不同的区间 2）每台服务器处理不同区间的数据 3）某区间数据太多会分裂成两个区间，迁移到其他机器

缺点：元数据信息较大，需要多台机器维护

3. 按数据量分布：1）数据为一个增加的文件 2）将文件按一定大小分块分布到不同服务器

优点：1）无数据倾斜问题 2）负载均衡简单，迁移数据块即可

缺点：需要维护较大的元数据信息

4. 一致性哈希：1）按某哈希函数计算数据某一特征值的哈希值 2）哈希值域为一封闭的环 3）环上有许多虚拟节点，节点数远大于未来集群中服务器数量 4）每个节点负责从自己节点开始，顺时针到下个节点之间的哈希值映射的数据 5）每个真实节点对应若干虚拟节点，数据落到虚拟节点上即落到对应的真实节点上面

优点：1）负载均衡较好：某真实节点不可用，导致多个虚拟节点不可用，压力被分摊到旁边的虚拟节点上，多台真实节点分摊压力；某节点加入，分配多个虚拟节点，分摊多台真实节点压力 2）需要维护的元数据量小

GFS: 按数据量分布。master检查当前副本情况，对负担较重的chunkserver上的副本进行迁移。同时，新的chunkserver加入时，也会将数据库慢慢迁移来填充它。

二、副本与数据分段

假如副本数量为3，则将该份数据切成N份数据段，以这些数据段为单位管理副本。

优点：数据丢失后数据恢复较快

三、副本协议

primary-secondary协议：

1. 数据更新：GFS为例，1）client询问master 哪个是primary 2）master回复client，之后client与primary联系 3)primary收到来自各个client的变异请求，为请求排序，发送到secondary副本 4）secondary副本之间接力传递 5）secondary副本严格按顺序执行变异 5）primary回复client执行变异是否成功

2. 数据读取：

思路：1）只读取primary上的副本 2）primary控制secondary是否可用：secondary更新失败为不可用，secondary与primary更新完数据后为可读 3）quarum机制来读数据

3. primary的确定与切换：lease机制确定primary是否宕机；quarum机制确定新的primary

4. 数据同步：

情形：1）secondary上落后：回放primary上的日志，追上primary 2)脏数据，secondary有多余的修改：丢弃副本/undo 3)secondary为新增加的副本，没有数据：拷贝快照？？+回放日志

四、lease机制

时钟的问题？

GFS中，master给primary颁发lease，承认他是primary。若primary异常，只要等到lease过期即可选出下一个primary。

五、WARO机制

更新：所有副本更新成功，则成功，有一个不成功，则更新失败

读：有一个副本正常，就可提供读服务

可用性较低

六、quorum机制

N个副本，W个副本更新成功则该数据算是更新成功，读取R个副本，一定能读到最新版本的数据。（N+1=W+R）

但无法保证读取到的数据是否为更新成功的数据，因为v2可能仅在一个副本上更新成功了。

加强版：读R个副本后，若v2有w个，则v2为最新版本；若少于w个，继续读，知道读到w个v2才算v2是最新版本，否则，版本号第二大的v1为最新版本。

quorum机制选择primary:

primary异常，中心节点与其他副本通信，读取R个副本，版本号最高的为最新数据，该副本为primary。primary与其他副本同步数据，发现其他副本更高版本的数据，有可能会被作为脏数据删掉；若primary拥有版本较高，则更新其他副本

GFS系统用的是WARO机制，但是有改进，利用record append，失败重试。虽然有重试造成的重复数据，但所有副本都有相同的偏移量。客户按这个偏移量一定能找到自己更新的数据。

Zookeepr的quorum。。

七、日志技术

流程：利用snapshot快速生成内存快照，先在日志中写入begin check point，开始dump快照中的数据到硬盘，结束后再在日志中写入end check point。

（这样可以做到dump的数据一定不包含begin check point之后的数据）

恢复流程：将dump的数据加载到内存；找到最新的end check point，再找到它之前的begin check point，回放从begin check point之后的日志

GFS: checkpoint snapshot redo log

八、两阶段提交（事务提交）

事务处理

1）阶段一：协调者询问参与者是否可以参数提交事务，参与者回复协调者是否可以参与事务提交

2）阶段二：协调者根据参与者回复的情况决定是否可以全局提交事务，并通知参与者执行

若都回复可以，协调者向参与者发送提交命令，参与者收到后回复协调者；若有一参与者回复不可以，则整个事务提交操作被放弃。

协调者宕机恢复：根据宕机前的状态，继续发送prepare或global-commit/global- abort 即可

参与者宕机恢复：等待接收协调者不断发送的prepare或global xx 消息并回复；重新发送vote-commit/vote-abort消息

协调者超时处理：等待参与者回复global-xx请求超时，只能不断继续发global-xx请求，继续等回复

参与者超时处理：参与者已经ready，在等待协调者发global-xx请求超时，只能不断发vote-xx请求，继续等回复

九、MVCC（分布式事务）

写数据：1）各节点记录事务的更新操作和版本号 2）当所有节点都更新成功后，全局元信息记录事务的版本号。

读数据：1）读取元信息最大事务版本号，再到各节点读取数据。所以，不会读到还没有完全执行完的事务。

各节点保存的是数据的更新操作，即增量，需计算得出各版本的数据。

仅保存更新操作会使元数据信息过于庞大，所以会定期合并较早版本事务的数据。

十、paxos协议

proposer: 提议者

acceptor: 批准者，一个value需要被半数以上的acceptor批准才能通过

规则：1）paxos协议一轮一轮的来，每一轮有一个编号，每轮paxos协议可能批准一个value也可能没有一个批准的value；2）一旦paxos批准了某个value，后面的paxos都只能批准这个value。

(注：轮数：B=b，批准的值： V=v)

proposer	acceptor
发起一轮paxos，广播prepare(b)
	收到prepare(b)
	case1: b小于自身收到的版本号B，回复reject(b)
case1: 收到reject(b):放弃，重新发起一轮
	case2: b>自身版本号B，设置B=b，回复promise(b,v)（ 注：将自身的值v一起广播出去）
收到promise(b,v)
case2_1: 未收到过半的promise(b,v)，不能广播accept，重新发起？
case2_2: 收到超过半数的promise(b,v):  1）若v=null，则proposer可以设置V=v1作为新值,并向acceptor广播accept(b,v1); 2）若v有值，则选择最新批准的v作为批准的value,并广播accept(b,v)
	收到accept(b,v1)（注：或accept(b,v)）
	case3: b小于自身收到的版本号B，回复Nack(b)
case3: 收到Nack(b)，重新发起一轮paxos
	case4: b>自身版本B，设置V=v1，并广播accepted