这是我参与「第五届青训营 」笔记创作活动的第3天
大纲：
- 分布式概述
- 系统模型
- 理论基础
- 分布式事务
- 共识协议
- 分布式实践
思考：本次直播课是在昨天的软件架构概论的基础上对分布式架构的更为详细和系统的介绍，主要详细介绍了在实际生产开发中使用到的有关分布式系统的一系列知识点。从总体理论向具体理论和实践靠近。
分布式概述
分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标，可以分为分布式计算、分布式存储、分布式数据库等。
优势：
- 去中心化
- 低成本
- 弹性
- 资源共享
- 可靠性高
挑战：
- 普遍的节点故障
- 不可靠的网络
- 异构的机器与硬件环境
- 安全
常见的分布式系统：
- 分布式存储：Google File System、Ceph、Hadoop HDFS、Zookeeper
- 分布式数据库：Google Scanner等
- 分布式计算：Hadoop Spark等
分布式节点故障模型：
- Byzantine Failure 节点可以任意篡改发送给其他节点的数据
- Authorization detectable byzantine failure 是 Byzantine failure 的特例：节点可以篡改数据，但是不能伪造其他节点的数据
- Performance Failure 节点未在特定时间段内收到数据
- Omission Failure 节点收不到数据
- Crash Failure 持续性的 Omission Failure
- Fail-stop failure 在 Crash Failure 的基础上加上了错误可检测的假设
拜占庭将军问题
两将军问题：两支军队的将军只能派信使穿越敌方领土互相通信，以此约定进攻时间。该问题希望秀姐如何在两名将军派出的任何心事都可能被俘虏的情况下，就进攻时间达成共识。
这个问题的结论是，两将军问题是被证实无解的电脑通信问题，两支军队理论上永远无法达成共识。
拜占庭将军问题和 TCP 连接的问题本质上是一致的。但是 TCP 的目的是达成数据传输，拜占庭将军的问题是达成共识，这两个问题的目的不同。想要继续解决拜占庭将军问题，需要在 TCP 问题的基础上再思考解决方法来解决共识问题。
共识和一致性
最终一致性：在客户端C写入完成后 其他客户端一定读到C写入的数据，在写入过程中不保证
线性一致性：一旦其他客户端读到新值，必须保证所有客户端都读到新值
时间和时间顺序
我们定义：如果 A 和 B 是在相同节点上的两个事件，A 在 B 前发生，则 A - B。若A B不在相同节点上，且 B 依赖于 A产生的消息，则 A - B。如果不满足该条件，则认为这两个事件是并发的。
逻辑时钟：
如果 A 和 B 在同一节点，且 A 在 B 前发生，则定义 A 的时钟小于 B 的时钟。同理，在不同节点上的具有 A - B 依赖关系的时钟也是如此。
CAP 理论：
CAP 理论往往运用于数据库领域，同样也适用于分布式存储方向
- C：一致性。指数据在多个副本中能够保持一致的特性
- A：可用性，指系统提供的服务必须一直处在可用的状态
- P：分区容错性，分布式系统在遇到任何网络分区故障的时候，能够快速反应
CAP 三者不可兼备，必须牺牲一种特性。
在网络发生分区的情况下，我们必须在可用性和一致性之间做出选择。近似解决方法：将故障节点的负载转移给备用的节点负责。即故障转移。
AICD 理论：
适用于数据库事务
- A：原子性，事务包含的所有操作要么全部成功，要么全部失败
- C：一致性：一个事务执行之前和执行之后数据库必须都处于一致性状态
- I：隔离性：当多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务所干扰
- D：持久性：一个事务提交后，对数据库中数据的改变是永久性的
