目录
分布式系统原理和概念
1.分布式系统：
学习分布式，肯定的知道什么是分布式。分布式言简意赅，就是多台电脑部署实现你要实现的功能，突破了单机的性能机器的瓶颈（高性能），解决了单机的容易宕机的（高可用），另外支出了水平、垂直扩展（可扩展）的 性能。单机服务集群架构或者微服务，根据业务功能拆分都属于分布式。
单体架构：
将所有的模块写到一个Web项目中，再统一部署到一个Web服务器中，这就是单体应用架构
垂直架构：
垂直应用架构就是将原来的项目应用拆分为互不相干的几个应用，以此提升系统的整体性能。
分布式架构：
将重复的代码抽象出来，形成统一的服务，供其他系统或者业务模块调用，这就是分布式架构。
分布式确实能提高服务性能也利于方便扩展增加新功能，但是毕竟机器之间也是需要沟通的，所以也延伸出网络通信延迟、节点故障、数据分布和同步等分布式环境下的特殊挑战。
2.分布式计算：
分布式计算是一种将计算任务分解和分配到多个计算资源（如计算机、服务器或节点）上进行并行处理的计算模型。传统的计算模型通常是集中式的，即单个计算机或服务器负责处理所有的计算任务。分布式计算肯定也计算分布式的优势。高性能、容错性、资源共享提高利用率、可扩展的能力。
3.CAP 原理：
CAP 原理是对分布式系统的三个关键属性进行权衡。C（一致性）表示所有节点在同一时间具有相同的数据视图；A（可用性）表示系统在面临部分节点故障时仍然可用；P（分区容错性）表示系统在面临网络分区时仍然能够继续运行。根据 CAP 原理，分布式系统只能同时满足其中两个属性。
为什么只能满足其中两个？你们有考虑过这个问题吗。
这里有个小知识，其实这里有个关于CAP理论理解的误区。不要以为在所有时候都只能选择两个特性。在不存在网络失败的情况下（分布式系统正常运行时），C和A能够同时保证。只有当网络发生分区或失败时，才会在C和A之间做出选择。
是 CP（强一致性）还是AP（可用性）根据业务场景决定。
4.BASE 理论：
三大特征：基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventually Consistent）三个特征
为什么使用base？
相对于传统ACID（原子性、一致性、隔离性、持久性）事务模型，提供了一种更为宽松和灵活的设计思路。在分布式系统中，由于网络延迟、节点故障等原因，强调ACID特性可能导致系统的可用性和性能受到很大的限制。而采用BASE理论，可以更好地适应分布式环境下的不确定性和容错性要求，提供更高的可用性和扩展性。
通俗易懂点就是折中，数据的实时性不要求的那么高了，保证服务的一致性，对不一致的数据有补偿的措施。
5.Paxos 算法：
-
提案阶段（Prepare Phase）：
- 提议者向接受者发送一个准备请求，称为prepare请求。这个请求包含一个提案编号（proposal number）。每个提案编号都是唯一且递增的。
- 每个接受者收到prepare请求后，会比较该请求的提案编号与之前收到的最大提案编号。
- 如果新请求的提案编号大于接受者之前收到的最大提案编号，则接受者将返回一个承诺（promise），表示不再接受小于该提案编号的请求。
-
接受阶段（Accept Phase）：
- 如果提议者收到了大多数接受者的承诺，即收到了足够的接受者回复，那么提议者可以发送一个接受请求，称为accept请求。
- 这个accept请求包含了一个提案值和提案编号。
- 接受者收到accept请求后，会验证请求中的提案编号是否大于等于之前收到的最大提案编号，并且没有对应的承诺被撤销。
- 如果通过验证，接受者将接受该提案，并向所有学习者广播接受请求。
-
学习阶段（Learn Phase）：
- 学习者收到接受请求后，将学习该提案，并广播给其他节点，以达到整个系统的一致性。
- 如果一个学习者在接收到足够多的相同提案的接受请求后，可以认为提案已经达成一致。
- 总结：Paxos算法通过两个阶段的协商过程，即提案阶段和接受阶段，来保证多个节点最终达成一致的提案。它通过使用提案编号和承诺机制，避免了冲突和竞争条件的发生。最终，通过学习阶段的广播与学习，确保所有节点都达到了相同的最终状态。
6.Raft 算法：
三个角色：领导者（leader）、跟随者（follower）和候选者（candidate）。
-
领导者选举阶段（Leader Election Phase）：
- 当一个节点启动或者现任领导者失效时，所有节点都可以成为候选者。
- 候选者将发送选举请求（election request）给其他节点，要求它们投票支持自己成为新的领导者。
- 如果候选者得到了大多数节点的投票支持，即获得了绝对多数（majority）的选票，那么它就成为新的领导者。
- 如果没有候选者获得绝对多数的选票，则重新进行选举。
-
日志复制阶段（Log Replication Phase）：
- 在这个阶段中，领导者负责接收客户端的命令请求，并将其转换为日志条目。
- 领导者向跟随者发送追加条目请求（append entries request），将日志条目复制给跟随者。
- 跟随者接收到请求后，将日志条目追加到自己的日志中。
-
提交与应用阶段（Commit and Application Phase）：
- 当领导者将一条日志条目复制给大多数节点后，它会将该日志条目视为已提交（committed）。
- 领导者将通知所有节点该已提交的日志条目，并要求其应用到状态机上。
- 当节点将该已提交的日志条目应用到状态机后，该命令就被执行。
Raft算法通过领导者选举机制、日志复制和提交与应用等机制，确保了分布式系统中的一致性和可靠性。与Paxos算法相比，Raft算法的设计更加直观和易于理解，使得开发人员更容易实现和调试分布式系统。
相关材料：
