为什么会引出这个问题？
相对于传统的单机系统，分布式系统之间通信不可靠，同时实例本身可能会挂掉，但是这个时候还存在实例可以对外提供服务。于是各个实例上的数据不一致就出现了。
分布式系统的cap
c：强一致性，就是同一时间所有机器实例的状态数据都是一样的，不存在不一致的时刻。注意是强一致
a：可用性，就是向主机请求，在一定时间内能得到正确的响应
p：分区容忍，就是有的主机挂了，依然可以提供服务。
在分布式系统中，cap不能同时满足，而且没有一个通用的方案能解决允许故障的分布式异步模型系统的一致性问题。
为什么cap不能同时具备？
接来下就以两个db为例，说明下：
1.假设现在系统具备了c和a，也就是向其中一个db（A db）插入数据，会同步的把另一个（B db）也插入，这时候可以提供服务。此时b故障了，执行插入a的时候无法同步b，此时要想保证一致，那就不能提供写服务，因此不成立
2.假设具备 cp，允许故障但是需要一致，现在一台故障了，因为没法同步，要想一致，就不提供写服务了
3.假设ap具备，允许故障，同时支持写操作，此时通过可以通过binlog来将故障机器缺少的操作补上，但是无法达到强一致
一般交易相关的选择cp，在错误时候可以暂时不提供服务。其他的可以选择ap，例如提供不是最新的数据，但是最终是最新的
cap过于苛刻，分布式系统中还有个base理论，基本可用，软状态，最终一致
实现分布式一致的两个出名的算法
Paxos
两阶段提交的变种，提议者带上编号向其他的实例发送请求，可以提交吗？其他实例会记录每次提交和编码，如果这次请求时最大编码，那就同意，超过一半的同意就进入第二阶段提交，提交的时候同时还会验证是不是最大编码，这个算法目前是最好的算法，后续还需要研究下具体。
raft
选举出一个leader，客户端每次请求到leader这里，leader向其他实例发第一阶段的提交需求，超过一半就可以执行了。leader和follower会进行心跳侦测，同时通过心跳进行通信，leader挂了的话会重新进行选举。选举超过一半就算成功。如果分区了，两个leader，在事务提交的时候达不到一半的那个无法执行，在分区消除后，后根据最大的iterm决定谁才是leader，同时根据leader的日志进行数据同步。
--------------------------------------------8.13第一次写文章，关于分布式一致性的东西后续还会补充上来，这次只是简单的记录下-------
网友评论