快速理解分布式架构设计理论

前言

分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。简单来说，所谓分布式系统，就是一个业务拆分成多个子业务，分布在不同的服务器节点，共同构成的系统称为分布式系统，同一个分布式系统中的服务器节点在空间部署上是可以随意分布的，这些服务器可能放在不同的机柜中，也可能在不同的机房中，甚至分布在不同的城市。

1 分布式架构的演变

从最初的单体架构 》》》服务化，从下图来描述分布式架构的演变过程：

2 分布式系统面临的问题

1）通信异常
网络本身的不可靠性，因此每次网络通信都会伴随着网络不可用的风险（光纤、路由、DNS等硬件设备或系统的不可用），都会导致最终分布式系统无法顺利进行一次网络通信，另外，即使分布式系统各节点之间的网络通信能够正常执行，其延时也会大于单机操作，存在巨大的延时差别，也会影响消息的收发过程，因此消息丢失和消息延迟变的非常普遍。
2）网络分区
网络之间出现了网络不连通，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域，分布式系统就会出现局部小集群，在极端情况下，这些小集群会独立完成原本需要整个分布式系统才能完成的功能，包括数据的事务处理，这就对分布式一致性提出非常大的挑战。
3）节点故障
节点故障是分布式系统下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或"僵死"现象，根据经验来说，每个节点都有可能出现故障，并且经常发生. 4）三态分布式系统每一次请求与响应存在特有的“三态”概念，即成功、失败和超时。分布式系统中，由于网络是不可靠的，虽然绝大部分情况下，网络通信能够接收到成功或失败的响应，但当网络出现异常的情况下，就会出现超时现象，通常有以下两种情况：
1. 由于网络原因，该请求并没有被成功的发送到接收方，而是在发送过程就发生了丢失现象。
2. 该请求成功的被接收方接收后，并进行了处理，但在响应反馈给发送方过程中，发生了消息丢失现象。

3 分布式理论

3.1 一致性

什么是分布式一致性？
分布式数据一致性，指的是数据在多份副本中存储时，各副本中的数据是一致的。

分布式系统当中，数据往往会有多个副本。如果是一台数据库处理所有的数据请求，那么通过ACID四原则，基本可以保证数据的一致性。而多个副本就需要保证数据会有多份拷贝。这就带来了同步的问题，因为我们几乎没有办法保证可以同时更新所有机器当中的包括备份所有数据。 网络延迟，即使我在同一时间给所有机器发送了更新据的请求，也不能保证这些请求被响应的时间保持一致存在时间差，就会存在某些机器之间的数据不一致的情况。

一致性分类

总得来说，我们无法找到一种能够满足分布式系统所有系统属性的分布式一致性解决方案。因此，如何既保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。于是，一致性级别由此诞生：
1. 强一致性
这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大。但是强一致性很难实现。
2.弱一致性
这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。

• 读写一致性
  用户读取自己写入结果的一致性，保证用户永远能够第一时间看到自己更新的内容。
• 单调读一致性
  本次读到的数据不能比上次读到的旧。
• 因果一致性
  指的是：如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后 的值。于此同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。
• 最终一致性
  最终一致性是所有分布式一致性模型当中最弱的。可以认为是没有任何优化的“最”弱一致性，它的意思是说，我考虑 所有的中间状态的影响，只保证当没有新的更新之后，经过一段时间之后，最终系统内所有副本的数据是正的。 它最大程度上保证了系统的并发能力，也因此，在高并发的场景下，它也是使用最广的一致性模型。

3.2 CAP定理

CAP 理论含义是，一个分布式系统不可能同时满足一致性（C:Consistency)，可用性（A: Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中的2个。

选项	描述
C	一致性 分布式系统当中的一致性指的是所有节点的数据一致，或者说是所有副本的数据一致
A	可用性 Reads and writes always succeed. 也就是说系统一直可用，而且服务一直保持正常
P	分区容错性 系统在遇到一些节点或者网络分区故障的时候，仍然能够提供满足一致性和可用性的服务

1. 舍弃A(可用性)，保留CP(一致性和分区容错性)

一个系统保证了一致性和分区容错性，舍弃可用性。也就是说在极端情况下，允许出现系统无法访问的情况出现，这个时候往往会牺牲用户体验，让用户保持等待，一直到系统数据一致了之后，再恢复服务。

2. 舍弃C(一致性)，保留AP(可用性和分区容错性)

这种是大部分的分布式系统的设计，保证高可用和分区容错，但是会牺牲一致性。

3. 舍弃P(分区容错性)，保留CA(一致性和可用性)

如果要舍弃P，那么就是要舍弃分布式系统，CAP也就无从谈起了。可以说P是分布式系统的前提，所以这种情况是不存在 的。

3.3 BASE定理

BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。

BASE是对CAP中一致性和可用性权衡的结果，BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

①Basically Available(基本可用)

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。以下就是两个"基本可用"的例子

• 响应时间上的损失：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
• 功能上的损失：正常情况下，在一个电子商务网站（比如淘宝）上购物，消费者几乎能够顺利地完成每一笔订单。但在一些节日大促购物高峰的时候（比如双十一、双十二），由于消费者的购物行为激增，为了保护系统的稳定性（或者保证一致性），部分消费者可能会被引导到一个降级页面。

②Soft state（软状态）

什么是软状态呢？相对于一致性，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。
软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本之间进行数据同步的过程中存在延迟。

③Eventually consistent（最终一致性）

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

3.4 分布式事务

什么是分布式事务？

其实分布式事务从实质上看与数据库事务的概念是一致的，既然是事务也就需要满足事务的基本特性（ACID），只是分布式事务相对于本地事务而言其表现形式有很大的不同

3.5 一致性协议2PC和3PC

2PC （ Two-Phase Commit缩写）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Preparephase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。

两个阶段过程：

1. 准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。 （Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数 据文件）
2. 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。

2PC执行流程




3PC，全称 “three phase commit”，是 2PC 的改进版，将 2PC 的 “提交事务请求” 过程一分为二，共形成了由
CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。

第一个阶段： CanCommit
① 事务询问
协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待
各参与者的响应。
② 各参与者向协调者反馈事务询问的响应
参与者在接收到来自协调者的包含了事务内容的canCommit请求后，正常情况下，如果自身认为可以顺利执行事
务，则反馈Yes响应，并进入预备状态，否则反馈No响应。

阶段二：PreCommit
协调者在得到所有参与者的响应之后，会根据结果有2种执行操作的情况：执行事务预提交，或者中断事务
假如所有参与反馈的都是Yes，那么就会执行事务预提交。

1. 执行事务预提交分为 3 个步骤
   ① 发送预提交请求：
   协调者向所有参与者节点发出preCommit请求，并进入prepared阶段。
   ② 事务预提交：
   参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。
   ③ 各参与者向协调者反馈事务执行的结果：
   若参与者成功执行了事务操作，那么反馈Ack
   若任一参与者反馈了No响应，或者在等待超时后，协调者尚无法接收到所有参与者反馈，则中断事务
2. 中断事务也分为2个步骤：
   ① 发送中断请求：
   协调者向所有参与者发出abort请求。
   ② 中断事务：
   无论是收到来自协调者的abort请求或者等待协调者请求过程中超时，参与者都会中断事务。

阶段三：do Commit
该阶段做真正的事务提交或者完成事务回滚，所以就会出现两种情况：

1. 执行事务提交
   ① 发送提交请求：
   进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么他将从预提交状
   态转化为提交状态，并向所有的参与者发送doCommit请求。
   ② 事务提交：
   参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行过程中占用的事
   务资源。
   ③ 反馈事务提交结果：
   参与者在完成事务提交后，向协调者发送Ack响应。
   ④ 完成事务：
   协调者接收到所有参与者反馈的Ack消息后，完成事务。
2. 中断事务
   ① 发送中断请求：协调者向所有的参与者节点发送abort请求。
   ② 事务回滚：参与者收到abort请求后，会根据记录的Undo信息来执行事务回滚，并在完成回滚之后释放整
   个事务执行期间占用的资源。
   ③ 反馈事务回滚结果：参与者在完成事务回滚后，向协调者发送Ack消息。
   ④ 中断事务：协调者接收到所有参与者反馈的Ack消息后，中断事务。
   注意：一旦进入阶段三，可能会出现 2 种故障：
3. 协调者出现问题
4. 协调者和参与者之间的网络故障
   如果出现了任一一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针对这种情况，参与
   者都会在等待超时之后，继续进行事务提交

2PC对比3PC

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

问题：3PC协议并没有完全解决数据不一致问题。

3.6 一致性算法Paxos 和 Raft

Paxos

Paxos算法是Lamport提出的一种基于消息传递的分布式一致性算法。自Paxos问世以来就持续垄断了分布式一致性算法，Paxos这个名词几乎等同于分布式一致性。Google的很多大型分布式系统都采用了Paxos算法来解决分布式一致性问题，如Chubby、Megastore以及Spanner等。开源的ZooKeeper，以及MySQL 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法解决分布式一致性问题。然而，Paxos的最大特点就是难，不仅难以理解，更难以实现。

Paxos解决了分布式系统一致性问题。

Paxos相关概念
首先一个很重要的概念叫提案（Proposal）。最终要达成一致的value就在提案里。
提案 (Proposal)：Proposal信息包括提案编号 (Proposal ID) 和提议的值 (Value)
在Paxos算法中，有如下角色：
Client：客户端
客户端向分布式系统发出请求，并等待响应。例如，对分布式文件服务器中文件的写请求。

Proposer：提案发起者
提案者提倡客户请求，试图说服Acceptor对此达成一致，并在发生冲突时充当协调者以推动协议向前发展

Acceptor：决策者，可以批准提案
Acceptor可以接受（accept）提案；如果某个提案被选定（chosen），那么该提案里的value就被选定了

**Learners：**最终决策的学习者
学习者充当该协议的复制因素

Raft

Raft 是一种为了管理复制日志的一致性算法。Raft提供了和Paxos算法相同的功能和性能，但是它的算法结构和Paxos不同。Raft算法更加容易理解并且更容易构建实际的系统。

Raft将一致性算法分解成了3模块

1. 领导人选举
2. 日志复制
3. 安全性
   Raft算法分为两个阶段，首先是选举过程，然后在选举出来的领导人带领进行正常操作，比如日志复制等。

Raft 通过选举一个领导人，然后给予他全部的管理复制日志的责任来实现一致性。
在Raft中，任何时候一个服务器都可以扮演下面的角色之一：
领导者(leader)：处理客户端交互，日志复制等动作，一般一次只有一个领导者
候选者(candidate)：候选者就是在选举过程中提名自己的实体，一旦选举成功，则成为领导者
跟随者(follower)：类似选民，完全被动的角色，这样的服务器等待被通知投票而影响他们身份变化的则是 选举。

Raft使用心跳机制来触发选举。当server启动时，初始状态都是follower。每一个server都有一个定时器，超时时间为election timeout（一般为150-300ms），如果某server没有超时的情况下收到来自领导者或者候选者的任何消息，定时器重启，如果超时，它就开始一次选举。

这里不具体去演示，我们可以通过这个地址 http://thesecretlivesofdata.com/raft/ 动画演示

4 分布式系统设计策略

分布式系统本质是通过低廉的硬件攒在一起以获得更好的吞吐量、性能以及可用性等。
在分布式环境下，有几个问题是普遍关心的，我们称之为设计策略：

• 如何检测当前节点还活着？
• 如何保障高可用？
• 容错处理
• 负载均衡

1.心跳检测
心跳顾名思义，就是以固定的频率向其他节点汇报当前节点状态的方式。收到心跳，一般可以认为一个节点和现在的网络拓扑是良好的。当然，心跳汇报时，一般也会携带一些附加的状态、元数据信息，以便管理。

如图所示，Client请求Server，Server转发请求到具体的Node获取请求结果。Server需要与三个Node节点保持心跳连接，确保Node可以正常工作。

若Server没有收到Node3的心跳时，Server认为Node3失联。但是失联是失去联系，并不确定是否是Node3故障，有可能是Node3处于繁忙状态，导致调用检测超时；也有可能是Server与Node3之间链路出现故障或闪断。所以心跳不是万能的，收到心跳可以确认节点正常，但是收不到心跳也不能认为该节点就已经宣告“死亡”。此时，可以通过一些方法帮助Server做决定： 周期检测心跳机制、累计失效检测机制。

周期检测心跳机制
Server端每间隔 t 秒向Node集群发起监测请求，设定超时时间，如果超过超时时间，则判断“死亡”。
累计失效检测机制
在周期检测心跳机制的基础上，统计一定周期内节点的返回情况（包括超时及正确返回），以此计算节点的“死 亡概率。另外，对于宣告“濒临死亡”的节点可以发起有限次数的重试，以作进一步判断。通过周期检测心跳机制、累计失效检测机制可以帮助判断节点是否“死亡”，如果判断“死亡”，可以把该节点踢出集群。

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

系统高可用性的常用设计模式包括三种：主备（Master-SLave）、互备（Active-Active）和集群（Cluster）模式。

3.容错性
容错顾名思义就是IT系统对于错误包容的能力
容错的处理是保障分布式环境下相应系统的高可用或者健壮性，一个典型的案例就是对于缓存穿透 问题的解决方案。

4.负载均衡
负载均衡：其关键在于使用多台集群服务器共同分担计算任务，把网络请求及计算分配到集群可用的不同服务器节点上，从而达到高可用性及较好的用户操作体验。

负载均衡器有硬件解决方案，也有软件解决方案。硬件解决方案有著名的F5，软件有LVS、HAProxy、Nginx等。以Nginx为例，负载均衡有以下几种策略：

• 轮询：即Round Robin，根据Nginx配置文件中的顺序，依次把客户端的Web请求分发到不同的后端服务器。
• 最少连接：当前谁连接最少，分发给谁。
• IP地址哈希：确定相同IP请求可以转发给同一个后端节点处理，以方便session保持。
• 基于权重的负载均衡：配置Nginx把请求更多地分发到高配置的后端服务器上，把相对较少的请求分发到低配服务器。

5 分布式架构网络通信

要实现网络机器间的通讯，首先得来看看计算机系统网络通信的基本原理，在底层层面去看，网络通信需要做的就是将流从一台计算机传输到另外一台计算机，基于传输协议和网络IO来实现，其中传输协议比较出名的有tcp、udp等等，tcp、udp都是在基于Socket概念上为某类应用场景而扩展出的传输协议，网络IO，主要有bio、nio、aio三种方式，所有的分布式应用通讯都基于这个原理而实现，只是为了应用的易用，各种语言通常都会提供一些更为贴近应用易用的应用层协议。

5.1什么是RPC？

RPC全称为remote procedure call，即远程过程调用。
借助RPC可以做到像本地调用一样调用远程服务，是一种进程间的通信方式。
比如两台服务器A和B，A服务器上部署一个应用，B服务器上部署一个应用，A服务器上的应用想调用B服务器上的应用提供的方法，由于两个应用不在一个内存空间，不能直接调用，所以需要通过网络来表达调用的语义和传达调用的数据。
需要注意的是RPC并不是一个具体的技术，而是指整个网络远程调用过程。

RPC架构
一个完整的RPC架构里面包含了四个核心的组件，分别是Client，Client Stub，Server以及Server Stub，这个Stub可以理解为存根。
客户端(Client)，服务的调用方。
客户端存根(Client Stub)，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
服务端(Server)，真正的服务提供者。
服务端存根(Server Stub)，接收客户端发送过来的消息，将消息解包，并调用本地的方法。

RPC调用过程

5.2 BIO、NIO、AIO

在讲 BIO,NIO,AIO 之前先来回顾一下这样几个概念：同步与异步，阻塞与非阻塞。

同步与异步

同步： 同步就是发起一个调用后，被调用者未处理完请求之前，调用不返回。
异步： 异步就是发起一个调用后，立刻得到被调用者的回应表示已接收到请求，但是被调用者并没有返回结果，此时我们可以处理其他的请求，被调用者通常依靠事件，回调等机制来通知调用者其返回结果。

同步和异步的区别最大在于异步的话调用者不需要等待处理结果，被调用者会通过回调等机制来通知调用者其返回结果。

阻塞和非阻塞

阻塞： 阻塞就是发起一个请求，调用者一直等待请求结果返回，也就是当前线程会被挂起，无法从事其他任务，只有当条件就绪才能继续。
非阻塞： 非阻塞就是发起一个请求，调用者不用一直等着结果返回，可以先去干其他事情。

BIO

同步阻塞IO，B代表blocking。数据的读取写入必须阻塞在一个线程内等待其完成。
如果要让 BIO 通信模型 能够同时处理多个客户端请求，就必须使用多线程（主要原因是 socket.accept()、socket.read()、 socket.write() 涉及的三个主要函数都是同步阻塞的），也就是说它在接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理，处理完成之后，通过输出流返回应答给客户端，线程销毁。这就是典型的 一请求一应答通信模型

NIO

NIO是一种同步非阻塞的I/O模型，在Java 1.4 中引入了NIO框架，对应 java.nio 包，提供了 Channel , Selector，Buffer等抽象。
NIO中的N可以理解为Non-blocking，不单纯是New。它支持面向缓冲的，基于通道的I/O操作方法。 NIO提供了传统BIO模型中的 Socket 和 ServerSocket 相对应的 SocketChannel 和 ServerSocketChannel 两种不同的套接字道实现,两种通道都支持阻塞和非阻塞两种模式。阻塞模式使用就像传统中的支持一样，比较简单，但是性能和可性都不好；非阻塞模式正好与之相反。对于低负载、低并发的应用程序，可以使用同步阻塞I/O来提升开发速率和好的维护性；对于高负载、高并发的（网络）应用，应使用 NIO 的非阻塞模式来开发。

NIO 包含下面几个核心的组件：
Channel(通道)
Buffer(缓冲区)
Selector(选择器)

AIO

AIO 也就是 NIO 2。在 Java 7 中引入了 NIO 的改进版 NIO 2,它是异步非阻塞的IO模型。异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。

AIO 是异步IO的缩写，虽然 NIO 在网络操作中，提供了非阻塞的方法，但是 NIO 的 IO 行为还是同步的。对于 NIO 来说，我们的业务线程是在 IO 操作准备好时，得到通知，接着就由这个线程自行进行 IO 操作，IO操作本身是同步的。

5.3 .Netty

Netty 是由 JBOSS 提供一个异步的、 基于事件驱动的网络编程框架。
Netty 可以帮助你快速、 简单的开发出一 个网络应用， 相当于简化和流程化了 NIO 的开发过程。 作为当前最流行的 NIO 框架， Netty 在互联网领域、 大数据分布式计算领域、 游戏行业、 通信行业等获得了广泛的应用， 知名的 Elasticsearch 、 Dubbo 框架内部都采用了 Netty

为什么使用Netty

NIO缺点

• NIO 的类库和 API 繁杂，使用麻烦。你需要熟练掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等.
• 可靠性不强，开发工作量和难度都非常大
• NIO 的 Bug。例如 Epoll Bug，它会导致 Selector 空轮询，最终导致 CPU 100%。

Netty优点

• 对各种传输协议提供统一的 API
• 高度可定制的线程模型——单线程、一个或多个线程池
• 更好的吞吐量，更低的等待延迟
• 更少的资源消耗
• 最小化不必要的内存拷贝

Netty模型

Netty 抽象出两组线程池， BossGroup 专门负责接收客 户端连接， WorkerGroup 专门负责网络读写操作。NioEventLoop 表示一个不断循环执行处理 任务的线程， 每个 NioEventLoop 都有一个 selector， 用于监听绑定在其上的 socket 网络通道。 NioEventLoop 内部采用串行化设计， 从消息的读取->解码->处理->编码->发送， 始终由 IO 线 程 NioEventLoop 负责。