这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天
分布式系统
简介
分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。可以分为分布式计算、分布式存储、分布式数据库等。
- 分布式系统的优势：去中心化、低成本、弹性、资源共享、可靠性高
- 分布式系统的挑战：故障、网络、环境、安全
常见的分布式系统
- 分布式存储：
- Google File System (GFS)：google 分布式文件系统
- Ceph：统一的分布式存储系统
- Hadoop HDFS：基于GFS架构的开源分布式文件系统
- Zookeeper：高可用的分布式数据管理与系统协调框架
- 分布式数据库：
- Google Spanner：google 可扩展的、全球分布式的数据库
- TiDB：开源分布式关系型数据库
- HBase：开源 Nosql 数据库
- MongoDB：文档数据库
- 分布式计算
- Hadoop：基于 MapReduce 分布式计算框架
- Spark：在 Hadoop 基础之上，使用内存来存储数据
- YARN：分布式资源调度
系统模型
故障模型
六种故障模型，从处理的难易程度分类：
- Byzantine failure：节点可以任意篡改发送给其他节点的数据，是最难处理的故障
- Authentication detectable byzantine failure (ADB)：节点可以篡改数据，但不能伪造其他节点的数据
- Performance failure：节点未在特定时间段内收到数据，即时间太早或太晚
- Omission failure：节点收到数据的时间无限晚，即收不到数据
- Crash failure：节点停止响应，持续性的故障
- Fail-stop failure：错误可检测，是最容易处理的故障
| 故障 | 描述 | 可能的类型 |
|---|---|---|
| 磁盘故障 | 磁头不寻道、盘片不转、磁介质损伤等。年发生率1-2% | Fail-stop |
| 磁盘坏道、坏块 | 磁头划伤引(起坏道，或受宇宙射线影响晶体管产生位反转 | Fail-stop, ADB |
| 服务器主板、板卡故障 | 可能是风扇故障，或灰尘引起的短路，或SCSI/RAID卡造成的死机 | Crash |
| 网络故障 | 电源故障、背板故障等，网卡位反转、网络流量大造成大量丢包等 | Byzantine, Omission |
| 网络分区 | 网络引起节点形成不同的子集，子集中网络相通，子集间网络不通 | Performance |
| 内存故障 | 内存出错造成的数据被篡改，分为 UE、CE 两种 | ADB |
| 线缆故障 | 服务器光模块频繁 up 或 down | Performance, Omission |
| 内核崩溃 | 内核内部的致命错误，产生的 kernel panic | Crash |
| CPU 故障 | 年故障率接近1% | Omission, Crash |
| 电源故障 | 服务器失去电力支撑 | Omission |
| 软件故障 | 进程crash、 内存踩坏、 状态不一致、配置错误、软件bug等 | Byzantine |
拜占庭将军问题
两将军问题
两支军队的将军只能派信使穿越敌方领土互相通信，以此约定进攻时间。该问题希望求解如何在两名将军派出的任何信使都可能被俘虏的情况下，就进攻时间达成共识。
结论
- 两将军问题是被证实无解的电脑通信问题，两支军队理论上永远无法达成共识
- TCP 是两将军问题的一个工程解
三将军问题
两个“忠将” A 和 B，一个“叛徒” C，互相传递消息，消息可能丢失，也可能被篡改，当有一个将军是“叛徒”（即出现拜占庭故障）时，整个系统无法达成一致。
由于“叛徒” C 的存在，将军 A 和将军 B 获得不同的信息。这样将军 A 获得 2 票进攻 1 票撤退的信息，将军 B 获得 1 票进攻2票撤退的信息，产生了不一致
四将军问题：
将军D作为消息分发中枢，约定如果没收到消息则执行撤退
步骤：
- 如果D为“叛徒”，ABC无论收到任何消息，总能达成一致
- D为“忠将”，ABC有2人将D的消息进行正确的传递，同样能保证最终决策符合大多数。
- 进而能够证明，当有3m+1个将军，m个“叛徒”时，可以进行m轮协商，最终达成一致
共识和一致性
- 不同客户端A和B看到客户端C写入，因为时机的不同，产生数据读取的偏差。引导出最终一致性的详细说明
- 要保证所有客户端看到相同的值，需要多节点进行“协商”，达成共识，来保证线性一致性
- 一致性和可用性是对矛盾
