这是我参与「第五届青训营 」伴学笔记创作活动的第 10 天
什么是分布式
分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。可以分为分布式计算、分布式存储、分布式数据库等。
优势: 1.去中心化 2.低成本 3.弹性 4.资源共享 5.可靠性高
挑战: 1.普遍的节点故障 2.不可靠的网络 3.异构的机器与硬件环境 4.安全
使用者视角:
why：
1.数据爆炸，对存储和计算有大规模运用的述求
2.成本低，构建在廉价服务器之上
How :
1.分布式框架
2.成熟的分布式系统
What :
1.理清规模，负载，一致性要求等
2.明确稳定性要求，制定技术方案
学习者视角∶
Why :
1.后端开发必备技能
2.帮助理解后台服务器之间协作的机理
How :
1.掌握分布式理论
2.了解一致性协议
What :
1.把要点深入展开，针对难点搜索互联网资料
2.将所学知识运用于实践
常见的分布式系统
分布式存储：
1.Google File System ( GFS ) : google分布式文件系统
2.Ceph :统一的分布式存储系统
- 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 detectable byzantine failure (ADB):Byzantine failure的特例;节点可以篡改数据，但不能伪造其他节点的数据
Performance failure :节点未在特定时间段内收到数据，即时间太早或太晚
Omission failure :节点收到数据的时间无限晚，即收不到数据
Crash failure :在omission failure的基础上，增加了节点停止响应的假设，也即持续性地omission failure
Fail-stop failure :在Crash failure的基础上增加了错误可检测的假设
CAP理论
CAP理论往往运用于数据库领域，同样可以适用于分布式存储方向
CA:放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择
AP:放弃一致性（这里说的一致性是强一致性)，追求分区容错性和可用性，例如一些注重用户体验的系统
CP:放弃可用性，追求一致性和分区容错性，例如与钱财安全相关的系统
分布式事务
二阶段提交：
可能出现的情况︰
情况1)Coordinator不宕机，Participant宕机。
情况2)Coordinator宕机. Particinant不宕机
情况3)Coordinator宕机，Participant宕机。
回滚∶在Prepare阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚。
情况4）∶无法确认状态，需要数据库管理员的介入，防止数据库进入一个不一致的状态。
两阶段提交需注意的问题:
1.性能问题 两阶段提交需要多次节点间的网络涌信，耗时过大，资源需要进行锁定，徒增资源等待时间
2.协调者单点故障问题
如果事务协调者节点宕机，需要另起新的协调者，否则参与者处于中间状态无法完成事务。
3.网络分区带来的数据不一致 一部分参与者收到了Commit消息，另一部分参与者没收到Commit消息，会导致了节点之间数据不一致。
三阶段提交
三阶段提交vs两阶段提交
将两阶段提交中的Prepare阶段，拆成两部分∶CanCommit和PreCommit机制
解决了两个问题:
1.单点故障问题
2.阻塞问题
另外引入超时机制，在等待超时之后，会继续进行事务的提交。
Raft协议
Raft协议是一种分布式一致性算法（共识算法)，即使出现部分节点故障，网络延时等情况，也不影响各节点，进而提高系统的整体可用性。Raft是使用较为广泛的分布式协议。一定意义上讲，RAFT也使用了Quorum机制。
Leader-领导者，通常个系统中是一主( Leader )多从( Follower )。Leader负责处理所有的客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后，通知Follower提交日志。
Follower -跟随者，不会发送任何请求。接受并持久化Leader同步的日志，在Leader告知日志可以提交后，提交日志。当Leader出现故障时，主动推荐自己为Candidate。
Candidate -备选者，Leader选举过程中的临时角色。向其他节点发送请求投票信息。如果获得大多数选票，则晋升为Leader。
Log (日志）∶节点之间同步的信息，以只追加写的方式进行同步，解决了数据被覆盖的问题 Term(任期号）∶单调递增，每个Term内最多只右一个l eader1003
Committed :日志被复制到多数派节点，即可认为已经被提交
Applied:日志被应用到本地状态机:执行了log中命令，修改了内存状态
Leader选举过程︰
1.初始全部为Follower
2.Current Term + 1
3.选举自己
4.向其它参与者发起RequestVote请求，retry直到
-收到多数派请求，成为Leader并发送心业1003
-收到其它Leader的请求，转为Follower，更新自己的Term
-收到部分，但未达到多数派，选举超时，随机timeout开始下一轮
两个规则：
-在一个任期内每个参与者最多投一票（持久化)
-要成为Leader，必须拿到多数投票
Log Replication过程:
新Leader产生，Leader和Follower不同步，Leader强制覆盖Followers的不同步的日志
1.Leader收到写请求w
2将w写入本地log
3.向其它Follower发起AppendEntries RPC
4.等待多数派回复
-更新本地状态机，返回给客户端
-下一个心跳通知Follower上一个Log已经被Committed了
Committed了
- Follower也根据命令应用本地状态机5.Follower有问题，Leader—直retry
如果Leader有问题呢?
切主:
当Leader出现问题时，就需要进行重新选举。
r里新选举。
1.Leader发现失去Follower的响应，失去Leader身份2.两个Follower之间一段时间未收到心跳，重新进行选
举，选出新的Leader，此时发生了切主
3.Leader自杀重启，以Follower的身份加入进来
Stale读:
发生Leader切换，old leader收到了读请求。如果直接响应，可能会有Stale Read。如何解决?
解决方案，保证读的强一致
读操作在lease timeout内，默认自己是leader ;
不是则发起一次heartbeat。等待Commit Index应用到状态机。
Election timeout > lease timeout :新leader上任，自从上次心跳之后一定超过了Election
timeout，l日leader大概率能够发现自己的Lease过期
