分布式理论基础

网络本身的不可靠性，因此每次网络通信都会伴随着网络不可用的风险（光纤、路由、DNS等硬件 设备或系统的不可用），都会导致最终分布式系统无法顺利进行一次网络通信，另外，即使分布式 系统各节点之间的网络通信能够正常执行，其延时也会大于单机操作，存在巨大的延时差别，也会影响消息的收发过程，因此消息丢失和消息延迟变的非常普遍。

网络之间出现了网络不连通，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被 切分成了若干个孤立的区域，分布式系统就会出现局部小集群，在极端情况下，这些小集群会独立 完成原本需要整个分布式系统才能完成的功能，包括数据的事务处理，这就对分布式一致性提出非常大的挑战。

分布式系统每一次请求与响应存在特有的“三态”概念，即成功、失败和超时

分布式系统在发生调用的时候可能会出现 失败 超时的情况. 这个时候需要重新发起调用.

任意多次执行对资源本身所产生的影响均与一次执行的影响相同

强一致性

弱一致性

最终一致性

因果一致性

读己所写一致性

会话一致性

单调读一致性

单调写一致性（串行）

一旦客户端将值写入任何一台服务器并获得响应，那么之后client从其他任何服务器 读取的都是刚写入的数据

系统中非故障节点收到的每个请求都必须有响应，在可用系统中，如果我们的客户端向服务器 发送请求，并且服务器未崩溃，则服务器必须最终响应客户端，不允许服务器忽略客户的请求

允许网络丢失从一个节点发送到另一个节点的任意多条消息，即不同步. 也就是说，G1和G2发送给 对方的任何消息都是可以放弃的，也就是说G1和G2可能因为各种意外情况，导致无法成功进行同 步，分布式系统要能容忍这种情况。

什么是分区？

分布式系统中，必须满足 CAP 中的 P，此时只能在 C/A 之间作出取舍。

• 若要保证一致性：则必须进行节点间数据同步，同步期间数据锁定，导致期间的读取失败或超时，破坏了可用性；
• 若要保证可用性：则不允许节点间同步期间锁定，这又破坏了一致性。

• 舍弃P(选择C/A)：单点的传统关系型数据库 DBMS(MySQL/Oracle)，但如果采用集群就必须考虑P了；
• 舍弃A(选择C/P)：是分布式系统要保证P，而且保证一致性，如 ZooKeeper / Redis / MongoDB / HBase；
• 舍弃C(选择A/P)：是分布式系统要保证P，而且保证可用性，如 CoachDB / Cassandra / DynamoDB。

 保证可用性和分区容错，舍弃强一致性，但保证最终一致性，比如一些高并发的站点（秒杀、淘宝、12306）。最终近似于兼顾了三个特性。

第一阶段（voting phase投票阶段）

第二阶段（commit phase提交执行阶段）

尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）

性能问题：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

可靠性问题：参与者发生故障。协调者需要给每个参与者额外指定超时机制，超时后整个事务失败。协调者发生故障。参与者会一直阻塞下去。需要额外的备机进行容错。

数据一致性问题：二阶段无法解决的问题：协调者在发出`commit`消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

太过保守：在进行事务提交询问的过程中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，此时协调者只能依靠自身的超时机制来判断是否需要中断事务，这样的策略过于 保守，即没有完善的容错机制，任意一个结点的失败都会导致整个事务的失败。

事务询问 协调者向所有参与者发出包含事务内容的 `canCommit` 请求，询问是否可以提交事务，并等待所有参与者答复。

响应反馈 参与者收到 `canCommit` 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。

所有参与者均反馈 yes，协调者预执行事务。

任何一个参与者向协调者发送了No响应，或者等待超时之后，
协调者都没有接到参与者的响应，那么就执行事务的中断

执行提交

中断事务

相比二阶段提交，三阶段提交降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段 3 中协调者出现问题时，参与者会继续提交事务

数据不一致问题依然存在，当在参与者收到 `preCommit` 请求后等待 `doCommit` 指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

1. 首先对于协调者和参与者都设置了超时机制（在2PC中，只有协调者拥有超时机制，即如果在一定 时间内没有收到参与者的消息则默认失败）,主要是避免了参与者在长时间无法与协调者节点通讯 （协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自 动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。
2. . 通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个 缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的 
3. . PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的

主要是对业务系统做检测及资源预留 (加锁，锁住资源)

• Confirm（确认）：执行真正的业务执行业务，释放锁
• Cancle（取消）：是预留资源的取消出问题，释放锁

优点

缺点

NWR是一种在分布式存储系统中用于控制一致性级别的一种策略。在亚马逊的云存储系统中，就应用 NWR来控制一致性。

• N（node）：在分布式存储系统中，有多少份备份数据 
• W：代表一次成功的更新操作要求至少有w份数据写入成功 
• R： 代表一次成功的读数据操作要求至少有R份数据成功读取

反熵传播

谣言传播

优点

缺点

Gossip 协议由于以上的优缺点，所以适合于 AP 场景的数据一致性处理，常见应用有：P2P 网络通信、 Redis Cluster、Consul

在常见的分布式系统中，总会发生诸如机器宕机或网络异常（包括消息的延迟、丢失、重复、乱序，还有网络分区）等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系 统中，快速且正确地在集群内部对某个数据的值达成一致，并且保证不论发生以上任何异常，都不会破坏整个系统的一致性。

2PC 和 3PC的时候在一定程度上是可以解决数据一致性问题的，但是并没有完全解决就是协调者宕机的情况，
如何解决2PC和3PC的存在的问题呢 ?

引入多个协调者之后又引入主协调者.那么这个就是最简单的一种Paxos 算法  Paxos的版本有: Basic Paxos, Multi Paxos, Fast-Paxos,   具体落地有Raft 和zk的ZAB协议

决策模型

流程

在 Base Paxos 基础上选择主决策者

Multi-Paxos在实施的时候会将Proposer，Acceptor和Learner的角色合并统称为“服务器”。因此， 最后只有“客户端”和“服务器”

节点状态

termId：任期号，时间被划分成一个个任期，每次选举后都会产生一个新的 termId，一个任期内只有一个 leader

RequestVote：请求投票，candidate 在选举过程中发起，收到多数派响应后，成为 leader

gif动画

如果有多个 Follower 成为 Candidate，并且所获得票数相同，那么就需要重新开始投票，例如下 图中 Candidate B 和 Candidate D 都获得两票，因此需要重新开始投票。

当重新开始投票时，由于每个节点设置的随机竞选超时时间不同，因此能下一次再次出现多个 Candidate 并获得同样票数的概率很低

网络分区情况日志复制

• Lease是颁发者对一段时间内数据一致性的承诺； 
• 颁发者发出Lease后，不管是否被接收，只要Lease不过期，颁发者都会按照协议遵守承诺； 
• Lease的持有者只能在Lease的有效期内使用承诺，一旦Lease超时，持有者需要放弃执行，重新申请Lease。

某个时刻主节点突然出现网络抖动或者网络中断情况(注意:不是宕机)，导致从节点无法接受到心跳，又竞选出新的主节点，出现的双主问题。

主要解决思路

引入中心节点负责下发Lease

出现网络问题

如果网络恢复

如果到01:10时间,主节点会进行续约操作,然后在下发新的Lease

如果主节点宕机，其他节点申请Lease也会失败，承认主节点存在

副节点申请Lease,申请成功. 因为Lease过期

• 主节点宕机 ： lease机制天生即可容忍网络、lease接收方的出错,时间即Lease剩余过期时长 
• 中心节点异常：  颁发者宕机可能使得全部节点没有lease，系统处于不可用状态，解决的方法就是使用一个小集群 而不是单一节点作为颁发者。
•  时差问题 ： 中心节点与主节点之间的时钟可能也存在误差，只需要中心节点考虑时钟误差即可。

Server端每间隔 t 秒向Node集群发起监测请求，设定超时时间，如果超过超时时间，则判断“死亡”

在周期检测心跳机制的基础上，统计一定周期内节点的返回情况（包括超时及正确返回），以此计 算节点的“死亡”概率。另外，对于宣告“濒临死亡”的节点可以发起有限次数的重试，以作进一步判 断。如果超过次数则可以把该节点踢出集群

高可用(High Availability)是系统架构设计中必须考虑的因素之一，通常是指，经过设计来减少系统不能提供服务的时间

主从（主备）模式 【MS模式】

双主互备(故障转移) 【MM模式】

集群模式

在高可用（HA）系统中，当联系两个节点的"心跳线"断开时(即两个节点断开联系时)，本来为 一个整体、动作协调的HA系统，就分裂成为两个独立的节点(即两个独立的个体)。由于相互失去了 联系，都以为是对方出了故障，两个节点上的HA软件像"裂脑人"一样，"本能"地争抢"共享资源"、 争起"应用服务"。就会发生严重后果：

• 共享资源被瓜分、两边"服务"都起不来了；
• 两边"服务"都起来了，但同时读写"共享存储"，导致数据损坏（常见如数据库轮询着的联机日志出错）。

脑裂出现的原因（总的来说就是节点之间无法进行正常的通讯）

Redis

zk

消息队列中间件主要解决应用耦合，异步消息，流量削锋等问题

分层过滤的核心思想

分层过滤的基本原则

整个架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，我们可以将一些 不重要 或 不紧急 的服务或任务进行服务的延迟使用 或 暂停使用

从分布式，微服务架构全局的 视角来看，降级处理方案

针对后端代码层面的降级处理策略

结合服务能否降级的优先原则，并根据台风预警（都属于风暴预警）的等级进行参考设计，可将分布 式服务架构的所有服务进行故障风暴等级划分为以下四种

计数器（固定窗口）

计数器（滑动窗口）

漏桶

令牌桶

Hystrix

Sentinel

故障快速定位

各个调用环节的性能分析

数据分析

生成服务调用拓扑图

设计目标

埋点和生成日志

抓取和存储日志

分析和统计调用链数据

计算和展示