分布式系统的事务处理简析

2019独角兽企业重金招聘Python工程师标准>>>

编者按：数据服务的高可用是所有企业都想拥有的，但是要想让数据有高可用性，就需要冗余数据写多份。写多份的问题会带来一致性的问题，而一致性的问题又会带来性能问题，这就会陷入一个无解的死循环！这里所谓数据一致性，就是当多个用户试图同时访问一个数据库时，如果它们的事务同时使用相同的数据，可能会发生以下四种情况：丢失更新、未确定的相关性、不一致的分析和幻像读。阿里巴巴北京研发中心、商家业务部任资深专家陈皓的博客《分布式系统的事务处理》一文对此做了详细的描述，推荐给大家。以下是作者原文：

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

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

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

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

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

1. 从A帐号中把余额读出来；
2. 对A帐号做减法操作；
3. 把结果写回A帐号中；
4. 从B帐号中把余额读出来；
5. 对B帐号做加法操作；
6.  把结果写回B帐号中。

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

1. 在数据分区的方案中：如果A帐号和B帐号的数据不在同一台服务器上怎么办？我们需要一个跨机器的事务处理。也就是说，如果A的扣钱成功了，但B的加钱不成功，我们还要把A的操作给回滚回去。在不同的机器上实现，就会比较复杂。
2. 在数据镜像的方案中：A帐号和B帐号间的汇款是可以在一台机器上完成的，但是别忘了我们有多台机器存在A帐号和B帐号的副本。如果对A帐号的汇钱有两个并发操作（要汇给B和C），这两个操作发生在不同的两台服务器上怎么办？也就是说，在数据镜像中，在不同的服务器上对同一个数据的写操作怎么保证其一致性，保证数据不冲突？

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

• 容灾：数据不丢、结点的Failover
• 数据的一致性：事务处理
• 性能：吞吐量 、 响应时间

前面说过，要解决数据不丢，只能通过数据冗余的方法，就算是数据分区，每个区也需要进行数据冗余处理。这就是数据副本：当出现某个节点的数据丢失时可以从副本读到，数据副本是分布式系统解决数据丢失异常的唯一手段。所以，在这篇文章中，我们只讨论在数据冗余情况下考虑数据的一致性和性能的问题。简单说来：

• 要想让数据有高可用性，就得写多份数据。
• 写多份的问题会导致数据一致性的问题。
• 数据一致性的问题又会引发性能问题

这就是软件开发，按下了葫芦起了瓢。

一致性模型

说起数据一致性来说，简单说有三种类型（当然，如果细分的话，还有很多一致性模型，如：顺序一致性，FIFO一致性，会话一致性，单读一致性，单写一致性，但为了本文的简单易读，我只说下面三种）：

1. Weak 弱一致性：当你写入一个新值后，读操作在数据副本上可能读出来，也可能读不出来。比如：某些cache系统，网络游戏其它玩家的数据和你没什么关系，VOIP这样的系统，或是百度搜索引擎。
2. Eventually 最终一致性：当你写入一个新值后，有可能读不出来，但在某个时间窗口之后保证最终能读出来。比如：DNS，电子邮件、Amazon S3，Google搜索引擎这样的系统。
3. Strong 强一致性：新的数据一旦写入，在任意副本任意时刻都能读到新值。比如：文件系统，RDBMS，Azure Table都是强一致性的。

从这三种一致型的模型上来说，我们可以看到，Weak和Eventually一般来说是异步冗余的，而Strong一般来说是同步冗余的，异步的通常意味着更好的性能，但也意味着更复杂的状态控制；同步意味着简单，但也意味着性能下降。

插入一条笔记：

之前看多阿里大神程立的一个关于分布式事务的文档，目前使用较多的分布式事务解决方案有几种：
一、结合MQ消息中间件实现的可靠消息最终一致性
二、TCC补偿性事务解决方案
三、最大努力通知型方案

        第一种方案：可靠消息最终一致性，需要业务系统结合MQ消息中间件实现，在实现过程中需要保证消息的成功发送及成功消费。即需要通过业务系统控制MQ的消息状态
        第二种方案：TCC补偿性，分为三个阶段TRYING-CONFIRMING-CANCELING。每个阶段做不同的处理。
TRYING阶段主要是对业务系统进行检测及资源预留
CONFIRMING阶段是做业务提交，通过TRYING阶段执行成功后，再执行该阶段。默认如果TRYING阶段执行成功，CONFIRMING就一定能成功。
CANCELING阶段是回对业务做回滚，在TRYING阶段中，如果存在分支事务TRYING失败，则需要调用CANCELING将已预留的资源进行释放。
        第三种方案：最大努力通知xing型，这种方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种方案也是结合MQ进行实现，例如：通过MQ发送http请求，设置最大通知次数。达到通知次数后即不再通知。
具体的案例你也可以参考下这篇博客，它上面的这个案例就是结合电商支付做的系统分布式事务实现案例：http://www.roncoo.com/article/detail/124243

转载于:https://my.oschina.net/liujiest/blog/739574