关系型数据库遵循的ACID规则
事务在英文中是transaction，和现实中的交易很类似，它有以下的四个特征：
1、A（Atomicity）原子性
原子性很好理解，就是在一个事务中要么全部完成，要么全部都不完成，事务成功的条件是事务里的所有操作全部都成功，只要有一个操作失败，整个事务都失败，就会进行一个回滚操作（回滚即回到事务开始前的状态）。比如银行转账，从A账户转100块到B账号，分为两个步骤：1）从A账户取出100块；2）存入100块到B账户。这两步要么一块完成，要么一块不完成，如果第一步成功，第二不失败，如果不遵循原子性，那么A账户中就会莫名奇妙的少了100块。
2、C (Consistency) 一致性
一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。
3、I (Isolation) 独立性
所谓独立性就是指并发的事务之间不会相互影响，如果一个事务要访问的数据另一个事务正在修改，只要另一个事务未提交，它所访问的数据就不受未提交事务的影响，比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的
4、D (Durability) 持久性
持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。
CAP三进二
在分布式系统中，讲究C:Consistency（强一致性）、A:Availability（可用性）、P:Partition tolerance（分区容错性）
CAP的证明基于异步网络，异步网络也是反映了真实网络中情况的模型。真实的网络系统中，节点之间不可能保持同步，即便是时钟也不可能保持同步，所有的节点依靠获得的消息来进行本地计算和通讯。这个概念其实是相当强的，意味着任何超时判断也是不可能的，因为没有共同的时间标准。之后我们会扩展CAP的证明到弱一点的异步网络中，这个网络中时钟不完全一致，但是时钟运行的步调是一致的，这种系统是允许节点做超时判断的。
CAP的证明很简单，假设两个节点集{G1, G2}，由于网络分片导致G1和G2之间所有的通讯都断开了，如果不满足P，则整个网络不可用，如果在G1中写，在G2中读刚写的数据， G2中返回的值不可能G1中的写值。由于A的要求，G2一定要返回这次读请求，由于P的存在，导致C一定是不可满足的。
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。
而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。
所以我们只能在一致性和可用性之间进行权衡，没有任何分布式系统能同时保证这三点。
C:强一致性 A：高可用性 P：分布式容忍性
CA 传统Oracle数据库
AP 大多数网站架构的选择
CP Redis、Mongodb
注意：分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。
因此牺牲C换取P，这是目前分布式数据库产品的方向
一致性与可用性的决择
对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地
数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低， 有些场合对写一致性要求并不高。允许实现最终一致性。
数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，
最多只能同时较好的满足两个。
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
- CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
- CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。
- AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
BASE定理
BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。
BASE其实是下面三个术语的缩写：
- 基本可用（Basically Available）
- 软状态（Soft state）
- 最终一致（Eventually consistent）
它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法
分布式一致性理论paxos、raft、zab算法
我们这里就聊一聊raft算法：
假如我们只有一台服务器，客户端给服务器发送一个值7，只有一个节点时客户端和服务端就很容易达成共识。
但是如果我们有多个服务器的话，如何实现共识的呢，难道是客户端发送多个请求嘛，很显然不是，那么我们来看一下多节点是如何实现多节点达成共识的，这也是分布式共识的问题所在。
Raft是一种实现分布式共识的协议。
让我们来看一下它是如何实现分布式共识的，让我们看一下它的工作原理：
各节点可以分成三种状态：Follower状态、候选人状态、Leader状态。
所有节点一开始都是Follower状态，它们会开始变成候选人状态，等到有一个先变成候选人它会向剩余的节点请求投票。
被请求投票的节点会投票给候选人状态的节点
当候选人的票数超过节点数的一半以上，则会变成Leader状态。
客户端会将所有的请求发送给Leader状态的节点，Leader状态的节点会将系统对数据的更改添加到节点的日志当中，但是此日志并未提交所以服务端的值还未更改。
这里我们说了，既然有一个节点已经成为Leader状态即领导人，领导人的值变动，剩下的追随者也应该变动，那是如何实现的，上面说了当客户端把请求发给Leader状态的节点时，日志是还未提交的状态，服务端的值并未改动，所以当我们想要提交日志的时候，Leader状态的节点会将该日志复制给剩下的Follower节点。
、
其实这样还不行，其实这并不是说Leader有权限修改Follower的值，而是向Follower节点发送修改值为8的请求，大家都知道请求的发送需要网络等因素在没问题的情况下才能抵达，所以当Leader节点发送完通知时，需要Follower给Leader节点发送个收到通知的回应，这时的Leader节点会处于等待的状态，等收到大多数节点都收到该通知时才会提交日志，当Leader节点提交完日志，更改了值之后，它会再通知各个节点提交日志，并完成更新值。
PS：这里的日志不是Log日志，其实是
- 事务的读写操作被封装为Raft日志条目。
这个算法其实它是强一致和高可用的，强一致性上述已经体验到了，这里的高可用性我们可以来简单聊一聊，其实它也是得力于节点的三种状态机制，当Leader状态的节点，由于设备原因，导致Leader节点挂掉了，但是Follower状态的节点是怎么知道Leader挂掉的，这里也延申出另一个问题，我们前面也聊了Follower状态下的节点会自动的变成候选人状态，那为什么在选出了Leader，Follower就再也没出现候选人的状态呢？这就是raft的另一个特征，当候选人变成了Leader，Leader会立刻发送抑制信息，来打断Follower成为候选人的周期，所以只要Leader存在就不会有Follower状态会变成候选人，所以当Leader挂掉后就不会发送抑制信息，所以剩下的节点会继续选举其中一个节点成为Leader，然后继续执行之后的操作。
这里我们已经解释了为什么不会出现多个Leader的情况，和Leader挂了之后，各节点状态，现在聊一下比较特殊的情况，就是当两个候选人的票数一致时，怎么处理，这里我就不画图了其实跟上面的差不多。
这里其实raft也做出了处理当俩个候选人的票数一致时，所有节点会重新回到Follower状态，然后再进入候选人的状态（由于每个节点的网速等因素不可能都是一样的，所以每个节点成为候选人的时间也是不一样的），直到选出一个Leader为止。
这就是博主对Raft算法的大致了解，可能理解的还不是很深刻，欢迎大家一块讨论😊