分布式架构基础、Paxos算法、Raft算法、系统网络通信

SpringCloudAlibaba微服务实战教程系列

-------------------------目录-------------------------------------

第一部分：分布式架构理论

　　一、分布式与集群区别

　　二、传统架构的弊端：

　　三、分布式系统面临的问题

　　四、分布式中的一致性理论(CAP与BASE理论)

　　五、一致性协议：2PC协议

　　六、一致性协议：3PC协议

　　七、分布式一致性：Paxos算法

　　八、分布式一致性：Raft算法

第二部分：分布式系统设计策略 

　　心跳机制、高可用、容错性、负载均衡

 -----------------------------------------------------------------

第一部分：分布式架构理论

 一、分布式与集群区别

　　分布式：是多个人在一起做不同的事情；

　　集群：是多个在一起做同样的事情；

二、传统架构的弊端：

互联网发展单机处理所有的业务弊端比较明显，比如修改下单业务的逻辑，用户登录的功能没有修改也需要重启项目，同时团队开发同一个项目沟通协作的成本也会随着业务的发展而增多。

1、升级单机处理能力的性价比越来越低。

2、单机处理能力存在瓶颈。

3、稳定性和可用性这两个标准很难达到。

三、分布式系统面临的问题

1、通信异常

主要包括消息丢失与消息延时：网络本来不可靠每次通信都可能存在网络不可用的风险，最终导致分布式系统无法顺利的进行网络通信，另一种是分布式节点正常执行也会出现单机延时处理，从而影响整个业务处理的消息丢失和消息延迟

 2、网络分区

网络之间出现网络不通，但是各个子节点网络正常通信，导致真个系统网络环境被分隔独立的区域，在分布式中就会存在局部小集群，对与数理的事务处理分布式一致性挑战比较大

3、节点故障

节点故障是分布式系统比较常见的问题，制的是组成分布式系统的服务器节点出现宕机或者僵死

4、三态

分布式系统每次请求响应存在三态：成功、失败、超时

超时有两种情况：

1、网络原因请求发出后对方没有收到，

2、请求接收方收到请求，业务处理成功，返回失败

四、分布式中的一致性理论

首先分布式中处理数据的一致性，保证一致性使用的是多副本存储，副本存储就是多份拷贝；

一致性分类：强一致性、弱一致性、单调弱一致性、最终一致性。

 1、分布式理论：CAP理论

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

一致性（C）：分布式系统中的一致性是所有节点的数据一致，或者说所有的副本数据一致，强一致性

可用性（A）：系统一直可用

分区容错性（P）：系统在遇到节点或者网络分区故障的时候，还可以通过一致性和可用性的服务。

CAP理论具体应用：

Redis ：属于 cp 模型。Redis-cluster 属于 ap 模型Redis-cluster  

Zookeeper：属于cp模型。

MongoDB ：属于cp模型。

Eureka：属于ap模型。

 2、分布式理论：BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。

　　BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。接下来我们着重对BASE中的三要素进行详细讲解。

　　基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。

注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子：

　　响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。

　　功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

　　弱状态：也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

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

五、一致性协议：2PC协议

什么事2PC：2PC就是分布式一致性协议，Two-Phase commit的缩写，就是两阶段提交协议，将整个事务流程分为连个阶段：准备阶段和提交阶段，2是两个阶段，p准备阶段，c是提交阶段。

例如：事务的提交（如下图），

第一阶段事务管理者向两个资源发起准备请求，两个资源返回准备完成，

第二阶段：资源记录日志undo/redo,事务管理者向两个资源发起提交请求，两个资源发起ack确认。

如果事务异常，那么第二阶段事务管理这会发起事务回滚请求，都是资源返回ack确认。

优点： 原理简单，实现方便

确定：- 同步阻塞

　　　- 单点问题

　　　- 数据不一致（第一个资源提交，第二个资源超时）

六、一致性协议：3PC协议

3PC是2PC的改进版，把二阶段提交协议的“提交事务请求”过程一分为二。形成了CanCommit、PreCommit、DoCommit三个阶段。

第一阶段CanCommit：1、事务询问参与者，2、各参与者返回是否支持事务

第二阶段PreCommit：1、向各个参与者发送预提交处理，2、参与者记录日志undo/redo，各参与者返回ack响应：同时等待提交commit或终止abort请求。

如果其中一个参与者下返回no或者超时，接下来协调者会发送alber终止请求

第三阶段Docommit：1、向各个参与者发起提交请求，2、参与者提交事务完成后返回ack确认，

如果参与者中间事务中断或者超时，协调者发起abort请求，执行第二阶段的undo日志。

3PC详细文章：https://blog.csdn.net/yulong1026/article/details/81002618

七、分布式一致性：Paxos算法

1、Paxos 算中中必须认识的三个角色

• Proposer：议案发起者（提议者）。提案者提倡客户请求，试图说服Acceptor对此达成一致，并在发生突时充当协调者以推动协议向前发展
• Acceptor：决策者，可以批准议案。Acceptor可以接受（accept）提案；如果某个提案被选（chosen），那么该提案里的value就被选定了
• Learner：最终决策的学习者（接受者）。

2、Proposer生成提案

首先Proposer在生成提案之前，需要先学习已经被选定或者可能被选定的value，然后以该value作为自己提出的议案的value，没有value被选中的时候才可以自己决定value值，学习value是通过一个prepare请求实现的。

第一步：proposer选择新提案编号N，然后向半数以上的Acceptor发送请求，要求每个acceptor做出下面的响应

a、Acceptor向Propose承诺保证不再接受任何编号小于N的提案。

b、如果Acceptor已经接受过提案，那么就想proposer反馈已经接受过编号小于N的，但是值是最大编号的提案值。

我们将这请求称为编号为N的prepare请求

第二步：

a、如果Proposer收到了半数以上的Acceptor的响应，那么它就可以生成编号为N，Value为V的提案[N,V]。这里的V是所有的响应中编号最大的提案的Value。如果所有的响应中都没有提案，那 么此时V就可以由Proposer自己选择。

b、生成提案后，Proposer将该提案发送给半数以上的Acceptor集合，并期望这些Acceptor能接受该提案。我们称该请求为Accept请求。

3、Acceptor接受提案

根据刚刚的介绍，一个Acceptor可能会受到来自Proposer的两种请求，分别是Prepare请求和Accept请求，对这两类请求作出响应的条件分别如下

Prepare请求：Acceptor可以在任何时候响应一个Prepare请求

Accept请求：在不违背Accept现有承诺的前提下，可以任意响应Accept请求

因此，对Acceptor接受提案给出如下约束：

P1a：一个Acceptor只要尚未响应过任何编号大于N的Prepare请求，那么他就可以接受这个编号为N的提

案。

Paxos算法推导过程：https://my.oschina.net/u/150175/blog/2992187 

Paxos算法在线演示：http://thesecretlivesofdata.com/raft/ 

八、分布式一致性：Raft算法

Raft将系统中的角色分为领导者（Leader）、跟从者（Follower）和候选者（Candidate）：

• Leader：接受客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后告诉Follower提交日志。

• Follower：接受并持久化Leader同步的日志，在Leader告之日志可以提交之后，提交日志。

• Candidate：Leader选举过程中的临时角色。

https://blog.csdn.net/daaikuaichuan/article/details/98627822 

第二部分：分布式系统设计策略 

一、心跳检测

二、高可用性

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

式。

1.主备模式 主备模式就是Active-Standby模式，当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按

使用者的设定以自动（热备）或手动（冷备）方式将服务切换到主机上运行。在数据库部分，习惯称之为MS模

式。MS模式即Master/Slave模式，这在数据库高可用性方案中比较常用，如MySQL、Redis等就采用MS模式实现

主从复制。保证高可用，如图所示。

MySQL之间数据复制的基础是二进制日志文件（binary log fifile）。一台MySQL数据库一旦启用二进制日志后，作

为master，它的数据库中所有操作都会以“事件”的方式记录在二进制日志中，其他数据库作为slave通过一个I/O线

程与主服务器保持通信，并监控master的二进制日志文件的变化，如果发现master二进制日志文件发生变化，则

会把变化复制到自己的中继日志中，然后slave的一个SQL线程会把相关的“事件”执行到自己的数据库中，以此实现

从数据库和主数据库的一致性，也就实现了主从复制。

 

2.互备模式 互备模式指两台主机同时运行各自的服务工作且相互监测情况。在数据库高可用部分，常见的互备是

MM模式。MM模式即Multi-Master模式，指一个系统存在多个master，每个master都具有read-write能力，会根

据时间戳或业务逻辑合并版本。

我们使用过的、构建过的MySQL服务绝大多数都是Single-Master，整个拓扑中只有一个Master承担写请求。比

如，基于Master-Slave架构的主从复制，但是也存在由于种种原因，我们可能需要MySQL服务具有Multi-Master的

特性，希望整个拓扑中可以有不止一个Master承担写请求

3.集群模式

集群模式是指有多个节点在运行，同时可以通过主控节点分担服务请求。如Zookeeper。集群模式需要解决主控节

点本身的高可用问题，一般采用主备模式。

三、容错性

容错顾名思义就是IT系统对于错误包容的能力

容错的处理是保障分布式环境下相应系统的高可用或者健壮性，一个典型的案例就是对于缓存穿透 问题的解决方

案。

1、缓存穿透

       描述：  缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。

      解决方案：接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击

2、缓存击穿

      描述：   缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力

      解决方案：设置热点数据永远不过期。加互斥锁：

四、缓存雪崩

      描述：  缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，        缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

     解决方案：缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。设置热点数据永远不过期。

四、负载均衡 

 负载有硬件负载与软件负载，负载算法：轮询、权重、ip_hash、最少链接等