这是我参与「第五届青训营 」伴学笔记创作活动的第 4 天
分布式理论
分布式概述
分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节 点的计算资源来实现共同的目标。可以分为分布式计算、分布式存 储、分布式数据库等。
优势:（下面五点接近于递进关系 在实现难度上）
- 去中心化
- 低成本
- 弹性（服务器白天用于在线服务，夜晚用于离线计算；促销进行服务扩容，结束后进行服务缩容）
- 资源共享（单个服务器存储数据有限）
- 可靠性高（通常使用多副本冗余的方式来解决存储问题）
挑战:
- 普遍的节点故障（很常见）
- 不可靠的网络（大型数据中心网络的稳定是一个很大的问题）
- 异构的机器与硬件环境
- 安全（集群被攻破的话影响比较大）
Why-How-What：
使用者视角:
-
Why:
- 数据爆炸，对存储和计算有大规模运用的述求
- 成本低 ，构建在廉价服务器之 上
-
How :
- 分布式框架
- 成熟的分布式系统
-
What :
- 理清规模，负载，一致性要求等
- 明确稳定性要求，制定技术方案 学习者视角:
-
Why :
- 后端开发必备技能
- 帮助理解后台服务器之间协作的机理
-
How :
- 掌握分布式理论
- 了解一致性协议
-
What :
- 把要点深入展开，针对难点搜索互联网资料法
- 将所学知识运用于实践
常见的分布式系统：
- 分布式存储
- 分布式数据库
- 分布式计算
系统模型
分布式故障划分成了六种类型
- Byzantine failure :节点可以任意篡改发送给其他节点的数据（多数分布式系统不解决这个问题）
- Authentication detectable byzantine failure (ADB) : Byzantine failure的特例;节点可以篡改数据，但不能伪造其他节点的数据
- Performance failure :节点未在特定时间段内收到数据，即时间太早或太晚（慢的话，还不如kill掉；不要纠结在一个节点中，感觉有点像之前说的那个长尾请求；还有不要花太多时间等待回复啥的）
- Omission failure :节点收到数据的时间无限晚，即收不到数据
- Crash failure :在omission failure的基础上，增加了节点停止响应的假设，也即持续性地omission failure（就是宕机）
- Fail-stop failure :在Crash failure的基础上增加了错误可检测的假设（fail stop是知道状态和原因的，而crash只知道状态未必知道原因）
拜占庭将军问题
-
定义
两将军问题( Two Generals' Problem ) :两支军队的将军只能派信使穿越敌方领土互相通信，以此约定进攻时间。该问题希望求解如何在两名将军派出的任何信使都可能被俘虏的情况下，就进攻时间达成共识。- 来自wikiped
-
分析
理论上两支军队理论上是永远无法达成共识的。（因为最后一次回复过程中都可能丢包，就是不知道自己的回复对方有没有收到）
这里有两个方案，但是都无法完全解决：
- 方案一: 同时发送N个信使，任何一个达到对方军队，都算成功。（但其实只是增加成功概率）
- 方案二: 设置超时时间，发送后未在一定时间返回，则加派信使。
共识与消息传递的不同:即使保证了消息传递成功，也不能保证达成共识。
TCP三次握手是在两个方向确认包的序列号，增加了超时重试，是两将军问题的一个工程解。
-
变形（增加将军数量）
拜占庭将军考虑更加普适的场景，例如3个将军ABC互相传递消息，消息可能丢失，也可能被篡改，当有一个将军是"叛徒”( 即出现拜占庭故障)时，整个系统无法达成一致。
如果没有"叛徒”，无论各自观察到怎样的敌情，总能达成一致的行动。由于'叛徒”C的存在，将军A和将军B获得不同的信息。这样将军A获得2票进攻1票撤退的信息，将军B获得1票进攻2票撤退的信息，产生了不一致。
那么我们这里的做法是增加一名将军D，将军D只是作为消息分发的中枢，不会进行投票，然后我们增加一轮协商，则场景如下：
增加一名将军，考虑当4个将军，只有1个叛徒的场景，其中将军D作为消息分发中枢，有两轮处理：
- 第一轮是将军D从将军ABC中各自收集信息，然后把协商结果发送到将军ABC中
- 第二轮是将军D不参与，剩下的将军ABC按照之前三个人那样通信，每个人发送到另外两个人那里（这里发送的信息应该是ABC在第一轮中从D中收集到的信息）
这样的情况下，我觉得是：可能最终的决策结果和原来的不一样，但是至少能够保证几个将军最终执行是一致的。考虑下面的情况：
-
如果D为“叛徒”， ABC无论收到任何消息，总能达成一致
我的理解是，如果D叛徒，那么第一轮中ABC可能收到的都不同，但是由于是奇数，所以第二轮中肯定能够确定为撤退/进攻中的一个，且ABC将军的结果达成一致（每个人收到2/1的结果），但可能并不是最开始协商的结果。
-
如果D为“忠将”， ABC有2人将D的消息进行正确的传递，同样能保证最终决策符合大多数。
即此时第一轮ABC收到的结果都一致，只是第二轮中ABC中有一个没有正确发送，但是对于其他两个来说，要么是3:0 要么是2:1 结果不变，这种情况下最终的执行一致且也是最开始协商的结果。
然后有说到：
进而能够证明，当有3m+1个将军，其中m个"叛徒”时，可以增加 m轮协商，最终达成一致。
共识和一致性
-
最终一致性
客户端A读到x=0 ,当客户端C正在写入时客户端A和B可能读到0或者1。但是当C写入完成后，A和B最终能读到一致的数据。我们称这样的一致性为Eventuallyconsistent (最终一致性)
-
线性一致性（等同于强一致性）
当客户端A读到更新的版本x=1后，及时将消息同步给其他客户端，这样其他客户端立即能获取到x=1。我们称这样的一致性为Linearizability (线性一致性) 如果要保证“线性”一致性，多个节点间势必需要进行协商，以寻求一致。这样增加了延迟,系统可用性便会受损
lamport逻辑时钟
可以搜一搜
CAP理论
- C (Consistence) 一致性，指数据在多个副本之间能够保持一致的特性(严格的一致性)
- A (Availability) 可用性，指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应但是不保证获取的数据为最新数据。
- P (Network partitioning) 分区容错性，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。
无法同时满足CAP
CAP理论往往运用于数据库领域，同样可以适用于分布式存储方向
- CA：放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择
- AP：放弃一致性(这里说的一致性是强一 致性)，追求分区容错性和可用性 ，例如一些注重用户体验的系统
- CP：放弃可用性，追求一致性和分区容错性，例如与钱财安全相关的系统
上面：
P1的值进行了修改，为1，然后由于这里P1和P2之间的消息传递失败了（比如长时间故障），没有同步成功，此时P2的值还是0，下面根据选择有分支：
- 左上角：注重可用性A，而不考虑一致性，此时就是继续让用户读取P2，此时从P1和P2中读取的结果就不满足一致性了。但至少还是可用的。
- 右上角：注重一致性C，而不考虑可用性，直接让P2拒绝服务，这样还是会回到P1中读取，最终结果还是一致的
下面进行取舍优化：
增加master节点和backup节点的划分，把故障节点的负载转移给备用节点负责，如上图中下面的两张图。
所有请求都由master节点来负责，如果master发生故障，再把请求都转到backup节点来负责
这样可用性和一致性都有部分丢失，但是两方兼容还是比较好的
ACID理论
事务是数据庠系統中非常重要的概念,它是数据庠管理系统执行过程中的一个還輯単元,它能移保証一个事努中的所有操作要么全部抗行，要么全都不执行。 数据库事务们有四个特性ACID ,即分別是原子性( Atomicity)、一致性( Consistency)、隔离性( Isolation )和持久性(Durability )
- 原子性(A)。原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚。
- 一致性(C)。一致性是指事务必须使数据库从一个一致性状态变换到另一个致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态（这边是事务的一致性，而CAP是线性一致性）
- 隔离性(I)。隔离性是当多个用户并发访问数据库时，数据库为每一个用户开启的事务 ，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离
- 持久性(D)。持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障 的情况下也不会丢失提交事务的操作。
BASE理论
Base理论是对CAP中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结,是基于CAP定理逐步演化而来的。
其核心思想是:
- Basically Available(基本可用) :假设系统,出现了不可预知的故障,但还是能用，相比较正常的系统而言:响应时间上的损失，或功能上的损失
- Soft state (软状态) : 允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
- Eventually consistent (最终一致性) : 系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一 致的状态因此所有客户端对系统的数据访问最终都能够获取到最新的值。
