第一部分：分布式架构理论
作者：互联网
转发地址：https://www.cnblogs.com/niunafei/p/13330721.html
第一部分：分布式架构理论
一、单机、集群、分布式的区别
单机结构
一个系统的业务量放在一个项目里面，这个项目部署在一台服务器，整个项目的服务由这台服务器提供。
缺点：处理能力有限，抗风险能力低。
集群结构
单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。为了处理哪个节点来处理请求的问题，需要有一个调度者，这个调度者就是“负载均衡服务器”。
负载均衡服务器：硬负载F5，软负载Nginx，实例负载Ribbon
缺点：当你的业务发展到一定程度的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不明显了。这时候，你就需要使用微服务结构了。
分布式结构
分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。
优点：1、系统之间的耦合度降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界明确，开发效率提升。2、系统的扩展性更好。3.服务的复用性更高。比如：多个系统可以服用登陆系统。
总结：分布式：是多个人在一起做不同的事情；
集群：是多个在一起做同样的事情；
二、传统架构的弊端
1、升级单机处理能力的性价比越来越低。
2、单机处理能力存在瓶颈。
3、稳定性和可用性这两个标准很难达到。
三、分布式系统面临的问题
1、通信异常
主要包括消息丢失与消息延时：1、网络不可用的风险；2、分布式节点正常执行也会出现单机延时处理。
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日志。
六、分布式一致性：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的提案。
七、分布式一致性：Raft算法
Raft将系统中的角色分为领导者（Leader）、跟从者（Follower）和候选者（Candidate）：
Leader：接受客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后告诉Follower提交日志。
Follower：接受并持久化Leader同步的日志，在Leader告之日志可以提交之后，提交日志。
Candidate：Leader选举过程中的临时角色。
标签：架构,请求,理论,提交,一致性,提案,Acceptor,分布式 来源： https://blog.csdn.net/m0_37824308/article/details/114266325