day01分布式一致性与共识算法入门引入
悟已往之不谏知来者之可追
记录一下自己学习Raft算法的过程
前言
你能造什么样的火箭，决定你能去拧什么样的螺丝。
一、引入？
在进行算法的学习之前，如果有机会，你会怎么样去设计一个分布式系统？
一般来说，单机系统数据一般都是放在本地的，基本不需要与外部通信，比如单机数据库锡系统。但是，当有一天你的系统遇到了单机系统难以维持的高请求量，为了防止系统宕机，也为了系统有更高的可用性，可用搭建类似master-slave结构的系统，并允许请求落到slave服务器上面。
但实际上当你去深入思考之后，却发现这个东西并没有你想象的那么容易设计。
首先，相比较于单机系统，分布式系统需要和多台设备进行通信，而且通信也会潮师的可能，此时发送方也无法确定通信是成功还是失败。
其次，一份数据被放在多台服务器，数据的更新也是有延迟的。
最后，当master服务器宕机了，没有一个自动机制可以立马提升slave服务器为master服务器。
这个时候你可能会想，我可以用某些方法解决上述问题，或者是用xxx框架？讲道理，一开始我也以为会有解决方法，但实际上是 没有！！！
依据就是分布式领域中CAP定理。
二、CAP定理
1.概念
基本概念：
- Consistency：一致性
- Availability：可用性
- Partition-tolerance：分区容错性
我想只要稍微懂一点分布式的同学都知道 ，在异步网络模型中 ，不可能同时满足上述三个 属性，只能 同时满足两个。
在前言中说了， 通信超时 和 更新延迟 都是属于一致性 的问题，原因是存在多台服务器，而每台服务器都有自己的数据，数据冗余虽然可以提高系统的可用性 和 分区容错性，但是相应的难以满足一致性，但是想解决的话，就是要达到强一致性，比如把所有的请求全部通过单台服务器进行处理，那这个样子的话，其实就很难满足高可用性
根据经验来说一般都是可用性或者一致性是被弱化的对象。
但是对于高可用的系统而言，往往会保留强一致性。典型的就是延迟处理，利用消息队列的 中间件，在后台逐一处理队列中的请求，处理完毕的时候，就是达到了强一致性状态 。
但是要求强一致性的系统，比如元数据系统，分布式数据库系统，他们的可用性往往是有限的。
解决上述的问题，就要用到 共识算法
2.共识算法
基础概念：
共识算法
“共识”的意思就是保证所有的参与者都有相同的认知（这个地方可以理解为强一致性）。共识算法本身可以依据是否有恶意节点分为两类，大部分的时候共识算法都指向没有恶意节点的那一类，即系统节点不会向其他节点发送恶意请求，比如欺骗请求。共识算法中有名的有paxos算法，raft算法，zab算法。
总结
简单描述了下cap问题， 相比较Paxos算法相比，Raft算法在保持正确性的同时更容易理解，我认为偏向于入门。 接下来就开卷！！！