数据分布协议：使用维度各有利弊
哈希(更新起来要成倍迁移)
一致性哈希(环哈希，易实现负载均衡)
数据量(元数据多，类似B树的中间节点)
数据范围(也是元信息多)
基本副本协议：
中心化(primary-secondary)(中心节点负责维护数据的更新、并发控制、协调副本的一致性)
去中心化
一个节点向另一个节点发起RPC的状态有成功，失败和超时
lease机制，最重要的分布式协议，重要的应用在于判定节点状态。通过颁发一个有效期，经验证通常为10s，并且通常中心节点互为副本，成为一个小的集群，具有高可用性，对外颁发lease。
primary-secondary架构：
只允许有一个primary，Q为Master节点，A为当前primary节点。
心跳包的缺点：一个节点Q超过一定时间接受不到A的心跳则认为异常，但其实有可能是Q与A之间的网络中断，网络拥塞，或者Q异常，也就是Q认为A有问题，但A不认为自己有问题。
此时Q将primary分配给B，并通知所有节点primary为B。
但由于通知的顺序问题可能或出现双primary问题，双主问题会出现严重的数据错误。
分布式协议依赖于对节点状态认知的全局一致性，即一旦节点Q认为节点A异常，那么A也需要认为自己异常，从而停止作为primary
改进：A，B，C节点还是通过心跳给Q传递信息，给每个节点颁发lease，给primary节点颁发特殊的lease。
分布式协议可以容忍双主错误，即不依赖于对节点状态的全局一致性的认知。(去中心化)
我们现在依赖于Zookeeper这样的开源的高可用系统，简单的实现高效的、无单点选主的、状态监控、分布式锁、分布式消息队列等功能。依赖于zookeeper与client之间的lease。
日志技术：常用于分布式数据库
redo log幂等性 具有check point
undo log
redo/undo log
no redo/no undo log也称为是0/1目录
两阶段提交协议：
经典的强一致性中心化副本控制协议
在分布式数据库上，有一些副本可以顺利提交，但有一些可能会失败
两阶段涉及的对象有一个中心化的协调者节点和N个参与者节点，参与者节点也就是管理副本的节点
第一阶段：协调者询问所有的参与者是否可以提交事务，所有参与者向协调者投票
第二阶段：协调者根据所有参与者的投票结果做出是否事务可以全局提交的决定，并通知所有参与者执行这个决定(只要有一个参与者不OK那就放弃，选择放弃(abort)事务)
协调者宕机恢复 如果最后是begin_commit，则说明宕机前协调者处于wait状态，因此重新发送prepare消息即可。如果最后是global_commit或者是global_abort，那么重新发送global_commit或者是global_abort即可继续两阶段提交流程
参与者宕机恢复 如果是init则等待协调者发来的prepare消息即可，如果是ready那么是vote_commit,如果是global_xx,则不影响等待协调者发过来即可
容错差，易阻塞，交互太多很麻烦，理论意义大于实践意义
MVCC：多版本并发控制技术
使用的方法有复制，也就是类似SVN的check out操作
还有增量，也就是类似SVN的增量提交
事务靠日志或者是MVCC技术实现
时间戳，ID序列号，还有版本合并，如果这个版本没有修改过对应版本修改过的数据，那么可以进行合并。
Paxos
高可用，强一致性的去中心化的分布式协议
拥有一组完全对等的参与节点，他们就某一件事作出决议，如果该决议获得了超过半数节点的同意则生效。
只要有超过一半的节点正常，就可以工作，能很好的对宕机，网络分化等异常情况。
WARO与Quorum
WARO所有副本更新成功才可以成功
Quorum大部分更新成功即可
补新学到的心跳出血bug：是指每次服务器端传输心跳包结果时，由于使用的是内存复制，如果客户端在确认存活时要求服务器端发送xx字节的文件，服务器端可能会造成信息泄漏，也就是将自身内存中非心跳包响应的部分一并传出去。解决方案就是在服务器端设置忽略客户端的xx字节请求，使用自己默认的心跳包大小即可。