背景
- ZAB、Raft 算法是对Paxos算法的简化和改进，是Paxos算法的变种
二者的leader的选举都需要满足过半原则，并且写操作都是由leader发起
共同点：
都是共识算法，写数据时都需要大部分成功才能把日志应用到状态机。
都有选主、日志对齐、数据广播的流程。
都把数据分成快照+日志。
区别 ：raft算法 强一致性 同一时间只能有一个leader,所有的操作都在leader上，Raft 的设计更为简洁，没有和ZooKeeper 强耦合 - Gossip 去中心化分布式一致性算法
Gossip协议基本思想就是：一个节点想要分享一些信息给网络中的其他的一些节点。于是，它周期性的随机选择一些节点，并把信息传递给这些节点。这些收到信息的节点接下来会做同样的事情，即把这些信息传递给其他一些随机选择的节点。一般而言，信息会周期性的传递给N个目标节点，而不只是一个。这个N被称为fanout（这个单词的本意是扇出）。
以下各种工程实现都是一个在CAP之间tradeoff的过程
zookeeper
采用zab算法，满足写强一致性（过半节点），读最终一致性（所有节点）
hdfs
采用租约机制确保并发写入的顺序性和采用hflush机制实现文件的最小副本可见性，满足写强一致性（满足hfds最小副本数，其它副本hdfs自动异步同步），读最终一致性（所有副本），实现弱分区容错性
kafka
kafka 读写都在leader上，配合acks=all，实现了读写强一致性，ISR机制确保了高可用性，副本机制实现了分区容错性
hbase
hbase读写rowkey都在特定region上，实现读写强一致性，弱高可用性（region存在单点故障），分区容错性hdfs来实现
redis
redis3.0实现Redis-Cluster，采用Gossip协议进行redis元数据广播，实现了元数据读写最终一致性，并且采用shard-master和shard-slave机制实现高可用性，分区容错性
在分布式系统中，需要提供维护节点元数据信息的机制，所谓元数据是指节点负责哪些数据、主从属性、是否出现故障等状态信息。常见的元数据维护方式分为集中式和无中心式。Redis Cluster 采用 Gossip 协议实现了无中心式。
clickhouse
实现原理同redis-cluster，实现了读写最终一致性，高可用和分区容错性
JournalNode
NameNode与JournalNode Cluster进行数据读写时核心点是需要大多数JN成功返回才可认为本次请求有效
在JournalNode Cluster中所有JN之间完全对等，不存在Primary/Secondary区别，实现原理类似paxos
QJM机制实现的是最终一致性
1、为了降低读写操作相互影响，Journal采用了DoubleBuffer技术管理实时过来的Editlog数据，通过DoubleBuffer可以为高速设备（内存）与低速设备（磁盘/SSD）之间建立缓存区和管道，避免数据写入被低速设备阻塞影响性能；
2、NameNode到JournalNode的所有数据写入请求都会直接落盘，当然写入请求的数据可以是批量，只有数据持久化完成才能认为本次请求有效和成功，这一点在数据恢复时非常关键；
3、与Pasox/Zookeeper类似，所有到达JournalNode的读写请求，包第一件事情是合法性校验，括EpochNum，CommitTxid等在内的状态信息，只有校验通过才能被处理，状态校验是强一致保证的基础；
一句话总结JournalNode是一套提供读写服务并实时持久化序列数据的有状态存储系统。
