原文出处： waylau

为保障系统的可用性、靠得住性以及机能，在漫衍式系统中，往往会配置数据冗余，即对数据举办复制。举例来说，当一个数据库的副本被破环今后，那么系统只需要转换到其他数据副本就能继承运行下去。别的一个例子，劳务派遣管理系统，当会见单一处事器打点的数据的历程数不绝增加时，系统就需要对处事器的数量举办扩充，此时，对处事器举办复制，随后让它们分管事情负荷，就可以提高机能。但同时，如何保障多个数据节点之间数据的一致以及如那里理惩罚漫衍式事务，将成为为一个巨大的话题。本文将先容常用的事务处理惩罚机制。

CAP 定理

CAP 定理（也称为 Brewer 定理），是由计较机科学家 Eric Brewer 提出的，即在漫衍式计较机系统不行能同时提供以下全部三个担保：

一致性（Consistency）：所有节点同一时间看到是沟通的数据；

可用性（Availability）：不管是否乐成，确保每一个请求都能吸收到响应；

分区容错性（Partition tolerance）：系统任意分区后，在网络妨碍时，仍能操纵

显然，为了保障机能和靠得住性，我们将数据复制多份，漫衍到多个节点上，同时也带来了一个难点，那就是如何保持各个副本数据的一致性。换句话说，我们选择了 AP ，则必需要牺牲掉 C 了。

可是，在实际的应用场景中，数据的一致性往往也是需要担保的。那么这是否违背了 CAP 定理呢？

一致性模子

其实，数据的一致性也分几种环境，大抵可以分为：

Weak 弱一致性：当你写入一个新值后，读操纵在数据副本上大概读出来，也大概读不出来。好比：某些存储系统，搜索引擎，及时游戏，语音谈天等，这些数据本文对完整性要求不高，数据是否一致干系也不大。

Eventually 最终一致性：当你写入一个新值后，并不必然能顿时读出来，但在某个时间窗口之后担保最终能读出来。好比：DNS，电子邮件，动静中间件等系统，大部门漫衍式系统技能都回收这类模式。

Strong 强一致性：新的数据一旦写入，在任意副本任意时刻都能读到新值。好比：文件系统，RDBMS都是强一致性的。

也就是说，在设计漫衍式系统时，我们并不必然要求是强一致性的，按照应用场景可以选择弱一致性可能是最终一致性。

事务的浸染

事务有如下浸染：

担保执行功效的正确性

担保数据的一致性

ACID

机制">常见的事务处理惩罚机制

Master-Slave 复制

Slave 一般是 Master 的备份。在这样的系统中，一般是如下设计的：

读写请求都由 Master 认真。

写请求写到 Master 上后，由 Master 同步到 Slave 上。

这种机制的特点是：

数据同步凡是是异步的

有精采的吞吐量，低延迟 *　在大大都　RDBMS　中支持，好比　MySQL二进制日志

弱/最终一致性

这种机制的缺点是，假如 Master 挂了，Slave 只能提供读处事，而没有写处事。

Master-Master 多主复制

指一个系统存在两个或多个Master，每个Master都提供读写处事。这个机制是Master-Slave的增强版，数据间同步一般是通过Master间的异步完成，所以是最终一致性。 Master-Master的长处是，一台Master挂了，此外Master可以正常做读写处事，他和Master-Slave一样，当数据没有被复制到此外Master上时，数据会丢失。很大都据库都支持Master-Master的Replication的机制。

这种机制的特点是：

异步

最终的一致性

多个节点间需要序列化协议

两阶段提交

两阶段提交协议 （Two-phase commit protocol，2PC）的进程涉及到协调者和参加者。协调者可以看做成事务的提倡者，软件开发，同时也是事务的一个参加者。对付一个漫衍式事务来说，一个事务是涉及到多个参加者的。详细的两阶段提交的进程如下：

第一阶段（筹备阶段）

协调者节点向所有参加者节点询问是否可以执行提交操纵(vote)，并开始期待各参加者节点的响应。

参加者节点执行询问提倡为止的所有事务操纵，并将 Undo 信息和 Redo 信息写入日志。（留意：若乐成这里其实每个参加者已经执行了事务操纵）

各参加者节点响应协调者节点提倡的询问。假如参加者节点的事务操纵实际执行乐成，则它返回一个“同意”动静；假如参加者节点的事务操纵实际执行失败，则它返回一个“中止”动静。

第二阶段（提交阶段）