分布式系统开发实战：分布式事务面临的挑战&节点复制

分布式系统开发实战：分布式事务面临的挑战&节点复制

2021-07-04 08:26·大数据架构师

分布式事务面临的挑战

分布式事务是指发生在多个数据节点之间的事务，分布式事务比单机事务要复杂得多。在分布式系统中，各个节点之间是相互独立的，需要通过网络进行沟通和协调。由于存在事务机制，可以保证每个独立节点上的数据操作可以满足ACID。但是，相互独立的节点之间无法准确地知道其他节点的事务执行情况。所以从理论上来讲，两个节点的数据是无法达到一致的状态。如果想让分布式部署的多个节点中的数据保持一致性，那么就要保证在所有节点上数据的写操作，要么全部都执行，要么全部都不执行。但是，一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果，所以它也就不知道本次事务到底应该commit还是rollback。所以，常规的解决办法就是引入一个“协调者”的组件来统一调度所有分布式节点的执行。

为了解决这种分布式-致性问题，过去人们在性能和数据一致性的反反复复权衡过程中总结了许多典型的协议和算法。其中比较著名的有二阶提交协议(Two Phase Commitment Protocol, 2PC) 、三阶提交协议(Three Phase Commitment Protocol, 3PC)、Paxos算法和Raft算法。大部分的关系型数据库通过两阶段提交算法来完成分布式事务，比如Oracle中通过dblink方式进行事务处理。同时，业界也经常使用消息的方式来解决分布式事务。

针对分布式事务，是X/Open这个组织定义的一套分布式事务的标准X/Open DTP (X/Open Distributed Transaction Processing ReferenceModel)，定义了规范和API接口，可以由各个厂商进行具体的实现。

节点复制

以下是常见的节点复制机制。

 Master-Slave复制

Slave节点一般是Master节点的备份。采用Master-Slave复制的系统，一般是如下设计的。

• ·读写请求都由Master负责。
• ·写请求写到Master上后，由Master同步到Slave上。

这种机制的特点如下。

• ·数据由Master同步到Slave时，通常采用异步方式。
• ·有良好的吞吐量，低延迟。
• ·在大多数RDBMS中支持，比如MySQL二进制日志。
• ·数据一致性通常是最终一致性。

这种机制的缺点是，如果Master“挂了”，Slave只能提供读服务，而没有写服务。

 Master-Master多主复制

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

这种机制的特点如下。

• 异步。
• 最终的一致性。
• 多个节点间需要序列化协议。