「分布式理论 - 现代架构基石」第五届字节跳动青训营 - 后端专场

常见的分布式

分布式存储

Google File System ( GFS ) : google分布式文件系统
Ceph :统一的分布式存储系统
Hadoop HDFS:基于GFS架构的开源分布式文件系统
Zookeeper :高可用的分布式数据管理与系统协调框架

分布式数据库

1.Google Spanner : google可扩展的、全球分布式的数据库
2.TiDB:开源分布式关系型数据库
3.HBase :开源Nosql数据库
4.MongoDB:文档数据库

分布式计算

1.Hadoop:基于MapReduce分布式计算框架
2.Spark :在Hadoop基础之上，使用内存来存储数据
3.YARN:分布式资源调度

故障模型

Byzantine failure:节点可以任意篡改发送给其他节点的数据
Authentication detectable byzantine failure (ADB):Byzantine failure的特例;节点可以篡改数据，但不能伪造其他节点的数据
Performance failure :节点未在特定时间段内收到数据，即时间太早或太晚
Omission failure :节点收到数据的时间无限晚，即收不到数据
Crash failure :在omission failure的基础上，增加了节点停止响应的假设，也即持续性地omission failure
Fail-stop failure :在Crash failure的基础上增加了错误可检测的假设

拜占庭将军问题

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

结论是，两将军问题是被证实无解的电脑通信问题，两支军队理论上永远无法达成共识。方案一∶同时发送N个信使，任何一个达到对方军队，都算成功。方案二︰设置超时时间，发送后未在一定时间返回，则加派信使。

共识与消息传递的不同:即使保证了消息传递成功，也不能保证达成共识 TCP三次握手是在两个方向确认包的序列号，增加了超时重试，是两将军问题的一个工程解。

时间和事件顺序

1978年Leslie Lamport发表在Communications of the ACM上的论文Time, Clocks, and the Ordering of Events in a Distributed System 我们定义“happened before”关系，记为"→"。其满足如下三个条件:

如果a和b是在相同节点上的两个事件，a在b之前发生，则定义︰a→b
如果事件a表示某个节点发送某条消息，b是另一个节点接受这条消息，则有a→b
如果有a→b 且b→c ，则有a→c

当且仅当 -/-> b 且b -/-> a时，我们称两个事件为并发的(concurrent). 我们不难在图中找到若干满足条件的事件对，例如 p1→r4，其由p1一q2→q4→r3一r4推导而来

理论基础

CAP

选项	描述
C(Consistence)	一致性，指数据在多个副本之间能够保持一致的特性（严格的一致性)。
A(Availability)	可用性，指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。
P(Network partitioning)	分区容错性，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。

CAP理论往往运用于数据库领域，同样可以适用于分布式存储方向

CA:放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择
AP:放弃一致性(这里说的一致性是强一致性），追求分区容错性和可用性，例如一些注重用户体验的系统
CP:放弃可用性，追求一致性和分区容错性，例如钱财安全相关的系统

BASE理论

Base理论是对CAP中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于CAP定理逐步演化而来的。其核心思想是∶

Basically Available(基本可用):假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言∶响应时间上的损失，或功能上的损失
Soft state (软状态）∶允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
Eventually consistent(最终一致性）∶系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。

二阶段提交

可能出现的情况∶

情况1 ) Coordinator不宕机，Participant宕机。如下图所示，需要进行回滚操作
情况2 )Coordinator宕机，Participant不宕机。可以起新的协调者，待查询状态后，重复二阶段提交
情况3 )Coordinator宕机，Participant宕机。

回滚︰在Prepare阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚。

情况3∶无法确认状态，需要数据库管理员的介入，防止数据库进入一个不一致的状态

两阶段提交需注意的问题:

性能问题

两阶段提交需要多次节点间的网络通信，耗时过大，资源需要进行锁定，徒增资源等待时间。
协调者单点故障问题

如果事务协调者节点宕机，需要另起新的协调者，否则参与者处于中间状态无法完成事务。
网络分区带来的数据不一致

一部分参与者收到了Commit消息，另一部分参与者没收到Commit消息，会导致了节点之间数据不一致。

思考?

1.日志被保存在「可靠」的存储设备上。如何保证这一点?

2.参与者Commit了，但Ack信息协调者没收到。怎么办?

三阶段提交

三阶段提交vs两阶段提交将两阶段提交中的Prepare阶段，拆成两部分∶CanCommit和PreCommit机制

解决了两个问题: 1.单点故障问题⒉阻塞问题

另外引入超时机制，在等待超时之后，会继续进行事务的提交。

思考? 三阶段缓和了两阶段面临的问题，但依然没有解决∶1.性能问题 2.网络分区场景带来的数据─致性问题

分布式理论 - 现代架构基石｜ 青训营笔记