数据一致性的解决方法

       我们平时在业务开发的时候，不可避免要在系统中串行执行一系列指令的操作。例如，我们要支付宝转账1万块钱到余额宝，这是日常生活的一件普通小事，但支付宝扣除1万之后，如果系统挂掉怎么办，这时余额宝账户并没有增加1万，数据就会出现不一致状况了。

　　同样在电商系统中，当有用户下单后，除了在订单表插入一条记录外，对应商品表的这个商品库存数量必须减1，怎么保证？！在搜索广告系统中，当用户点击某广告后，除了在点击事件表中增加一条记录外，还得去商家账户表中找到这个商家并扣除广告费吧，怎么保证？！等等，相信大家或多或多少都能碰到相似情景。

　　这些问题本质上都可以抽象为：当一个表数据更新后，怎么保证另一个表的数据也必须要更新成功。我们在单体服务系统中，这种问题很好解决，使用本地事务来保证。

1 本地事务

　　还是以支付宝转账余额宝为例，假设有

　　支付宝账户表：A（id，userId，amount）　　

　　余额宝账户表：B（id，userId，amount）

　　用户的userId=1；

　　从支付宝转账1万块钱到余额宝的动作分为两步：

　　1）支付宝表扣除1万：update A set amount=amount-10000 where userId=1;

　　2）余额宝表增加1万：update B set amount=amount+10000 where userId=1;

　　如何确保支付宝余额宝收支平衡呢？可以用事务解决嘛

Begin transaction
    update A set amount=amount-10000 where userId=1;
         update B set amount=amount+10000 where userId=1;
End transaction
commit;

　　如果系统规模较小，数据表都在一个数据库实例上，上述本地事务方式可以很好地运行，但是如果系统规模较大，比如支付宝账户表和余额宝账户表显然不会在同一个数据库实例上，他们往往分布在不同的物理节点上，这时本地事务已经失去用武之地。

　　既然本地事务失效，那么我们就需要用基于消息队列的分布式事务来解决这个问题

2 分布式事务

　　分布式事务的实现方案会很多，从可靠性和性能方面综合考虑，我觉得用消息队列的方式最为合适。设计思路为：

　　1）支付宝在扣款事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送；

　　2）当支付宝扣款事务被提交成功后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送该消息；

　　3）当支付宝扣款事务提交失败回滚后，向实时消息服务取消发送。在得到取消发送指令后，该消息将不会被发送；

　　4）对于那些未确认的消息或者取消的消息，需要有一个消息状态确认系统定时去支付宝系统查询这个消息的状态并进行更新。为什么需要这一步骤，举个例子：假设在第2步支付宝扣款事务被成功提交后，系统挂了，此时消息状态并未被更新为“确认发送”，从而导致消息不能被发送。

　　优点：消息系统独立部署，降低业务系统与消息系统间的耦合；

当然，这里还有一个很重要的问题需要解决，就是要对重复投递的消息做判断处理。