一，分布式系统
1，简介。（what） 这是一个较为宽泛的概念，它的产生和出现是为了解决和应对以往系统的问题
百科： 分布式系统（distributed system），是建立在网络之上的软件系统。正是由于软件的特性，所以分布式系统具有内聚性和透明性。
内聚性： 系统内的节点、服务的目的、分工、规则明确。
透明性： 分布式系统对外提供服务，调用该系统的外部用户不用考虑它是怎样工作的，只要根据规则进行使用就行，也不需要里面包含多少台服务器，在什么地方
简单理解： 是一套互相连接共同对外提供服务的系统，系统内部结点采用某种方式进行通信；常见的大的如大型电商系统，小的如数据库集群、缓存集群。
2，使用分布式系统原因？(why)
* 分布式系统出现之前的单机系统，一旦服务器的操作系统、硬盘、网络出现问题就会导致服务的中断，数据的丢失等问题。
* 单机系统的性能再高、存储能力再扩展、也是有限的。而分布式系统可以以大量的服务器来分散带宽、存储、计算的压力
* 由于跨远区域甚至跨国、网络的延迟有时候是客观的，所以说服务器集中在一个地方很难再较大的区域内提供较好的服务和体验
3，分布式系统在实际操作环境之中的问题；
由于分布式系统不完美的运行环境，所以有些问题尚待解决。例如，系统之间的每个节点都有可能出现单个节点出现故障突然间不工作了，节点间会有或大或小，忽大忽小的网络延迟，节点间也有可能出现网络中断。从技术角度来看，可能出现的问题基本上认为是早晚会发生的，说到底，很多问题就是成本和收益的平衡。因此，一个分布式系统要想正常的对外提供服务，它的设计本身就的考虑这些问题的解决。在算法层面上，分布式一致性算法就是为了辅助和解决这些问题，确保系统尽可能的能够正常的对外提供服务
二，分布式一致性算法
简介；
主要是从系统角度分析分布式系内部节点本身及其节点之间出现问题的解决，
例如，一个系统之间包含5个节点，由于网络问题，其中3个节点与另外2个节点失去连接，此刻系统如何处理？是否继续提供服务支持？如果继续提供服务支持，那么他们之间的数据就是不一致的，后面节点的网络恢复后，怎么解决数据不一致问题？
其次，节点间的网络延迟，磁盘读写，CPU处理能力都不尽相同，那么保存到这个系统中的数据什么样的情况下认为保存成功？同时还要以一种高效的形式来实现。
常见的分布式系统的一致性算法：
Paxos Raft ZAB
ZAB（zookeeper atomic Broadcast）:
主要以下特点：
* 把节点分为两种：主节点（leader）和从节点(follower)
* 有一个主节点，所有的写操作（这里的写操作可以认为是新增和修改）都在主节之上，如果有一个从节点收到写操作请求，也会转移到主节点处理。
* 其他节点都是从节点，可以通过从节点进行读操作
* 主节点通过选举所得，主节点失踪后，其余从节点自动选取新的主节点
写操作具体实施：
常规写流程如下：
1. 客户向主节点请求写数据X
2. 主节点为该条数据X生成唯一的递增id，叫ZXID X(id)
3. 主节点把X(id)发送给所有从节点，跟他们确认能不能正常的将数据记录下来，这个操作叫做Propose提议
4. 超过一半的从节点向主节点回复没有问题，这个操作叫做ACK应答
5. 主节点收到一半以上从节点肯定回答后，给所有从节点发送确认提交请求，即表示你们可以将这条数据保存下来了，同时自己也正式保存这条数据，这个过程叫做commit
节点挂掉的各个情况：
1. 少部分节点挂掉没有任何影响
2. 一半节点挂掉，系统不能提供服务；一般这种情况的概率较小
3. 少部分节点挂掉、一段时间后又恢复了之后：
* 先通过主节点同步最新的数据；因为自己挂掉一段时间后，很有可能没有最新的数据。
* 数据同步之后正式成为子节点开始工作。
同理：新添加的子节点到现有的集群也是这个模式
4. 在主节点挂掉期间，系统暂时不对外提供服务，开始新的节点选举
ZAB节点选举机制：发消息到每一个自己能连得上的节点：包含自己的节点编号myid和保存数据的最大ZXID
选举规则：
* 谁的ZXID最大，谁就是主节点。why？因为这表示他的数据最新。尽量保证数据的一直性。
* ZXID一样时，谁的myid最大，谁就是新的主节点。
* 每个节点收到其他节点的数据后，与自己的数据进行判断，如果对方的比自己大，那就认同对方为主节点
* 得到一半以上（注意；这里又是一半以上）节点认同的候选节点成为新的主节点
====》最后 新的主节点选取出来以后，进入集群成为数据同步节点，先检查节点内部那些数据比自己旧，然后将数据同步过去。然后对外提供服务
Raft算法：
Raft算法与ZAB算法类似，也分为主节点和从节点；区别在于主节点选取机制上有所不同。
Raft选举机制：
1. 发现主节点失踪一段时间之后，所有从节点向其他从节点发送消息，让他们选取自己为新的主节点。
2. 还没有参加选举的从节点如果收到其他节点的选举请求，就选取自己收取到的第一个节点，后面在有谁请求自己支持选取，就告知自己已经支持另一个节点了。
3. 如果一个节点发现另一个节点的支持率比自己高，那么自己就无条件的支持另一个节点，并同时让自己的簇拥也支持另一个节点。
4. 如果一轮选举没有选取出新的主节点，那么就开始下一轮选举，知道一个节点得到大多数的拥簇。
备注：
关于ZXID说明：主节点上没提交的数据在从节点上也算做未提交，因此没提交的数据的ZXID不算数。
关于选举说明：选举一定是在主节点挂掉之后才进行的。分布式一致性算法可以再保证部分节点挂掉的情况下，数据的一致性；但是在大部分节点同时挂掉的情况下不保证。如果超过半数节点同时挂掉，那么该系统则不对再外提供服务。
当然，在写数据时，强制确认所有节点都写入了新数据会更安全和一致，但是系统的可用性和性能就大大降低了；
譬如一个节点挂掉，那么整个系统就不能够正常的工作了。
Q&A
Q：为什么要保证一半以上的从节点回复？
A为了保证数据的一致性
Q:如果他们网络恢复之后，正常节点与非正常节点（多数节点与少数节点间）数据已谁为准？
A：分布式一致性算法采用大多数认同的方式
Q：判定主节点已死的依据是什么？因为通过节点选举的机制，那么主节点的压力比较大。
A：通过心跳检测来判断；针对心跳侦听时间的配置较为严苛，间隔太大容易响应慢，间隔太小容易出现假死。所以针对这种情况分两方面考虑：1，针对外部系统通过缓存、延迟调用等方式解决；2，对内在运维上需要对于服务器做自动化监控预警告警方面的处理。
