#分布
1、一致性问题
一、可终止性：termination：一致的结果在有限的时间内完成
①：强一致性
顺序一致性：
线性一致性：
最终 致性（ eventual consistency ）
大部分 Web 系统实现的都是最终一致性 相对强一致性，这一类在某些方面弱化的 致性都笼统称为弱一致性（weak consistency）
②：常见算法
PBFT (Practical Byzantine Fault Tolerance ) ：确定性系列算法，容忍不超过 1/3 的故障 PoW 为代表的概率算法：共识结果则是临时的
XFT (Cross Fault Tolerance ）IBM 超级账本
③：FLP 不可能原理
FLP 不可能原理实际上告诉人们，不要浪费时间，去为异步分布式系统设计在任意场景下都能实现共识的算法 I：CAP 原理
一致性：任何操作应该都是原子的，这里指的是强一致性；
可用性：有限时间内，非失败节点都可以答应请求
分区容忍性：节点收到请求后因为没有得到其他节点的确认而不应答（牺牲可用性），要么节点只能应答非一致的结果（牺牲一致性） 备注：分区会导致“脑裂”，新出现的主节点会尝试关闭其他主节点
应用场景：
-
弱化（不）一致性：Gossip、CouchDB、Cassandra（期间不保证 致性）
-
弱化（不）可用性：MongoDB、Redis、MapReduce、Paxos\Raft（允许少数节点离线）
3.弱化（不）分区容忍性：关系型数据库、ZooKeeper（双通道,达到高稳定的网络通信）
II：ACID 原则
原子性：Atomicity:每次操作是原子的，要么成功，要么不执行（事务特性）
一致性：Consistency：数据库状态一致的，无中间状态
隔离性：Isolation：各种操作之间，互不影响
持久性：Durability：状态改变是持久的，不会失败
备注：ACID 和 BASE 在英文中分别是“酸”和 “碱”，看似对立， 是分别对 CAP
三种特性的不同取舍
A、Paxos 算法（被广泛应用在 Chubby、 ZooKeeper 这样的分布式系统中）
Proposer （提案者）：提出一个提案，等待大家批准（ chosen ）
Acceptor （接受者）：负责对提案进行技票，接受（ accept ）提案
Learner （学习者）：获取批准结果，并可以帮忙传播，不参与投 过程
Safety：只有被Proposer提案才行，被多数接受者accept的结果成为决议
Liveness:·决议总会产生，并且学习者能获得被批准的决议。
A-1:两阶段的提交
准备阶段：提案者发送自己计划提交的提案的编号到多个接收者( 试探是否可以锁定多数接收者的支持；)
提交阶段：提案者如果收到大多数的回复（一旦多数接受者接受了共同的提案值，则形成决议，成为最终确认）
B、Raft 算法
Leader （领导者）
Leader负责从客户端接收 log ，并分发到其他节点；
强制所有的 Follower 来刷新，数据的同步是单向的
Candidate （候选领导者）
Follower （眼随者）
1999 年， Castro Liskov 于论文《 Practical Byzantine Fault Tolerance and Proactive Recovery 中提出的 Practical Byzantine Fault Tolerant ( PBFT ）算法
首次将拜占庭容错算法复杂度从指数级降低到了多项式级
失效节点不超过总数 1/3 的情况下同时保证 Safety 和Liveness
PBFT 算法采用密码学相关技术（ RSA 签名算法、消息验证编码和摘要）
①：预准备阶段：主节点为从客户端收到的请求分配提案编号，然后发出预准备消息
< PRE-PREPARE,view,n,digest> ,message＞给各副本节点
②：准备阶段：副本节点收到预准备消息后，检查消息合法，如检查通过则向其他节点
发送准备消息＜PREPARE,view,n,digest,id＞，带上自己的 id 信息
③：提交阶段：广播 commit 消息，告诉其他节点某个提案 在视图 里已经处于准备状
如果集齐至少 2/ +1 个验证过的 commit 消息，则说明提案通过
C、PoW (Proof of Work ）概率算法思路
比特币的区块链网络
1、限制一段时间内整个网络中出现提案的个数（通过增加提案成本）
2、放宽对最终一致性确认的需求，约定好大家都确认并沿着已知最长的链进行拓展
3、各种 PoX 系列算法，也都是沿着这个思路进行改进，采用经济上的惩罚来制约破坏者
MTBF (Mean Time Between Failures ）：平均故障间隔时间，即系统可以无故障运行 的预期时间；
**MTTR (Mean Time to Repair ）：**平均修复时间，即发生故障后，系统可以恢复到正常 运行的预期时间
通过主从、多活等模式让多个节点集体完成原先单点的工作 这可以从概率意义上改善服务 对外的整体可靠性
**总结：**实际上，工程领域中不少问题都不存在一劳永逸的通用解法；而实用的解决思路是，合 理地在实际需求和条件限制之间进行灵活的取舍！
二、约同性：agreement： 最终的决策的结果是相同的
三、合法性：validity： 决策的结果是某个节点的提案