day01分布式一致性与共识算法入门引入

悟已往之不谏知来者之可追

记录一下自己学习Raft算法的过程

---

---

前言

你能造什么样的火箭，决定你能去拧什么样的螺丝。

---

一、引入？

在进行算法的学习之前，如果有机会，你会怎么样去设计一个分布式系统？

一般来说，单机系统数据一般都是放在本地的，基本不需要与外部通信，比如单机数据库系统。但是，当有一天你的系统遇到了单机系统难以维持的高请求量，为了防止系统宕机，也为了系统有更高的可用性，可用搭建类似master-slave结构的系统，并允许请求落到slave服务器上面。

但实际上当你去深入思考之后，却发现这个东西并没有你想象的那么容易设计。

首先，相比较于单机系统，分布式系统需要和多台设备进行通信，而且通信也会超时的可能，此时发送方也无法确定通信是成功还是失败。
其次，一份数据被放在多台服务器，数据的更新也是有延迟的。
最后，当master服务器宕机了，没有一个自动机制可以立马提升slave服务器为master服务器。

这个时候你可能会想，我可以用某些方法解决上述问题，或者是用xxx框架？讲道理，一开始我也以为会有解决方法，但实际上是 没有！！！

依据就是分布式领域中CAP定理。

二、CAP定理

1.概念

基本概念：

1. Consistency：一致性
2. Availability：可用性
3. Partition-tolerance：分区容错性

我想只要稍微懂一点分布式的同学都知道 ，在异步网络模型中 ，不可能同时满足上述三个 属性，只能 同时满足两个。

在前言中说了， 通信超时 和 更新延迟 都是属于一致性 的问题，原因是存在多台服务器，而每台服务器都有自己的数据，数据冗余虽然可以提高系统的可用性 和 分区容错性，但是相应的难以满足一致性，但是想解决的话，就是要达到强一致性，比如把所有的请求全部通过单台服务器进行处理，那这个样子的话，其实就很难满足高可用性

根据经验来说一般都是可用性或者一致性是被弱化的对象。

但是对于高可用的系统而言，往往会保留强一致性。典型的就是延迟处理，利用消息队列的 中间件，在后台逐一处理队列中的请求，处理完毕的时候，就是达到了强一致性状态 。
但是要求强一致性的系统，比如元数据系统，分布式数据库系统，他们的可用性往往是有限的。

解决上述的问题，就要用到 共识算法

2.共识算法

基础概念：

共识算法

“共识”的意思就是保证所有的参与者都有相同的认知（这个地方可以理解为强一致性）。共识算法本身可以依据是否有恶意节点分为两类，大部分的时候共识算法都指向没有恶意节点的那一类，即系统节点不会向其他节点发送恶意请求，比如欺骗请求。共识算法中有名的有paxos算法，raft算法，zab算法。

---

总结

简单描述了下cap问题， 相比较Paxos算法相比，Raft算法在保持正确性的同时更容易理解，我认为偏向于入门。 接下来就开卷！！！