分布式系统常见的事务处理机制

《分布式系统常见的事务处理机制》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、www.cdbdqn.cn分布式系统常见的事务处理机制为保障系统的可用性、可靠性以及性能，在分布式系统中，往往会设置数据冗余，即对数据进行复制。举例来说，当一个数据库的副本被破环以后，那么系统只需要转换到其他数据副本就能继续运行下去。另外一个例子，当访问单一服务器管理的数据的进程数不断增加时，系统就需要对服务器的数量进行扩充，此时，对服务器进行复制，随后让它们分担工作负荷，就可以提高性能。但同时，如何保障多个数据节点之间数据的一致以及如何处理分布式事务，将成为为一个复杂的话题。本文将介绍常用的事务处理机制。CAP定理CAP定理（也称为Brewer定理

2、），是由计算机科学家EricBrewer提出的，即在分布式计算机系统不可能同时提供以下全部三个保证：一致性（Consistency）：所有节点同一时间看到是相同的数据；可用性（Availability）：不管是否成功，确保每一个请求都能接收到响应；分区容错性（Partitiontolerance）：系统任意分区后，在网络故障时，仍能操作。显然，为了保障性能和可靠性，我们将数据复制多份，分布到多个节点上，同时也带来了一个难点，那就是如何保持各个副本数据的一致性。换句话说，我们选择了AP，则必须要牺牲掉C了。但是，在实际的应用场景中，数据的一致性往往也是

3、需要保证的。那么这是否违背了CAP定理呢？一致性模型其实，数据的一致性也分几种情况，大致可以分为：www.cdbdqn.cnWeak弱一致性：当你写入一个新值后，读操作在数据副本上可能读出来，也可能读不出来。比如：某些存储系统，搜索引擎，实时游戏，语音聊天等，这些数据本文对完整性要求不高，数据是否一致关系也不大。Eventually最终一致性：当你写入一个新值后，并不一定能马上读出来，但在某个时间窗口之后保证最终能读出来。比如：DNS，电子邮件，消息中间件等系统，大部分分布式系统技术都采用这类模式。Strong强一致性：新的数据一旦写入，在任意副本任

4、意时刻都能读到新值。比如：文件系统，RDBMS都是强一致性的。也就是说，在设计分布式系统时，我们并不一定要求是强一致性的，根据应用场景可以选择弱一致性或者是最终一致性。事务的作用事务有如下作用：保证执行结果的正确性保证数据的一致性ACID常见的事务处理机制Master-Slave复制Slave一般是Master的备份。在这样的系统中，一般是如下设计的：读写请求都由Master负责写请求写到Master上后，由Master同步到Slave上。这种机制的特点是数据同步通常是异步的。www.cdbdqn.cn有良好的吞吐量，低延迟*　在大多数　RDBMS　

5、中支持，比如　MySQL二进制日志。弱/最终一致性这种机制的缺点是，如果Master挂了，Slave只能提供读服务，而没有写服务。Master-Master多主复制指一个系统存在两个或多个Master，每个Master都提供读写服务。这个机制是Master-Slave的加强版，数据间同步一般是通过Master间的异步完成，所以是最终一致性。Master-Master的好处是，一台Master挂了，别的Master可以正常做读写服务，他和Master-Slave一样，当数据没有被复制到别的Master上时，数据会丢失。很多数据库都支持Master-Ma

6、ster的Replication的机制。这种机制的特点是：异步最终的一致性多个节点间需要序列化协议两阶段提交两阶段提交协议（Two-phasecommitprotocol，2PC）的过程涉及到协调者和参与者。协调者可以看做成事务的发起者，同时也是事务的一个参与者。对于一个分布式事务来说，一个事务是涉及到多个参与者的。具体的两阶段提交的过程如下：第一阶段（准备阶段）协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。www.cdbdqn.cn参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信

7、息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个“同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个“中止”消息。第二阶段（提交阶段）如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)当协调者节点从所有参与者节点获得的相应消息都为“同意”时:协调者

8、节点向所有参与者节点发出“正式提交(commit)”的请求。参与者节点正式完成操作，并释放在整个事务期间内占