参考链接：https://www.jianshu.com/p/71b2729d3004
两类一致性(操作原子性与副本一致性)
2PC，3PC协议：强调事务，用于保证属于多个数据分片上的操作的原子性。这些数据分片可能分布在不同的服务器上，2PC协议保证多台服务器上的操作要么全部成功，要么全部失败。
Paxos，Raft协议：强调同一条数据的复制，用于保证同一个数据分片的多个副本之间的数据一致性。当这些副本分布到不同的数据中心时，这个需求尤其强烈。
下面讲的是多个副本之间的数据一致性。
| 分布式系统 | 分布式一致性协议 | 选择理由 | 协议核心功能 | 备注 |
| TiDB | raft协议（强一致性） | raft协议实现简单 |
保证数据一致性，完整复制日志到其它节点leader选举同一时刻只能保证有一个Leader，只有leader可以复制日志 | 由于raft协议是2013年发布，而TiDB发布于2016年，时间刚好赶上了 |
| ElasticSearch | Gossip | 最终一致性消息 | ||
| Kafka | ||||
| ZooKeeper | Zab协议 | |||
| HDFS | ||||
| Hbase | 通过HDFS进行数据备份。WAL(Write-ahead logging) | WAL的实现是HLog，HLog也是存储在HDFS上的，所以HRegionServer崩溃了也不会导致HLog的丢失，它也有备份。 需要注意的是，Hbase Replication 是以 Column Family 为单位，每个CF都可以设置是否进行 Replication。 注意：Hbase是强一致性的 |
注意：
1.为什么raft协议是强一致性协议？因为超过半数成功后，认为是提交成功，然后只有这些提交成功的节点才会对外服务，这样就保证了app查到的数据是正确的数据（没有反馈确认的其它节点，即使成功了，也不会对外服务，只有反馈给leader成功，才会对外服务）
2.Hbase中的Replication也是基于WAL的，其在主集群的每个RegionServer进程内部起了一个叫做ReplicationSource的线程来负责Replication，同时在备集群的每个RegionServer内部起了一个ReplicationSink的线程来负责接收Replication数据。ReplicationSource记录需要同步的WAL队列，然后不断读取WAL中的内容，同时可以根据Replication的配置做一些过滤，比如是否要复制这个表的数据等，然后通过replicateWALEntry这个Rpc调用来发送给备集群的RegionServer，备集群的ReplicationSink线程则负责将收到的数据转换为put/delete操作，以batch的形式写入到备集群中。
3、提一下Mysql：Mysql是通过异步的方式读取binlog然后存储到slave集群，肯定会导致数据一致性的延时，有时候写入量大可能会延时几小时。
二、分布式系统需要考虑的几个基本问题分片要尽量均匀的散落在不同的节点，均匀的目的：
- 负载均衡，避免形成热点；很重要的隐藏意义，即增加或减少节点，数据会重新进行均衡分配，动态的根据节点分片情况迁移数据（增加的节点刚开始是没有数据的，这样导致各个增加节点数据不均匀，就会触发分片重新分配；其实减少节点也会，因为减少后，可能导致某些主分片或副本丢失，所以要重新拷贝副本，这个过程就会导致数据不均匀，所以也会重新分配）
必须多副本，至少一个，且数据的主分片和副本必须不能在同一个节点上：如果只有一个副本，且主分片和副本在一台机器上，那么这台机器挂掉后，这块数据就会丢失，这违背了分布式系统的设计初衷；数据的散落方案：一种是按照 Key 做 Hash，根据 Hash 值选择对应的存储节点（ElasticSearch）；另一种是分 Range，某一段连续的 Key 都保存在一个存储节点上（Hbase，TiDB）。节点迁移需要控制速度，避免影响线上服务 三、数据存储原理
| 分布式系统 | 概念 | 备注 | 其它说明 |
| TiDB | Region | ||
| ElasticSearch | 分布式存储原理：ElasticSearch - 巍巍的个人页面 - OSCHINA - 中文开源技术交流社区 | ||
| Kafka | Broker，Partition | Broker：Kafka集群中的一台或多台服务器统称broker. Partition：Topic物理上的分组，一个topic可以分为多个partion,每个partion是一个有序的队列。partion中每条消息都会被分配一个 有序的Id(offset)，同一 topic 下的不同分区包含的消息是不同的。 | |
| ZooKeeper | |||
| HDFS | |||
| Hbase | Region |
| 分布式系统 | 集群管理 | 备注 | 其它说明 |
| TiDB | PD | ||
| ElasticSearch | |||
| Kafka | ZooKeeper | ||
| ZooKeeper | |||
| HDFS | |||
| Hbase | ZooKeeper | 1、管理机器是否可用 2、存储region信息 3、 |
参考链接：
https://blog.csdn.net/tb3039450/article/details/80249664
https://blog.csdn.net/tb3039450/article/details/80185436
六、MVCC与事务MVCC即乐观锁的一种实现方式。
乐观锁(MVCC)
何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
几个分布式系统事务的实现机制：
| 分布式系统 | 事务 | 选择理由 | 协议核心功能 | 备注 |
| TiDB | TiKV 的事务采用的是 Percolator 模型，总体来说就是一个经过优化的二阶段提交（2PC）的实现 | |||
| ElasticSearch | ||||
| Kafka | ||||
| ZooKeeper | ||||
| HDFS | ||||
| Hbase |
要设计很好的调度系统，就需要手机足够多的信息，如每个节点的状态；每个分片的状态；节点或分片访问的QPS、吞吐量信息；节点的配置信息，如硬盘，内存等；
