分布式系统
分布式系统(distributed system)是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件(特别是操作系统)，而不是硬件。
为什么要分布式
集中式系统的限制与约束:
- 大规模数据下的性能问题
- 长期迭代之后的扩展问题
- 极端异常情况下的高可用问题
分布式系统的特点:
- 横向扩展(Scale Out,Scale horizontally)
- 并行计算
- 故障自动迁移
分布式系统能否同时实现以下3个目标:
- 既要提升系统的可用性
- 又要保证数据的实时可见
- 还有提升系统的容错能力
根据CAP理论，上述目标是不能同时满足的。
举个栗子:
某运营商系统，为保证系统的高可用，提出建设异地双中心节点。 运营商对双中心建设方案提出如下要求:
- 双中心要能随时切换，最好是能实现同时在线承载业务
- 双中心任意节点故障，不能影响另一节点状态
- 任意中心的系统容量和性能不能受影响
CAP理论
CAP理论是分布式系统设计的指导思想
2000年时，Eric Brewer教授在PODC会议上提出了CAP理论，但是由于没有被证明过，所以，当时只能被称为CAP猜想。这个猜想引起了巨大的反响，因为CAP很符合人们对设计纲领的预期。
在2002年后，经过Seth Gilbert和Nancy Lynch从理论上证明了CAP猜想后，CAP理论正式成为了分布式系统理论的基石之一。
CAP基本概念
CAP定理，指的是在一个分布式系统中，Consistency(一致性,C)、 Availability(可用性,A)、Partition tolerance(分区容错性,P)这三个基本需求，最多只能同时满足其中的2个
Consistency分布式结构中所有节点的请求和响应都是一致的, 合乎逻辑的, 例如节点A往X写入1然后写入2, 节点B不会先读出2再读出1Availability分布式系统中所有的操作都会成功, 我们说一个系统可用, 指的是提供写操作Partition tolerance. A partition is a communications break within a distributed system–a lost or temporarily delayed connection between two nodes.Partition tolerancemeans that the cluster must continue to work despite any number of communication breakdowns between nodes in the system. 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。
C:数据一致性
如果经过一次写请求后，两个节点都发生了数据变化。然后，读请求把这些变化后的数据都读取到了，我们就把这次数据修改称为数据发生了一致性变化。
如果系统发生问题，导致无法同步数据变化，此时，需要衡量舍弃可用性还是一致性。
A: 可用性
可用性在CAP里就是对结果的要求。它要求系统内的节点们接收到了无论是写请求还是读请求，都要能处理并给回响应结果。这里有两个隐含的前提条件:
返回结果必须在合理的时间以内，这个合理的时间是根据业务来定的。业务说必须
100毫秒内返回，合理的时间就是100毫秒，需要1秒内返回，那就是1秒，如果业务定的100毫秒，结果却在1秒才返回，那么这个系统就不满足可用性。-
需要系统内能正常接收请求的所有节点都返回结果.
如果节点不能正常接收请求了，比如宕机了，系统崩溃了，而其他节点依然能正常接收请求，那么，我们说系统依然是可用的，也就是说，部分宕机没事儿，不影响可用性指标。
如果节点能正常接收请求，但是发现节点内部数据有问题，那么也必须返回结果，哪怕返回的结果是有问题的。比如，系统有两个节点，其中有一个节点数据是三天前的，另一个节点是两分钟前的，如果，一个读请求跑到了包含了三天前数据的那个节点上，抱歉，这个节点不能拒绝，必须返回这个三天前的数据，即使它可能不太合理。
P: 分区容忍性
P 隐含两种情况
任意节点与其他节点网络故障
任意节点故障导致宕机
CAP权衡
if you have a network that may drop messages, then you cannot have both availability and consistency, you must choose one. 如果允许因为网络错误导致丢失任意的报文/消息，那这个系统就必须在可用性和一致性中选择其一.
CA without P只存在于单机系统中。比如RDBMS(关系型数据库)CP without A:如果不要求A(可用)，相当于每个请求都需要在Server之间强一致，而P(分区)会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。AP wihtout C:要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。
在分布式系统内，P是必然的发生的;同时，P发生的概率又是非常低的，需要能够快速恢复的。
CAP不是针对整个系统的。当分区发生的时候，其实对一致性和可用性的抉择是局部性的，而不是针对整个系统的。
比如，当我们做一套支付系统的时候，会员的财务相关像账户余额，账务流水是必须强一致性的。这时候，你就要考虑选C。但是，会员的名字，会员的支付设置就不必考虑强一致性，可以选择可用性A。
BASE理论
BASE 是 Basically Available(基本可用) 、Soft-state(软状态) 和 Eventually Consistent(最终一致性) 三个短语的缩写。
BASE理论是对CAP中一致性C和可用性A权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，它大大降低了我们对系统的要求。
BASE理论的核心思想是:
即使无法做到强一致性(
Strong consistency)，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性(Eventual consistency)。
Basically Available
什么是基本可用呢？假如系统出现了不可预知故障，允许损失部分可用性，当然也不能完全不可用。
损失的这部分可用性指的是什么？
响应时间上的损失:正常情况下的搜索引擎0.5秒即返回给用户结果，而
基本可用的搜索引擎可以在2秒作用返回结果。功能上的损失:在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
举个例子，在秒杀系统中，为了保证系统能抗住并发压力，并不是所有用户都能访问到真正的服务器的，大部分访问者可能会被引导到其他页面(或服务器)。而界面上可能显示的就是:商品已经售罄，谢谢惠顾。
这里我们至少保证了系统可用，如果所有用户都能访问到系统，那么最终导致系统崩溃。
Soft state
在软状态中，我们允许系统的数据存在中间状态，并且这种状态不会影响整体的可用性。
举个例子，Redis主从同步中，同步不及时，可能主数据和从数据不一致。如果我们的业务允许不一致，那么这个不一致的状态就是软状态。
也就是说，软状态允许各个节点的数据同步存在延迟。
Eventually consistent
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
分布式一致性的 3 种级别:
强一致性: 系统写入了什么，读出来的就是什么。
弱一致性: 不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
最终一致性: 弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。
最终一致性几种表现:
因果一致性(Causal consistency): 如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。读己之所写(Read your writes): 节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。会话一致性(Session consistency): 对系统数据的访问过程框定在了一个会话当中:系统能保证在同一个有效的会话中实现读己之所写的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。单调读一致性(Monotonic read consistency): 如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。单调写一致性(Monotonic write consistency): 一个系统要能够保证来自同一个节点的写操作被顺序的执行。
常见分布式组件CAP特征
| 组件 | 说明 | CAP特性 |
|---|---|---|
| ZooKeeper | 分布式一致性协调组件 | CP |
| Euerka | Netflix提供的微服务注册、发现组件 | AP |
| Redis | 基于KV的高速缓存库 | CP |
| MongoDB | 文档格式的NoSQL数据库 | CP |
| Cassandra | 分布式的列式数据库 | AP |
| DNS | 域名解析系统 | AP |
| Nacos | 注册中心、配置中心 | CP或者AP |
分布式系统下的一致性问题
拜占庭将军问题
拜占庭帝国派出多支军队去围攻一个强大的敌人，每支军队有一个将军，但由于彼此距离较远，他们之间只能通过信使传递消息。敌方很强大，必须有超过半数的拜占庭军队一同参与进攻才可能击败敌人。在此期间，将军们彼此之间需要通过信使传递消息并协商一致后，在同一时间点发动进攻。
拜占庭将军问题，其实是一个共识问题。
问题的难点
将军的忠诚度问题
信使的可靠性问题
故障容错算法(Crash Fault Tolerance, CFT)， 即非拜占庭容错算法，解决的是分布式系统中存在故障，但不存在恶意攻击的场景下的共识问题。也就是说，在该场景下可能存在消息丢失，消息重复，但不存在消息被篡改或伪造的场景。一般用于局域网场景下的分布式系统，如分布式数据库。
1990年，Leslie Lamport 在论文《The Part-time Parliament》中提出了Paxos共识算法，在工程角度实现了一种最大化保障分布式系统一致性(存在极小的概率无法实现一致)的机制。Leslie Lamport作为分布式系统领域的早期研究者，因为相关成果获得了2013年度图灵奖。
Leslie Lamport在论文中将Paxos问题表述如下:
希腊岛屿Paxon上的执法者在议会大厅中表决通过法律(一次
Paxos过程)，并通过服务员(proposer)传递纸条的方式交流信息，每个执法者会将通过的法律记录在自己的账目上。 问题在于执法者和服务员都不可靠，他们随时会因为各种事情离开议会大厅(服务器拓机或网络断开)，并随时可能有新的执法者进入议会大厅进行法律表决(新加入机器) 使用何种方式能够使得表决过程正常进行，且通过的法律不发生矛盾(对一个值达成一致)。
Paxos过程中不存在拜占庭将军问题(消息不会被篡改)和两将军问题(信道可靠)。
Paxos是首个得到证明并被广泛应用的共识算法，其原理类似两阶段提交算法，进行了泛化和扩展，通过消息传递来逐步消除系统中的不确定状态。
Paxos算法的变形: ZAB算法(zookeeper采用的一致性算法)和RAFT算法(etcd采用的一致性算法)