这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天
1.1 什么是分布式
分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。可以分为分布式计算、分布式存储、分布式数据库等。
优势：
- 去中心化
- 低成本
- 弹性
- 资源共享
- 可靠性高
挑战：
- 普遍的节点故障
- 不可靠的网络
- 异构的机器与硬件环境
- 安全
1.2 Why-How-What
使用者视角：
Why：
- 数据操作，对存储和计算有大规模运用的述求
- 成本低，构建在廉价服务器之上
How：
- 分布式框架
- 成熟的分布式系统
What：
- 理清规模，负载，一致性要求等
- 明确稳定性要求，制定技术方案
学习者视角：
Why：
- 后端开发必备技能
- 帮助理解后台服务器之间协作的机理
How：
- 掌握分布式理论
- 了解一致性协议
What：
- 把要点深入展开，针对难点搜索互联网资料
- 将所学知识运用于实践
1.3 常见的分布式系统
分布式存储
- Google File System：Google分布式文件系统
- Ceph：统一的分布式存储系统
- Hadoop HDFS：基于GFS架构的开源分布式文件系统
- Zookeeper：高可用的分布式数据库管理与系统协调框架
分布式数据库
- Google Spanner：Google可扩展的、全球分布式的数据库
- TiDB：开源分布式关系型数据库
- HBase：开源Nosql数据库
- MongoDB：文档数据库
分布式计算
- Hadoop：基于MapReduce分布式计算框架
- Spark：在Hadoop基础之上，使用内存来存储数据
- YARN：分布式资源调度
1.4 故障模型
- Byzantine failure :节点可以任意篡改发送给其他节点的数据
- Authentication detectable byzantine failure (ADB):Byzantine failure的特例;节点可以篡改数据，但不能伪造其他节点的数据
- Performance failure :节点未在特定时间段内收到数据，即时间太早或太晚
- Omission failure :节点收到数据的时间无限晚，即收不到数据
- Crash failure :在omission failure的基础上，增加了节点停止响应的假设，也即持续性地omission failure
- Fail-stop failure :在Crash failure的基础上增加了错误可检测的假设
1.5 共识和一致性
- 客户端A读到x=O，当客户端C正在写入时,客广端A和B可能卖到O5l-但示入完成后，A和B最终能读到一致的数据。我们称这样的一致性为Eventually consistent(最终—致性)
- 当客户端A读到更新的版本x=1后，及时将消息同步给其他客户端，这样其他客户端立即能获取到x=l。我们称这样的一致性为Linearizability(线性一致性)
- 如果要保证线性一致性，多个节点间势必需要进行协商，以寻求一致。这样增加了延迟，系统可用性便会受损
1.6 CAP理论
- C (Consistence)
一致性，指数据在多个副本之间能够保持一致的特性〔严格的一致性)。 - A (Availability)
可用性，指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。 - P (Network partitioning)
分区容错性．分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。
CAP理论往往运用于数据库领域，同样可以适用于分布式存储方向
- CA：放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择
- AP：放弃一致性〔这里说的一致性是强一致性），追求分区容错性和可用性，例如一些注重用户体验的系统
- CP：放弃可用性，追求一致性和分区容错性，例如与钱财安全相关的系统
1.7 CAP理论
1.8 ACID理论
1.9 BASE理论
二阶段提交
二阶段提交( Two-phase Commit ) :为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。
三个假设︰
- 1.引入协调者(Coordinator)和参与者(Participants)互相进行网络通信
- 2.所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上
- 3.所有节点不会永久性损坏，即使损坏后仍然可以恢复
可能出现的情况︰
- 情况1)Coordinator不宕机，Participant宕机。如下图所示，需要进行回滚操作
- 情况2)Coordinator宕机，Participant不宕机。可以起新的协调者，待查询状态后，重复二阶段提交
- 情况3)Coordinator宕机，Participant宕机。
回滚：在Prepare阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚。
两阶段提交需要注意的问题：
性能问题
- 两阶段提交需要多次节点间的网络通信，耗时过大，资源需要进行锁定，徒增资源等待时间。
协调者单点故障问题
- 如果事务协调者节点宕机，需要另起新的协调者，否则参与者处于中间状态无法完成事务。
网络分区带来的数据不一致
- 一部分参与者收到了Commit消息，另一部分参与者没收到Commit消息，会导致了节点之间数据不一致。
