分布式系统一致性
一致性问题
在分布式环境中，由于各个节点之间的通信存在延迟和不确定性，如何保证数据的一致性称为一个挑战
一致性是指分布式系统中所有节点对于某个操作或数据状态达成的共识。
当多个节点参与某个操作时，它们需要遵循一定的规则来保证数据的一致性
CAP 和 FLP 定理
CAP 定理
在一个分布式系统中，当涉及到读写操作时，只能保证以下三点中的两点：
- 一致性：Consistency
- 可用性：Availability
- 分区容错性：Partition tolerance
Consistence（一致性）
CAP理论中的一致性：
- 强一致性（Strong Consistency）又称：线性一致性（Linearizable Consistency）
它要求多节点组成的分布式系统，能像单节点一样运作
如果一个写操作返回成功
- 那么之后的读请求都必须读到这个新数据。
如果返回失败
- 那么所有的读操作都不能读到这个数据
三种一致性：
强一致性：
当更新操作完成后，在任何时刻所有的用户或进程查询到的都是最新一次成功更新的数据
弱一致性：
当数据更新后，后续对该数据的读操作可能得到更新后的值，也可能是更新前的值
最终一致性：
在某一时刻用户或进程查询到的数据可能都不同，但是最终成功更新的数据都会背所有用户或进程查询到
Availability（可用性）
CAP理论对可用性的定义：
要求系统提供的服务必须**
处于100%可用状态**，对于用户的每一个操作请求，系统总能够在有限的时间内返回结果
用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
- 一定返回数据
- 但不保证数据是最新的
Partition Tolerance（分区容错性）
Parittion（分区）：
- 因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接，形成独立分区
Tolerance（容错）：
- 在集群出现分区中整个系统也要持续对外提供服务
由于分布式系统通过网络进行通信，网络是不可靠的
当任意数量的消息丢失或延迟到达阈值时，系统仍会继续提供服务，不会挂掉
- 一直运行，不会存在系统挂掉的问题
FLP 定理
在异步通信场景，即使只有一个进程失败，也没有任何算法能保证非失败进程达到一致性
因为同步通信中的一致性背证明是可以达到的，因此在之前一直有人尝试各种算法解决以异步环境的一致性问题，有个FLP的结果。
sample难以涉及，除非先设计几种一致性算法，并用FLP说明这些算法都是错误的
系统模型
任何分布式算法或定义，都尤其对系统场景的假设：系统模型
假设：
异步通信
与同步通信的最大区别是没有时钟、不能时间同步、不能使用超时、不能探测失败、消息可任意延迟、消息可乱序
通信健壮
只要进程非失败，消息虽会被无限延迟，但最终会被送达
并且消息仅会被送达一次（无重复）
fail-stop模型
进程失败如同宕机，不再处理任何消息
相对Byzantine模型，不会产生错误消息
失败进程数量
最多一个进程失败
都是用TCP协议（保证了消息健壮、不重复、不乱序），每个节点都有NTP时钟同步（可以使用超时），纯的异步场景相对比较少。
拜占庭将军问题
场景设定：
拜占庭帝国(Byzantine Empire)军队的几个师驻扎在敌城外，每个师都由各自的将军指挥。将军们只能通过信使相互沟通。
在观察敌情之后，他们必须制定一个共同的行动计划，如进攻(Attack)或者撤退(Retreat)，且只有当半数以上的将军共同发起进攻时才能取得胜利
然而，其中一些将军可能是叛徒，试图阻止忠诚的将军达成一致的行动计划. 更糟糕的是，负责消息传递的信使也可能是叛徒，他们可能篡改或伪造消息，也可能使得消息丢失。
当三个将军都忠诚时，可以通过投票确定一致的行动方案。
展示了一种场景：
即General A, B通过观察敌军军情并结合自身情况判断可以发起攻击
而General C通过观察敌军军情并结合自身情况判断应当撤退
最终三个将军经过投票表决得到结果为进攻: 撤退=2:1, 所以将一同发起进攻取得胜利.
对于三个将军，每个将军都能执行**两种决策(进攻或撤退)**的情况下，共存在6中不同的场景，对于其他5中场景可简单地推得，通过投票三个将军都将达成一致的行动计划.
当三个将军中存在一个叛徒时，将可能扰乱正常的作战计划
他给General A和General B发送了不同的消息, 在这种场景下General A通过投票得到进攻:撤退=1:2, 最终将作出撤退的行动计划;
General B通过投票得到进攻:撤退=2:1, 最终将作出进攻的行动计划.
结果只有General B发起了进攻并战败.
事实上，对于三个将军中存在一个叛徒的场景, 想要总能达到一致的行动方案是不可能的.
此外，论文中给出了一个更加普适的结论: 如果存在m个叛将，那么至少需要3m+1个将军，才能最终达到一致的行动方案
Paxos算法
Paxos算法解决的问题正是分布式一致性问题，即一个分布式系统中的各个进程如何就某个值（决议）达成一致
Paxos算法运行在允许宕机故障的异步系统中，不要求可靠的消息传递可容忍消息丢失、延迟、乱序以及重复
它利用Majority机制保证了2F+1的容错能力
即：2F+1个节点的系统最多允许F个节点同时出现故障
Raft算法
raft是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。
raft是一个共识算法（consensus algorithm），所谓共识，就是多个节点对某个事情达成一致的看法，即使是在部分节点故障、网络延时、网络分割的情况下。
在分布式系统中，共识算法更多用于提高系统的容错性，比如
- 分布式存储中的复制集（replication）
raft协议就是一种leader-based的共识算法，与之相应的是leaderless的共识算法。
raft 为了易于理解目标，做了两个工作：
- 问题分解
- 状态简化
问题分解：
- 是将"复制集中节点一致性"这个复杂的问题划分为数个可以被独立解释、理解、解决的子问题。
状态简化：
- 对算法做出一些限制，减少需要考虑的状态数，使得算法更加清晰，更少的不确定性
🎶🥸🏏区块链专栏前瞻
- 【区块链技术（01）】区块链概述与认识区块链基础知识；区块链标识、哈希值、梅克尔树、难度确认
- 【区块链技术（02）】区块链三种类型：公有链、私有链、联盟差异；激励问题、最终确定性问题
- 【区块链技术（03）】区块链核心技术：哈希与加密算法、智能合约；非对称加密算法与默克尔树；智能合约工作原理与区块链的关系
- 【区块链技术（04）】区块链核心技术：分布式网络的定义和特点；分布式账本的特性、实现与工作流程；共识机制
- 【区块链技术（05）】区块链核心技术：哈希算法再区块链中的应用；区块哈希与默克尔树；公开密钥算法、编码和解码算法（BASE58、BASE64）
💕👉博客专栏
SpringCloud微服务-从Spring出发学习从0学习微服务！
Golang专栏-包含基础、Gin、Goam等知识
云原生专栏-包含k8s、docker等知识
从0开始学习云计算-华为HCIP证书
JUC专栏-带你快速领悟JUC的知识！
JVM专栏-深入Java虚拟机，理解JVM的原理
基于Java研究 数据结构与算法-包含贪心算法、加权图、最短路径算法等知识
Docker专栏-上手热门容器技术Docker
SpringBoot专栏-学习SpringBoot快速开发后端
项目管理工具的学习-设计技术：Maven、Git、Gradle等相关管理工具
JavaSE-全面了解Java基础
JS专栏-使用JS作的一部分实例~
使用CSS所作的一部分案例
