分布式协议
分布式理论概念
1. 分布式数据一致性
分布式数据一致性，指的是数据在多个副本中存储时，各副本中的数据是一致的。
在分布式系统中，数据往往有多个副本。多个副本就需要保证数据的一致性。这就带来了同步的问题，因为网络延迟等因素，我们几乎没有办法保证可以同时更新所有机器中的所有数据，一定会有一刻会出现数据不一致。
那么实际应用中，我们如何既保证数据一致性，同时又不影响系统运行的性能呢？于是一致性级别的概念由此诞生。
2. 一致性级别
- 强一致性
它要求系统写入什么，读出来的也会是什么，用户体验好，但是实现起来对系统的性能影响比较大
2. 弱一致性
这种级别，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能的保证到某个时间节点后，数据能够达到一致状态。
3. 最终一致性
最终一致性也是弱一致性的一种，它无法保证数据更新后，所有后续的访问能看到最新数据，而是需要一个时间，这个时间之后可以保证一致。
如微信的2小时到账：
3. CAP理论
CAP定理，它指出一个分布式系统不可能同时满足以下三点：
- 一致性 （Consistency）所有节点访问时都是同一份最新的数据副本
- 可用性（Availability）每次请求都能获取到非异常的响应，但不保证数据最新
- 分区容错性（Partition tolerance）分布式系统遇到任何网络分区故障的时候，仍然能够对外提供服务，除非整个网络环境都发生了故障
4. BASE理论
BASE全称是：Basically Available（基本可用），Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。
Base理论的核心思想是：既然无法做强一致性，那么每个应用可以根据自身业务特定，采用适当的方式使系统达到最终一致性。
-
基本可用：出现了不可预知的故障，但还是能用。只是相对正常系统来说可能响应变慢，部分功能缺失。
-
软状态：指系统的数据存在中间状态，并认为该状态不会影响系统的整体可用性。即允许不同副本的数据存在延迟
-
最终一致性：上面说的软状态，不能一直是软状态，必须要有时间期限。在期限过后，应当保证所有副本数据一致
分布式一致性协议
1. 两阶段提交
两阶段提交协议，简称2PC（2 Prepare Commit）,是比较常用的解决分布式事务问题的方式，要么所有参与进程提交事务，要么都取消事务。
阶段一：事务询问。协调者向所有资源发送事务的内容，参与者执行事务并响应结果给协调者。
阶段二：协调者根据上一阶段的结果，向所有参与者发送提交或回滚请求
优缺点
优点：原理简单
缺点：
- 同步阻塞：在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态。
- 单点问题：当协调者出现问题，那么整个二阶段提交都无法运转
- 数据不一致：在阶段二中，执行事务提交时，如果因为局部网络问题导致尚未向所有的参与者发送完Commit请求就宕机的话，就会导致出现数据不一致的现象。
2. 三阶段提交
三阶段提交是二阶段提交的改进版，将2PC的”提交事务请求“过程一分为二，共形成了由CanCommit，PreCommit和doCommit三个阶段组成的事务处理协议。
第一阶段（CanCommit阶段）：类似于2PC的准备（第一）阶段。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
第二阶段（PreCommit阶段)：协调者根据参与者的反应情况来决定是否可以执行事务的PreCommit操作。
- 如果是YES，向参与者发送预提交请求，通知参与者执行事务操作。
- 如果是NO，向参与者发送abort请求
第三阶段（doCommit阶段）：根据上一阶段的结果进行真正的事务提交或中断。
如果第三阶段中，协调者挂掉或者协调者和参与者出现网络问题：参与者都会在等待超时之后，继续进行事务提交
2PC和3PC的对比：
- 3PC对于协调者和参与者都设置了超时机制（在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收到参与者的消息则默认失败）,主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。
- 通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的 。
- PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。
3. NWR协议
NWR是一种在分布式存储系统中控制一致性级别的一种策略。
- N：在分布式存储系统中，有多少份备份数据
- W：代表一次成功的更新操作要求至少有W份数据写入成功
- R：代表一次成功的读数据操作要求至少有R份数据成功读取
NWR值的不同组合会产生不同的一致性效果，当W+R>N时，整个系统对于客户端来讲能保证强一致性。而W+R 举例：W=2 R=2 N=3 上述例子W+R>N，这种情况下，Read和Writer肯定会在某个或多个节点有交集，重合就表示强一致性。 Gossip协议也叫Epidemic协议（流行病协议）。原本用于分布式数据库中节点同步数据使用，后被广泛用于数据库复制、信息扩散、集群成员身份确认、故障探测等。 gossip 协议利用一种随机的方式将信息传播到整个网络中，并在一定时间内使得系统内的所有节点数据一致。Gossip 其实是一种去中心化思路的分布式 Gossip原理 Gossip 协议的消息传播方式有两种：反熵传播 和 谣言传播 是以固定的概率传播所有的数据。所有参与节点只有两种状态：Suspective(病原)、Infective(感染) 是以固定的概率仅传播新到达的数据。所有参与节点有三种状态：Suspective(病原)、Infective(感染)、Removed(愈除)。过程是消息只包含最新update，谣言消息在某个时间点之后会被标记为 removed，并且不再被传播 三种通信方式：推送模式、拉取模式、推/拉模式 优缺点： 综上所述，我们可以得出Gossip是一种去中心化的分布式协议，数据通过节点像病毒一样逐个传播。因为是指数级传播，整体传播速度非常快。 Paxos协议其实说的就是Paxos算法。Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一。 自Paxos问世以来就持续垄断了分布式一致性算法。开源的ZooKeeper，以及MySQL 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法解决分布式一致性问题。然而，Paxos的最大特点就是难，不仅难以理解，更难以实现. Paxos解决了什么问题？ 在常见的分布式系统中，总会发生诸如机器宕机或网络异常（包括消息的延迟、丢失、重复、乱序，还有网络分区）等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致，并且保证不论发生以上任何异常，都不会破坏整个系统的一致性 Paxos的版本有Basic Paxos，Multi Paxos，Fast-Paxos，具体落地有Raft和zk的ZAB协议。 Basic Paxos 角色概念： Basic Paxos流程图 异常情况下： Paxos协议的出现为分布式强一致性提供了很好的理论基础。但是实现比较复杂。然后斯坦福大学RamCloud项目中提出了易实现，易理解的分布式一致性复制协议Raft。Java，C++，Go 等都有其对应的实现。 Raft协议，引入主节点，通过竞选确认主节点。节点类型有Follower、Candidate、Leader。 Raft相关概念： Leader 会周期性的发送心跳包给Follower。每个Follower都设置了一个随机的竞选超时时间，一般为 150ms~300ms，如果在这个时间内没有收到 Leader 的心跳包，就会变成Candidate，进入竞选阶段,通过竞选阶段的投票多的人成为Leader 竞选阶段流程 这个是Raft完整版http://thesecretlivesofdata.com/raft/动画演示 github也提供一个https://raft.github.io/动画演示地址 . 如果多个Follower成为Candidate并且票数相同，那么就需要重新开始投票。当重新开始投票时，由于每个节点的随机竞选超时时间不同，因此能下一次再次出现多个Candidate并获得相同票数的概率很低。 日志复制 网络分区 面对网络分区，Raft也可以保持一致。 举例说明： 当发生分区后，肯定会因为接受不到Leader的心跳而重新发生选举，就会出现两个Leader。这样就分成了2部分。 原来的节点总数是5，大多数等于3.那么客户端往LeaderB上发的消息都是未提交的。只有发给E才能被提交。 等网络恢复后E节点Termid较大成为Leader节点，并同步节点数据。Leader B降为Follower节点 Lease机制，翻译过来是租约机制，是维护分布式系统数据一致性的一种常用工具。 Lease机制有如下几个特点： Lease机制能解决什么问题呢？ 分布式系统中，如何确认一个节点是否正常工作。考虑如下场景 Node1是主节点，剩下4个副本，如果Node1发生网络抖动（Node1本身是正常的，没有宕机），导致从节点无法接收到心跳。他们就会再选出一个主节点。 这种场景解决思路有4种： Lease如何处理这种情况呢？ Lease时间长短一般取1-10秒。太短网络压力太大，太长则收回承诺的时间也长，影响可用性 Lease的容错 应用：
4. Gossip 协议
协议，解决状态在集群中的传播和状态一致性的保证两个问题
5. Paxos协议
6. Raft协议
7. Lease机制
节点给每个client节点发送lease，用于判断client死活。