大话分布式系统

分布式系统的发展？

自20世纪60年代大型主机被发明出来后计算机一致在保持着快速地更新迭代，“摩尔定律”一直在发挥着作用，到20世纪80年代，计算机向微型化发展趋势日渐明显，传统的集中式处理模式越来越不能适应人们的需求。集中式主机在发展中存在的问题比如一台大型机故障了那么整个系统就没了就404了，但同时计算机的小型机PC用户的不断增加访问量的加剧，对于系统的可用性和效率的要求也越来越严苛，基于这样的环境越来越多的企业开始弃用单个大型机而转向搭建多台小型机的分布式系统。随着21世纪 移动互联网浪潮 小型Arm设备如手机的增长 伴随着前所未有的电子设备数量的增长 对传统小型机进行硬件扩展 加内存加是Cpu 已经不能满足 如此庞大体量的需求 这个IT系统带来了巨大的挑战 如阿里 就在 2009年开始 成立了 “阿里云” 计划将其电商系统 全部打造成 由"云" 处理 至 2019年 阿里云成立10周年 的双11 期间订单创建峰值更是高达54.4万笔/秒，所有交易皆是由 “云计算” 处理 是2009年第一次双11的1360倍，至此 迎来了 “分布式系统” 的黄金时代。

集中式系统和分布式系统的特点

1. 集中式系统 有一台或几台中心节点 存储数据，然后调度其他节点进行处理消息的录入，输出处理。由于是由中心的 所以不需要考虑 节点间的协作关系。传统的网站一般数据库放在一台服务器上 然后其他的服务器中心调度查询 这台服务器 他们之间协作是较简单的。
2. 分布式系统:
   • 分布性：就是说服务器可以在任何空间分布,可以放在火星，可以放在 太阳上 罒ω罒。
   • 对等性：没有主从之分谁都有可能变成老大，所以数据是冗余存放的。一个时间段内只能有一定数量的主节点但是这些节点主机也有可能挂掉，等它们挂掉其他小弟就有机会上位，走向人生巅峰，就像克隆人一样 如果被克隆的人给干掉了 你就可以代替他。
   • 并发性：假设某些节点的数据存在共享操作，协调多个节点进行高效的处理。假设 小王买 2个商品 在2个节点力 其他人和小王买的是同样的操作 此时 要同时读写 第一个商品的数据库 如果同时有大量的人都是这个操作那么就会并发阻塞 那此时比较好的方法是 一部分人 分配到别的数据库 去找到对应的商品。别全部堵在一起买一件商品。
   • 缺乏全局时钟：假设一场跑步比赛，有2个裁判，但是这两个裁判的表的时间相差1秒，那么你很难定义是谁先到终点。你处理的请求由于时间不一致，你没法判断 2个人在抢一件东西的时候 谁先抢到的 因为请求发送到了不同的机器上 这两台机器时间是不严格一致的。
   • 故障总是会发生的：假设一台机子发生故障的概率是 0.1% 那么 一千台机子至少一台机子发生故障的概率是 $1-(1-0.001{)}^{1000}$ = 63.23% 所以要假设分布式系统总是会发生故障的。

分布式系统常见故障

1.通信故障
由于分布式系统通过网络进行通信，那么必然的网络故障就会导致节点出错，消息丢失，延迟都会造成很大的影响。

• 三态

• 由于网络是不可靠的，每一次网络请求都可能存在三种状态:
  1. 成功
  2. 失败
  3. 超时

2. 节点故障
   节点发生宕机，或者由一些不可抗力所导致如：地震 洪水 挖断电缆等等。。。

什么是分布式系统呢?

网上一大堆啰里啰嗦的描述，但是我想说的是这些定义只有当你熟悉之后才能对有一个抽象的概念 它是对 一系列概念全面的概括 对于新手来说一上来 就给你这种说什么 2PC 3PC CAP理论 最终一致性 强一直 弱一致 还有 烦死人的 paxos 协议 和一大堆衍生的zooekeeper 的Zab协议 etc 的 Raft协议一上来是就想完全搞懂是很困难的，先挑一个简单的概念深入在慢慢深入才有利于理解。
对于理解一件事物比喻是绝佳的方法 大脑对熟悉的事物能相对快速的建立神经突触回路
那什么是分布式系统呢 说白了原来一个人的活干不完了 加人呗 但是加人的问题是什么呢 那就是 学习成本 和 协作成本 你不能招了个人 然后就不管了 让他自生自灭吧 至少最起码合作的2个人之间要交流 互相分配任务 处理任务 如果是要负责一个客户 那么还要 统一交换意见
要不然 意见所导致利益不一致怎么办 ，产生冲突 顾客该相信谁呢。在现实世界中如此 在计算机之间的协作亦是如此 假设有N多篇人在买东西 A计算机 觉得这个业务咱处理不过来了 就把请求发给B，B就要协助处理这个任务 但是他们之间不能 A和这个客户接触了一段时间 对这个客户基本需求都有所了解 能给他很贴心的服务 不能给到 B去处理 B就完全不认识了 请问您是谁 您需要什么 我可以哪里帮到你 那么这个顾客 下次再发请求 B 如果又交给C 那么 C有变成了一个完全不认识这个顾客的小白 如果此时C再说我没空 交给D 但C压根不知道D可能压根今天没上线来工作 那么顾客就得到了 “神奇的404” 那么如果我是这个客户鬼才和你做生意，每次请求状态都变成最初始的状态 就是无状态的。ps: Http就是无状态的协议，你请求几次http也不会记住上一次的你，是的比鱼的记忆还短。

那么从上面讲的内容可以发现在分布式系统中，最重要的是相互间的信息传递 和同步 ，这就是分布式系统需要解决的内容。这个问题 可以看做 是 著名的“拜占庭将军”问题了 什么是"拜占庭将军"问题呢 非常非常简单的说白了 就是 3 ( 2n + 1)个人 至少要 n +1 也就是 2个人 不撒谎 才保证 整个节点 之间是可信的。

有A、B、C三位将军，当A发出进攻命令时，B如果是叛徒，他可能告诉C，他收到的是“撤退”的命令。这时C收到一个“进攻”，一个“撤退“，于是C被信息迷惑，而无所适从。
如果A是叛徒。他告诉B“进攻”，告诉C“撤退”。当C告诉B，他收到“撤退”命令时，B由于收到了“进攻”的命令，而无法与C保持一致。

具体的请百度~。拜占庭问题 是1982 年由 Leslie Lamport 提出
之后在 1990年 Leslie Lamport 被提出了 “The Part-Time Parliament” 于1998年 发布了最终版本。
这个算法 大致意思是 如果每个人有一条记录 那么拼起来 就会是整个完整的记录。
其实比特币 私链也是基于这个协议的。

什么是ACID?

首先解释下什么是事务？事务就是一系列操作的集合，你要打LOL 的话 你就要 打开电脑
点击鼠标 打开lol客户端 输入账号和密码 匹配进入房间 巴拉巴拉 一系列操作 。这些操作 是有序的 要不然你颠倒 了看看 还能不能打游戏 并且要么就一起执行要么就 不要打游戏。

A：原子性(Atomicity)，一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。
事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
就像你买东西要么交钱收货一起都执行，要么发不出货，就退钱。
A向B转账 包含 A扣钱 B加钱 这两个操作 如果不是放在一起操作 要是其中一次操作失败了
要么就是A被平白无故的扣钱了 B 没加钱，
要么就是A 没扣钱 B加钱了
当然银行或商家来说第一种情况可以忍 第二种情况就坚决不能忍了。所以这两个操作要想原子一样 一家人要整整齐齐的 不能被分割 要永远在一起。

C：一致性(Consistency)，事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。
如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。
如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。

打个比方 假设你要吃饭 但是你只能有2种状态吃完 和 没吃完 但你中途突然有事不想吃了 那么你就破坏了一致性。数据库在执行中只有提交完成 和 未提交 但是 如果中间出现一种 提交到一半的中间状态 那么久违反一致性原则了。

I：隔离性(Isolation)，指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。
由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。
打个比方，你买东西本来还在犹豫，但突然有一群人想要买那个东西，你被影响了 就立马剁手买了 其实那些是托 提交了事务 实际不会购买。隔离性要保证你的操作不被影响，，应该单独给你个包间 让你单独思考买不买。

D：持久性(Durability)，指的是只要事务成功结束，它对数据库所做的更新就必须***保存下来。
即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。
打个比方，你买东西的时候需要记录在账本上，即使老板忘记了那也有据可查。

分布式系统中的事务?

在分布式数据库中，数据分散在不同的机器上可能会发生各种故障 机器宕机 网络异常等。在分布式系统中这是无法避免要解决的问题。分布式事务需要对 处于不同节点的事务进行操作 假设一个场景 一个电商网站 下单服务在数据库A 付款服务在数据库B 仓库扣减服务在数据库C 这些原来可以放在一台机子上进行 3个事务操作 要么成功 要么失败。但是现在都分布式数据库了 那就没办法 一定 满足ACID准则了

数据库 A 提交下单事务成功提交

数据库 B 负责提交付款事务没有成功提交

数据库C 负责仓库发货事务提交成功

由于B没有提交成功 那么订单状态可能还卡在未付款 但是仓库会去发货 那么就违背了原子性 一致性。ACID 准则就没法保证了，那么就需要回滚操作，但是这样顾客就白白下单了吗，浪费了顾客的感情，顾客可能就不会再下单了。这样就达不到可用性要求了 但是没办法如果一定要保证 系统的一致性原则 那和可用性 这两者必定是冲突的，绝大多数情况下 顾客是上帝(金钱) 所以会牺牲 一定的一致性原则 。

CAP 理论 和 BASE 理论

那么很明显能看出 ACID模型在分布式数据库明显存在不足，严格一致性会导致可用性的问题。
怎么构建一个兼顾可用性和一致性 的分布式系统就成为无数工程师探讨的问题，就出现了CAP和BASE这样的分布式系统经典理论。

CAP定理

2000年7月，加州伯克利分校的Eric Brewer教授在ACM PODC会议上，首次提出了CAP猜想。2年后，来自麻省理工学院的Seth Gilbert和Nancy Lynch 从理论上证明了Brewer教授CAP猜想的可行性，从此CAP理论正式在学术上成为分布式计算领域工人定理，并深深影响了分布式计算的发展

那么分布式理论说明了什么呢？

一个分布式系统不可能同时满足 一致性、可用性、和分区容错性这三个基本需求，只能满足其中两个。简单来说就是证明了，鱼和熊掌不可兼得就这个朴素的道理吧。

CAP中的一致性

分布式环境中，假设有一份数据 在 分布式系统中 会存在多个副本 那么 对 一个副本操作了那么其他副本也要保持最新副本的状态，如果能读到以前的就副本(脏读) 就是数据不一致的情况了。对某一个副本进行操作后立马就能在所有节点读到最新的值 那么就称为强一致性，这很好理解 对吧 有些App要跟新 因为有漏洞 需要强制更新 那么就是强一致更新，如果有些App只是日常普通跟新 可以保留原来的App继续使用 但最终所有人一定会都会慢慢更新的就称为 弱一致更新。

可用性

可用性就表示 全家 24小时营业，你去买东西总能在有限时间内被(在指定响应时间内)处理。不同的系统对有限时间内处理的定义不同。你用支付宝充话费那么可能需要几分钟甚至几个小时内 都认为是有限时间内 但你订外卖 可能超过平30分钟就超时了。超时当然你会大发脾气 取消订单 差评，这对商家是不可以忍受的 毕竟 顾客是上帝()。
强一致性：

分区容错性

所谓物以类聚人以群分，分布式系统可能也会被部署在某一个几种的 物理空间中 如果按地点分区 华东 华北 华西 华南 这样可能某一个区域由于 挖施工电缆 把光纤挖没了(某电商大公司) 那么这块区域就被孤立了。此时要保证系统还能正常运行。

CAP 无法同时满足,但是对于分区容错性一定是需要满足的,在一个分布式系统中 一定会存在这宕机这是常态，如果这个无法满足的话那么整个系统就是不稳定的不可靠的，那就没有存在的必要了。所以需要把经历根据任务特点 花在C(一致性)和A(可用性)之间寻求平衡。

BASE理论

eBay 的架构师 Dan Pritchett 源于对大规模分布式系统的实践总结，在 ACM 上发表文章提出 BASE 理论，BASE 理论是对 CAP 理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。

基本可用(Basically Available)： 基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。

软状态(Soft State)： 软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。MySQL Replication 的异步复制也是一种体现。

最终一致性(Eventual Consistency)： 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

ACID 和 BASE 的区别与联系：

ACID 是传统数据库常用的设计理念，追求强一致性模型。BASE 支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。

ACID 和 BASE 代表了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此 ACID 和 BASE 又会结合使用。

小结：

在分布式系统中很难做到ACID那么此时 BASE就会牺牲掉部分的一致性，数据可以暂时不一致但是最终节点之间通过特定如Paxos协议 达成最终消息的一致。BASE理论面向的是大型高可用可扩展的分布式系统，通过牺牲一定时间内的一致性，最终还是会达到最终一致，在实际分布式场景中，不同业务单元和组件对数据一致性要求是不同的，因此在具体的分布式系统架构设计中需要平衡业务和需求，灵活结合使用ACID 和BASE理论。

当然涉及到具体的解决方案
就会有2PC
3PC
Paxos算法等且听下回分解。
To be continue。。。

资料参考：

• 《从Paxos到ZooKeeper 分布式一致性原理实践》
• 第一次有人把“分布式事务”讲的这么简单明了 https://developer.51cto.com/art/201808/581174.htm