这是我参与「第五届青训营 」伴学笔记创作活动的第 7 天
分布式
优势
- 去中心化
- 低成本
- 弹性
- 资源共享
- 可靠性高(高可用)
挑战:
- 普遍的节点故障
- 不可靠的网络
- 异构的机器与硬件环境
- 安全
使用者视角:
why
- 数据爆炸，对存储和计算有大规模运用的述求
- 成本低，构架在廉价服务器之上
how
- 分布式框架
- 成熟的分布式系统
what
- 理清规模，负载，一致性要求
- 明确稳定性要求，制定技术方案
学习者视角
why
1.后端开发必备技能
2.帮助理解后台服务器之间协作的机理
how
1.掌握分布式理论
2.了解一致性协议
what
1.把那要点深入展开，针对难点搜索互联网资料进阶
2.将所学知识用于实践
常见的分布式系统
分布式存储
1.GFS(google分布式文件系统)
2.Ceph(统一的分布式存储系统)
3.Hadoop HDFS(基于GFS架构的开源分布式文件系统)
4.Zookeeper(高可用的分布式数据管理与系统协调框架)
分布式数据库
1.Google Spanner(google可拓展的，全球分布式的数据库)
2.TiDB(开源分布式关系型数据库)
3.HBase(开源Nosql数据库)
4.MongoDB(文档数据库)
分布式计算
1.Hadoop(基于MapReduce分布式计算框架)
2.Spark(再Hadoop基础上，使用内存来储存数据)
3.YARN(分布式资源调度)
故障模型(处理难度从难到易)
Byzantine failure:节点可以任意篡改发送给其他节点的数据
Authentication detecatable byzantine failure:Byzantine failure的特例；系欸但可以篡改数据，但不能伪造其他节点的数据
Performance failure:节点未在特定时间段内收到数据，即时间太早或太晚
Omission failure:节点收到数据的时间无线晚，也就是收不到数据
Crash failure:再Omission failure的基础上，增加了节点停止响应的假设，也即持续的omission failure
Fail-stop failurel:在Crash failure的基础上增加了错误可检测的假设
拜占庭将军问题(分布式经典问题)
引入:两将军问题( Two Generals' Problem) :
两支军队的将军只能派信使穿越敌方领土互相通信，以此约定进攻时间。该问题希望求解如何在两名将军派出的任何信使都可能被俘虏的情况下，就进攻时间达成共识。- 来自wikipedi
结论是，两将军问题是被证实无解的电脑通信问题，两支军队理论上永远无法达成共识。
方案一:同时发送N个信使，任何一个达到对方军队，都算成功。
方案二:设置超时时间，发送后未在一定时间返回 ，则加派信使。
共识与消息传递的不同:即使保证了消息传递成功，也不能保证达成共识
TCP三次握手是在两个方向确认包的序列号，增加了超时重试，是两将军问题的一个工程解。
思考: 1.为何三次握手?而不是两次和四次? 2.挥手过程中，如果FIN报文丢失，发生什么?
拜占庭将军问题
拜占庭将军考虑更加普适的场景，例如3个将军ABC互相传递消息，消息可能丢失，也可能被篡改，当有一个将军是"叛徒”( 即出现拜占庭故障)时，整个系统无法达成一致。如果没有"叛徒”，无论各自观察到怎样的敌情 ，总能达成一致的行动。
由于"叛徒”C的存在，将军A和将军B获得不同的信息。这样将军A获得2票进攻1票撤退的信息，将军B获得1票进攻2票撤退的信息，产生了不一致。考虑当4个将军，只有1个叛徒的场景。将军D作为消息分发中枢，约定如果没收到消息则执行撤退。
如果D为“叛徒” ABC无论收到任何消息，总能达成一致 D为“忠将”， ABC有2人将D的消息进行正确的传递，同样能保证 最终决策符合大多数。
进而能够证明，当有3m+1个将军，其中m个“叛徒”时，可以增加 m轮协商，最终达成一致
共识和一致性
客户端A读到x=0，当客户端C正在写入时客户端A和B可能读到0或者1。但是当C写入完成后，A和B最终能读到一致的数据。我们称这样的一致性为Eventually consistent (最终一致性)
当客户端A读到更新的版本x=1后，及时将消息同步给其他客户端，这样其他客户端立即能获取到x=1。我们称这样的一致性Linearizability (线性一致性)如果要保证“线性”一致性 ，多个节点间势必需要进行协商，以寻求-致。这样增加了延迟,系统可用性便会受损
时间和事件顺序 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 当且仅当a→b且ba时,我们称两个事件为并发的(concurrent)。
我们不难在图中找到若干满足条件的事件对，例如p1→r4 ,其由p1→q2-→q4→r3-→r4推导而来
CAP理论
C：一致性 A：可用性 P：分区容错性
我们无法同时满足CAP
CA:放弃分区容错性
AP:放弃一致性
CP:放弃可用性
ACID理论
事务是数据库系统中非常重要的概念
A 原子性(一定要保证)
C 一致性(一定要保证)
I 隔离性(不一定要保证)ORCALE不能保证
D 持久性(不一定要保证)mysql不能保证
BASE理论
Base理论是对CAP中一致性和可用性权衡的结果，其来源对大型互联网分布式实践的总结，是基于CAP定理逐步演化而来。
Basically Available(基本可用) :假设系统，出现了不可预知的故障,但还是能用，相比较正常的系统而言:响应时间上的损失或功能上的损失
Soft state (软状态) : 允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
Eventually consistent (最终一致性 ) : 系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一 致的状态
因此所有客户端对系统的数据访问最终都能够获取到最新的值。
分布式事务:
二阶段提交
二阶段提交( Two-phase Commit) :为了使基于分布式系统架构下的所有节点在进行事务提交时保持一 致性而设计的 种演算法。
三个假设:
1.引入协调者( Coordinator )和参与者( Participants)， 互相进行网络通信
2.所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上
3.所有节点不会永久性损坏，即使损坏后仍然可以恢复
