共识算法-raft论文分析
五一三天 看raft，最后的实在不明白 ，版本1。0理解 记录如此，
只看结论就行，后面的可以跳过
议 | 解决问题 | 不能解决 | 正常工作 | 角色 |
|---|---|---|---|---|
2PC | CA（Consistency + Availability） 必须全部同意，缺一不可 | Partition tolerance | N:N | Coordinator/Participant |
raft | CP（Consistency + Partition tolerance） 满足 大多数 | Availability （数据不一致等待同步数据） | n/2-1:N | Leader、Follower、Candidate |
Gossip | AP (Availibity + Partition tolerance) | Consistency （允许数据丢失，选择另外一个主机作为） | 1:N |
raft相关 资源
官方：https://raft.github.io/
英文：https://raft.github.io/raft.pdf
中文：https://destinywang.github.io/blog/2018/04/15/%E7%BF%BB%E8%AF%91-In-Search-of-an-Understandable-Consensus-Algorithm-%E2%80%94%E2%80%94-Raft%E7%AE%97%E6%B3%95/
视频 https://www.youtube.com/watch?v=YbZ3zDzDnrw https://www.youtube.com/watch?v=vYp4LYbnnW8&feature=youtu.be
书籍：http://book.mixu.net/distsys/replication.html 动画：http://thesecretlivesofdata.com/raft/
Designing for Understandability: The Raft Consensus Algorithm
- 什么是 状态机(state machines)
具体来是 有限状态机(Finite-state machine)
含义可以解释为:
如果在状态S的时候发生了事件E, 那么执行动作A并且使状态S过渡( transition )到状态S'
具体参考 https://zh.wikipedia.org/wiki/有限状态机
旁白：一个机器有什么状态，不就是if else 吗，有什么用，反正我是理解不？
搜下有限状态在已有知识中的应用
- c++ tcp状态切换
可以了，看着头疼，跳过吧
- JavaScript与有限状态机阮一峰
- 在游戏动作切换
理解：客户端 不断输入，会引起内部不断的变换，无论怎么怎么变换，就像孙悟空怎么翻不出如来佛袓的五指山
无论机器怎么挂，无论日志有有多太差异，都能通过固定方式来解决，保障数据的一致性
旁白: 一口盐水喷死他。不可能，
细节：
CAP和ACID一致性区别
CAP理论的一致性是保证同样一个数据在所有不同服务器上的拷贝都是相同的，是共识，不相同的就踢掉
Consensus algorithms ，排除异己
ACID一致性是有关数据库规则，是读写一致性
- 易于理解的设计 Designing for understandability
领导选取（leader election）、
日志复制（log replication）、
安全（safety）
和成员变化（membership changes）。
第三领导选取（leader election）、
https://raft.github.io/
每一个服务器一定会处于以下三种状态中的一个：领导人、候选人、追随者
s5 ---->s3
4 什么是任期（在状态里）
就是版本号，没切换一次，增加
名称 | 描述 |
|---|---|
currentTerm | 服务器最后知道的任期号（从0开始递增） |
votedFor | 当前任期内收到选票的 候选人 id（如果没有就为null） |
log[] | 日志条目；，诶个条目包含状态机的要执行命令和从 `领导者 出收到的任期号 |
- 在所有服务器上不稳定存在的
名称 | 描述 |
|---|---|
commitIndex | 已知的被提交的最大日志条目的索引值（从0开始递增） |
lastApplied | 被状态机执行的额最大日志条目的索引值（从0开始递增） |
每次异常都保障 ，有唯一的领导被选举出来。
旁白：领导有多个可能存在
选举关键,过半，允许N/2-1 失败，
对于一个典型的 5 服务器集群，该集群能够容忍 2 台机器不能正常工作，而整个系统保持正常
日志复制普通操作
旁白：争取大多数同意本身是阻塞的，类似2pc
这地方有一个疑惑，在于具体如何处理，但是有不影响性能，这里不知道？
日志由有序的序号标记的条目组成。每个条目都包含创建时的任期号（图中框中的数字）和一个状态机需要执行的指令。
领导人来决定什么时候把日志条目应用到状态机中是安全的；这种日志条目被称为已提交
下面包好了all raft逻辑
我只能看懂，每次发送数据，不是一个一个发送，而是一批数据。
相同的日志6，后面的不是
日志校验
在没有主机异常情况下，正常的数据同步，
直接把log日志发送过去理解是不对的，
你假设是主的log日志肯定比b
- 数据不一致情况还多样 AppendEntries consistency check
腾讯云开发者
