分布式系统的事务处理经典问题及模型

以下是作者原文：

在生产线上用一台服务器来提供数据服务的时候，经常会遇到如下的两个问题：

• 一台服务器的性能不足以提供足够的能力服务于所有网络请求。
• 担心服务器宕机，造成服务不可用或是数据丢失。

面对这些问题,我们不得不对服务器进行扩展，加入更多的机器来分担性能问题，以及解决单点故障问题。通常，我们会通过两种手段来扩展我们的数据服务：

• 数据分区：就是把数据分块放在不同的服务器上(如：uid % 16，一致性哈希等)。
• 数据镜像：让所有的服务器数据同步，提供无差别的数据服务。

使用第一种方案，无法解决数据丢失问题，单台服务器出问题时，一定会有部分数据丢失。所以，数据服务的高可用性只能通过第二种方法来完成——数据的冗余存储(一般工业界认为比较安全的备份数应该是3份，如：Hadoop和Dynamo)。 但是，加入的机器越多数据就会变得越复杂，尤其是跨服务器的事务处理，也就是跨服务器的数据一致性。这个是一个很难的问题!让我们用最经典的Use Case：“A帐号向B帐号汇钱”来说明一下，熟悉RDBMS事务的都知道从帐号A到帐号B需要6个操作：

• 从A帐号中把余额读出来;
• 对A帐号做减法操作;
• 把结果写回A帐号中;
• 从B帐号中把余额读出来;
• 对B帐号做加法操作;
• 把结果写回B帐号中。

为了数据的一致性，这6件事，要么都成功做完，要么都不成功，而且这个操作的过程中，对A、B帐号的其它访问必需锁死，所谓锁死就是要排除其它的读写操作，不然会有脏数据问题，这就是事务。但是，在加入了多个机器后，这个事情会变得复杂起来：

1，在数据分区的方案中：如果A帐号和B帐号的数据不在同一台服务器上怎么办?我们需要一个跨机器的事务处理。也就是说，如果A的扣钱成功了，但B的加钱不成功，我们还要把A的操作给回滚回去。在不同的机器上实现，就会比较复杂。

2，在数据镜像的方案中：A帐号和B帐号间的汇款是可以在一台机器上完成的，但是别忘了我们有多台机器存在A帐号和B帐号的副本。如果对A帐号的汇钱有两个并发操作(要汇给B和C)，这两个操作发生在不同的两台服务器上怎么办?也就是说，在数据镜像中，在不同的服务器上对同一个数据的写操作怎么保证其一致性，保证数据不冲突?

同时，我们还要考虑性能因素，如果不考虑性能的话，事务完成并不困难，系统慢一点就行了。除了考虑性能外，我们还要考虑可用性，也就是说，一台机器没了，数据不丢失，服务可由别的机器继续提供。 于是，我们需要重点考虑下面的这么几个情况：

（编辑：保山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!