分布式理论 | 青训营笔记

x_17
111 阅读6分钟

这是我参与「第五届青训营」笔记创作活动的第8天。

一、本堂课重点知识

今天主要的学习内容是分布式相关知识。

二、详细知识点介绍

1. 分布式概述

1.1 什么是分布式

分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。可以分为分布式计算、分布式存储、分布式数据库等。

优势：

  1. 去中心化
  2. 低成本
  3. 弹性
  4. 资源共享
  5. 可靠性高

挑战：

  1. 普遍的节点故障
  2. 不可靠的网络
  3. 异构的机器与硬件环境
  4. 安全

1.2 Why-How-What

使用者视角：

  • Why：
  1. 数据爆炸，对存储和计算有大规模运用的诉求
  2. 成本低，构建在链家服务器之上
  • How：
  1. 分布式框架
  2. 成熟的分布式系统
  • What：
  1. 理清规模，负载，一致性要求等
  2. 明确稳定性要求，制定技术方案

学习者视角：

  • Why：
  1. 后端开发必备技能
  2. 帮助理解后台服务器之间协作的机理
  • How：
  1. 掌握分布式理论
  2. 了解一致性协议
  • What：
  1. 把要点深入展开，针对难点搜索互联网资料进行学习
  2. 将所学知识运用于实践

1.3 常见的分布式系统

  • 分布式存储
    • Google File System(GFS)：google分布式文件系统
    • Ceph：统一的分布式存储系统
    • Hadoop HDFS：基于GFS架构的开源分布式文件系统
    • Zookeeper：高可用的分布式数据管理与系统协调框架
  • 分布式数据库
    • Google Spanner：google可扩展的、全球分布式的数据库
    • TiDB：开源分布式关系型数据库
    • HBase：开源Nosql数据库
    • MongoDB：文档数据库
  • 分布式计算
    • Hadoop：基于MapReduce分布式计算框架
    • Spark：在Hadoop基础之上，使用内存来存储数据
    • YARN：分布式资源调度

2. 系统模型

2.1 故障模型

  • Byzantine failure：节点可以任意篡改发送给其他节点的数据，是最难处理的故障
  • Authentication detectable byzantine failure (ADB)：节点可以篡改数据，但不能伪造其他节点的数据
  • Performance failure：节点未在特定时间段内收到数据，即时间太早或太晚
  • Omission failure：节点收到数据的时间无限晚，即收不到数据
  • Crash failure：节点停止响应，持续性的故障
  • Fail-stop failure：错误可检测，是最容易处理的故障
故障描述可能的类型
磁盘故障如：磁头不寻道、盘片不转、磁介质损伤等。年发生率1-2%Fail-stop
磁盘坏道、坏块磁头划伤引起坏道，或爱宇宙射线影响晶体管产生位反转Fail-stop,ADB
服务器主板、板卡故障可能是风扇故障，或灰尘引起的短路，或SCS引/RAID卡造成的死机Crash
网络故障电源故障、背板故障等，网卡位反转、网络流量大造成大量丢包等Byzantine,Omission
网络分区网络引起节点形成不同的子集，子集中网络相通，子集间网络不通Performance
内存故障内存出错造成的数据被篡改，分为UE、C两种ADB
线缆故障服务器光模块频素up或downPerformance,Omission
内核崩溃内核内部的致命错误，产生的kernel panicCrash
CPU做障年故障率接近1%Omission、Crash
电源故障服务器失去电力支撑Omission
软件故障如：进程crash、内存踩坏、状态不一致、配置错误、软件bug等Byzantine,Crash等

2.2 拜占庭将军问题

引入：两将军问题(Two Generals'Problem):两支军队的将军只能派信使穿越敌方领土互相通信，以此约定进攻时间。该问题希望求解如何在两名将军派出的任何信使都可能被俘虏的情况下，就进攻时间达成共识。

结论是，两将军问题是被证实无解的电脑通信问题，两支军邦队理论上永远无法达成共识

方案一：同时发送N个信使，任何一个达到对方军队，都算成功 方案二：设置超时时间，发送后未在一定时间返回，则加派信使。

共识与消息传递的不同：即使保证了消息传递成功，也不能保证达成共识

TCP三次握手是在两个方向确认包的序列号，增加了超时重试，是两将军问题的一个工程解。

考虑更多的将军数量？将军中存在叛徒？

拜占庭将军考虑更加普适的场景，例如3个将军ABC互相传递消息，消息可能丢失，也可能被篡改，当有一个将军是“"叛徒”（即出现拜占庭故障）时，整个系统无法达成一致。

如果没有“叛徒”，无论各自观察到怎样的敌情，总能达成一致的行动。

由于“叛徒”C的存在，将军A和将军B获得不同的信息。这样将军A获得2票进攻1票撤退的信息，将军B获得1票进攻2票撤退的信息，产生了不一致。

考虑当4个将军，只有1个叛徒的场曼。将军D作为消息分发中枢，约定如果没收到消息则执行撤退。

  • 如果D为“叛徒”，ABC无论收到任何消息，总能达成一致
  • D为“忠将”，ABC有2人将D的消息进行正确的传递，同样能保证最终决策符合大多数。

进而能够证明，当有3m+1个将军，其中m个"“叛徒”时，可以增加 m轮协商，最终达成一致

2.3 共识和一致性

客户端A读到x=0,当客户端C正在写入时客户端A和B可能读到O或者1。但是当C写入完成后，A和B最终能读到一致的数据。我们称这样的一致性为Eventually consistent(最终一致性)

读请求和写请求并发时可能读到旧值

当客户端A读到更新的版本x=1后，及时将消息同步给其他客户端，这样其他客户端立即能获取到x=1。我们称这样的一致性为Linearizability(线性一致性)

如果要保证“线性”一致性，多个节点间势必需要进行协商，以寻求一致。这样增加了延迟，系统可用性便会受损

一旦某个读获取到新值，所有客户端都必须返回新值

2.4 时间和事件顺序

3. 理论基础

3.1 CAP理论

3.2 ACID理论

3.3 BASE理论

4. 分布式事务

4.1 两阶段提交

4.2 三阶段提交

4.3 MVCC

5. 共识协议

5.1 Quorum NWR模型

5.2 RAFT协议

曾经修过的课程助教给我们提供了这个网址加深对Raft的理解。

5.3 Paxos协议

三、实践练习例子

1. 拜占庭将军问题

思考：

  1. 为何三次握手？而不是两次和四次？
  2. 挥手过程中，如果FIN报文丢失，会发生什么？

2. MapReduce

3. 分布式KV

四、课后个人总结

本节课对分布式相关知识有了更深理解。

五、引用参考

Raft (thesecretlivesofdata.com)

avatar
文章
阅读
粉丝