一、分布式锁数据库唯一索引Redis的SETNX指令Redis的RedLock算法Zookeeper有序节点二、分布式事务2PC本地消息表三、CAP一致性可用性分区容限权衡四Paxos运行流程约束六、竞选单一Candidate的Raft多项Candidate选举数据可以在单机场景中同步引用，通过语言嵌入式锁实现流程同步。 但是，在分布式方案中，必须使用分布式锁，因为需要同步的进程可能位于不同的节点上。
阻塞锁定通常使用互斥量实现。
互斥量为0表示其他进程正在使用该锁，并且当前处于锁定状态。 互斥量为1表示未锁定。 1和0可以用整数值表示，也可以用数据是否存在来表示。
在数据库的唯一索引被锁定时在表中插入记录，并在解除锁定时删除记录。 唯一索引可以确保只插入一条记录，并根据该记录是否存在来确定是否处于锁定状态。
这些问题包括：
如果锁没有过期日期，并且解锁失败，则其他进程将无法获取该锁。 只有非阻塞锁定，如果插入失败，则会立即报告错误，并且无法重试。 不能重新输入。 获得锁的进程也必须重新获得锁。 Redis的SETNX命令使用SETNX(set if not exist )命令插入键值对。 如果密钥已经存在，则返回False；如果密钥不存在，则成功插入，然后返回True。
SETNX指令与数据库的唯一索引类似，它确保只存在一个Key键值对，因此可以通过是否存在一个Key键值对来确定是否处于锁定状态。
EXPIRE命令允许键-值对过期，从而避免了数据库的唯一索引方法无法解锁的问题。
Redis的RedLock算法使用多个Redis实例进行分布式锁定。 这是为了在发生单点故障时也能使用。
尝试从n个相互独立的Redis实例中获得锁定； 计算获取锁所需的时间。 只有比锁的过期时间短，且从大多数(n/2 )实例获取锁时，才能成功获取锁。 如果获取锁定失败，请在每个实例上解除锁定。 Zookeeper有序节点1. Zookeeper抽象模型Zookeeper提供了树结构的命名空间，/app1/p_1节点的父节点是/app1。
2 .节点类型永久节点：不会因会话结束或超时而消失； 临时节点：会话结束或超时时消失； 有序节点：节点名称后带有数字后缀，为有序节点。 例如，生成的有序节点为/lock/node-00000000，下一个有序节点为/lock/node-0000000001。 3 .监听程序在节点上注册监听程序，并在节点状态更改时向客户端发送消息。
4 .实现分布式锁定创建锁定目录/lock； 如果客户端需要获取锁，请在/lock下创建临时有序子节点。 客户端获取/lock下的子节点列表，判断自己生成的子节点是否是当前子节点列表中编号最小的子节点，如果是，则判断获得了锁； 否则，拦截其前一个子节点，从子节点收到更改通知，然后重复此过程直到获得锁定。 执行业务代码，完成后删除对应的子节点。 5 .如果获取会话超时锁定的会话超时，则会删除与该会话相对应的临时节点，并且其他会话可以获取锁定，因为已创建临时节点。 通过该实现方法可以看出，在数据库的唯一索引实现方法中没有解锁失败的问题。
6 .羊群效应一个节点未锁定，只需要监听自己前面的子节点。 这是因为，当监听到所有子节点时，如果任意一个子节点的状态发生变化，则其他所有子节点都会得到通知(羊群效应，一只羊行动时，其他羊也一起上升)，我们只知道下一个子节点得到通知
二、分布式事务，意味着事务的操作必须在不同的节点上，保证事务的ACID特性。
例如，在订单场景中，如果库存和订单不在同一个节点，则与分布式事务处理有关。
分布式锁定与分布式事务的区别：
锁定问题的关键在于进程操作的互斥关系。 例如，多个进程可以同时修改帐户的余额，如果没有互斥关系，则该帐户的余额不正确。 事务问题的关键是与事务相关的操作集必须满足ACID特性。 例如，要满足原子操作，必须执行或不执行所有这些操作。 2PC两步提交(Two-phase Commit，2PC )通过部署协调者(协调员)来协调参与者的行为，并最终确定这些参与者是否实际执行事务。
1 .执行过程1.1准备阶段协调员询问参与者事务的执行是否成功，参与者发回事务的执行结果。 问题可视为一种投票，需要所有参与者同意才能执行。
1.2提交阶段如果事务在每个参与者处成功，事务协调器将发送通知以通知参与者提交事务，否则协调器将发送通知以允许参与者回滚事务。
请注意，在准备阶段，参与者执行了事务，但尚未提交。 只有在提交阶段收到协调员的通知后，才会进行提交或回滚。
2.1同步块所有事务参与者在等待其他参与者的响应时，处于同步块等待状态，无法进行其他操作。
2.2一点问题
题协调者在 2PC 中起到非常大的作用，发生故障将会造成很大影响。特别是在提交阶段发生故障，所有参与者会一直同步阻塞等待，无法完成其它操作。
2.3 数据不一致在提交阶段，如果协调者只发送了部分 Commit 消息，此时网络发生异常，那么只有部分参与者接收到 Commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。
2.4 太过保守任意一个节点失败就会导致整个事务失败，没有完善的容错机制。
本地消息表本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性，并且使用了消息队列来保证最终一致性。
在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。之后将本地消息表中的消息转发到消息队列中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。三、CAP
分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容忍性（P：Partition Tolerance），最多只能同时满足其中两项。
一致性
一致性指的是多个数据副本是否能保持一致的特性，在一致性的条件下，系统在执行数据更新操作之后能够从一致性状态转移到另一个一致性状态。
对系统的一个数据更新成功之后，如果所有用户都能够读取到最新的值，该系统就被认为具有强一致性。
可用性可用性指分布式系统在面对各种异常时可以提供正常服务的能力，可以用系统可用时间占总时间的比值来衡量，4 个 9 的可用性表示系统 99.99% 的时间是可用的。
在可用性条件下，要求系统提供的服务一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
分区容忍性网络分区指分布式系统中的节点被划分为多个区域，每个区域内部可以通信，但是区域之间无法通信。
在分区容忍性条件下，分布式系统在遇到任何网络分区故障的时候，仍然需要能对外提供一致性和可用性的服务，除非是整个网络环境都发生了故障。
权衡在分布式系统中，分区容忍性必不可少，因为需要总是假设网络是不可靠的。因此，CAP 理论实际上是要在可用性和一致性之间做权衡。
可用性和一致性往往是冲突的，很难使它们同时满足。在多个节点之间进行数据同步时，
为了保证一致性（CP），不能访问未同步完成的节点，也就失去了部分可用性；为了保证可用性（AP），允许读取所有节点的数据，但是数据可能不一致。 四、BASEBASE 是基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）三个短语的缩写。
BASE 理论是对 CAP 中一致性和可用性权衡的结果，它的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
基本可用指分布式系统在出现故障的时候，保证核心可用，允许损失部分可用性。
例如，电商在做促销时，为了保证购物系统的稳定性，部分消费者可能会被引导到一个降级的页面。
软状态指允许系统中的数据存在中间状态，并认为该中间状态不会影响系统整体可用性，即允许系统不同节点的数据副本之间进行同步的过程存在时延。
最终一致性最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能达到一致的状态。
ACID 要求强一致性，通常运用在传统的数据库系统上。而 BASE 要求最终一致性，通过牺牲强一致性来达到可用性，通常运用在大型分布式系统中。
在实际的分布式场景中，不同业务单元和组件对一致性的要求是不同的，因此 ACID 和 BASE 往往会结合在一起使用。
五、Paxos用于达成共识性问题，即对多个节点产生的值，该算法能保证只选出唯一一个值。
主要有三类节点：
提议者（Proposer）：提议一个值；接受者（Acceptor）：对每个提议进行投票；告知者（Learner）：被告知投票的结果，不参与投票过程。执行过程
规定一个提议包含两个字段：[n, v]，其中 n 为序号（具有唯一性），v 为提议值。
1. Prepare 阶段下图演示了两个 Proposer 和三个 Acceptor 的系统中运行该算法的初始过程，每个 Proposer 都会向所有 Acceptor 发送 Prepare 请求。
当 Acceptor 接收到一个 Prepare 请求，包含的提议为 [n1, v1]，并且之前还未接收过 Prepare 请求，那么发送一个 Prepare 响应，设置当前接收到的提议为 [n1, v1]，并且保证以后不会再接受序号小于 n1 的提议。
如下图，Acceptor X 在收到 [n=2, v=8] 的 Prepare 请求时，由于之前没有接收过提议，因此就发送一个 [no previous] 的 Prepare 响应，设置当前接收到的提议为 [n=2, v=8]，并且保证以后不会再接受序号小于 2 的提议。其它的 Acceptor 类似。
如果 Acceptor 接收到一个 Prepare 请求，包含的提议为 [n2, v2]，并且之前已经接收过提议 [n1, v1]。如果 n1 > n2，那么就丢弃该提议请求；否则，发送 Prepare 响应，该 Prepare 响应包含之前已经接收过的提议 [n1, v1]，设置当前接收到的提议为 [n2, v2]，并且保证以后不会再接受序号小于 n2 的提议。
如下图，Acceptor Z 收到 Proposer A 发来的 [n=2, v=8] 的 Prepare 请求，由于之前已经接收过 [n=4, v=5] 的提议，并且 n > 2，因此就抛弃该提议请求；Acceptor X 收到 Proposer B 发来的 [n=4, v=5] 的 Prepare 请求，因为之前接收到的提议为 [n=2, v=8]，并且 2 <= 4，因此就发送 [n=2, v=8] 的 Prepare 响应，设置当前接收到的提议为 [n=4, v=5]，并且保证以后不会再接受序号小于 4 的提议。Acceptor Y 类似。
2. Accept 阶段
当一个 Proposer 接收到超过一半 Acceptor 的 Prepare 响应时，就可以发送 Accept 请求。
Proposer A 接收到两个 Prepare 响应之后，就发送 [n=2, v=8] Accept 请求。该 Accept 请求会被所有 Acceptor 丢弃，因为此时所有 Acceptor 都保证不接受序号小于 4 的提议。
Proposer B 过后也收到了两个 Prepare 响应，因此也开始发送 Accept 请求。需要注意的是，Accept 请求的 v 需要取它收到的最大提议编号对应的 v 值，也就是 8。因此它发送 [n=4, v=8] 的 Accept 请求。
3. Learn 阶段
Acceptor 接收到 Accept 请求时，如果序号大于等于该 Acceptor 承诺的最小序号，那么就发送 Learn 提议给所有的 Learner。当 Learner 发现有大多数的 Acceptor 接收了某个提议，那么该提议的提议值就被 Paxos 选择出来。
约束条件 1. 正确性
指只有一个提议值会生效。
因为 Paxos 协议要求每个生效的提议被多数 Acceptor 接收，并且 Acceptor 不会接受两个不同的提议，因此可以保证正确性。
2. 可终止性指最后总会有一个提议生效。
Paxos 协议能够让 Proposer 发送的提议朝着能被大多数 Acceptor 接受的那个提议靠拢，因此能够保证可终止性。
六、RaftRaft 也是分布式一致性协议，主要是用来竞选主节点。
Raft: Understandable Distributed Consensus 单个 Candidate 的竞选有三种节点：Follower、Candidate 和 Leader。Leader 会周期性的发送心跳包给 Follower。每个 Follower 都设置了一个随机的竞选超时时间，一般为 150ms~300ms，如果在这个时间内没有收到 Leader 的心跳包，就会变成 Candidate，进入竞选阶段。
下图展示一个分布式系统的最初阶段，此时只有 Follower 没有 Leader。Node A 等待一个随机的竞选超时时间之后，没收到 Leader 发来的心跳包，因此进入竞选阶段。此时 Node A 发送投票请求给其它所有节点。
其它节点会对请求进行回复，如果超过一半的节点回复了，那么该 Candidate 就会变成 Leader。
之后 Leader 会周期性地发送心跳包给 Follower，Follower 接收到心跳包，会重新开始计时。
多个 Candidate 竞选 如果有多个 Follower 成为 Candidate，并且所获得票数相同，那么就需要重新开始投票。例如下图中 Node B 和 Node D 都获得两票，需要重新开始投票。
由于每个节点设置的随机竞选超时时间不同，因此下一次再次出现多个 Candidate 并获得同样票数的概率很低。
数据同步 来自客户端的修改都会被传入 Leader。注意该修改还未被提交，只是写入日志中。
Leader 会把修改复制到所有 Follower。
Leader 会等待大多数的 Follower 也进行了修改，然后才将修改提交。
此时 Leader 会通知的所有 Follower 让它们也提交修改，此时所有节点的值达成一致。
参考 dddpw. 从 Paxos 到 ZooKeeper : 分布式一致性原理与实践 [M]. 电子工业出版社, 2015.Distributed locks with Redis浅谈分布式锁基于 Zookeeper 的分布式锁聊聊分布式事务，再说说解决方案分布式系统的事务处理深入理解分布式事务What is CAP theorem in distributed database system?NEAT ALGORITHMS - PAXOSPaxos By Example