由于数据量的巨大，现在大部分的Web应用都需要部署很多个数据库实例。这样，有时候某些操作就可能需要去修改多个数据库实例中的数据。传统的解决方法是使用分布式事务保证数据的全局一致性，经典的方法是使用两阶段事务提交(我的blog中已经提到过)，现在MySQL和PostgreSQL这类面向低端用户的开源数据库都支持分布式事务了，开发者泪在其中的同时，却没有考虑分布式事务是否给系统带来了伤害。
分布式事务提供的原则保证是以损害系统的可用性、性能与可伸缩性为代价的。只有在参与分布式事务的各个数据库实例都能够正常工作的前提下，分布式事务才能够顺利完成，只要有一个工作不正常，整个事务就不能完成。这样，系统的可用性就相当于参加分布式事务的各实例的可用性之积，实例越多，可用性下降越明显。从性能和可伸缩性角度看，首先是事务的总持续时间通常是各实例操作时间之和，因为一个事务中的各个操作通常是顺序执行的，这样事务的响应时间就会增加很多；其次是一般Web应用的事务都不大，单机操作时间也就几毫秒甚至不到1毫秒，一但涉及到分布式事务，提交时节点间的网络通信往返过程也为毫秒级别，对事务响应时间的影响也不可忽视。由于事务持续时间延长，事务对相关资源的锁定时间也相应增加，从而可能严重增加了并发冲突，影响到系统吞吐率和可伸缩性。
正是由于分布式事务有以上问题，在设计上就可以不采用分布式事务，而是通过其它途径来解决数据一致性问题。其中使用的最重要的技术就是消息队列和消息应用状态表。
举个例子。假设系统中有以下两个表:库存表、出入库明细表，其中库存表(记录商品当前库存、初期库存、末期库存)，出入库明细表（记录每个商品出入的详细信息）这样，在进行一笔交易时，若使用事务，就需要对数据库进行以下操作：
事务开始；
插入数据到出入库明细表中；
更新库存表；
提交事务；
假设库存表和出入库明细表存储在不同的节点上，那么上述事务就是一个分布式事务。要消除这一分布式事务，将它拆分成两个子事务，一个写入数据到出入库明细表，一个更新库存表，这样做是不行的，因为有可能出入库明细表写入成功后，更新库存表失败，系统将不能恢复到一致状态。
解决方案是使用消息队列。如下所示，先启动一个事务，写入数据到出入库明细表后，并不直接去更新库存表，而是将要对库存表进行的更新插入到消息队列中。另外有一个异步任务轮询队列内容进行处理。
那么我们现在就需要将消息队列中的信息放到库存表中来提交第二个事务，提交成功后，再从消息队列中删除该消息。由于消息队列存储与库存表不在一起，可能还没来得及将应用过的消息从队列中删除时系统就出故障了。这时系统恢复后会重新应用一次这一消息，由于幂等性，应用多次也能产生正确的结果。
但实际情况下，消息很难具有幂等性，对某表执行一次和执行多次相同的sql语句(insert、update等语句)的结束显然是不一样的。解决这一问题的方法是使用另一个表记录已经被成功应用的消息，并且这个表使用与库存表相同的存储。
我们来仔细分析一下：
1、消息队列与出入库使用同一实例，因此第一个事务不涉及分布式操作；
2、新添加的表与库存表在同一个实例中，也能保证一致性；
3、第二个事务结束后，如果出故障，那么系统会重新从消息队列中取出这一消息，但通过新添加的表可以检查出来这一消息已经被应用过，跳过这一消息实现正确的行为；
4、最后将已经成功应用，且已经从消息队列中删除的消息从新添加的表中删除，可以将新添加的表保证在很小的状态（不清除也是可以的，不影响系统正确性）。由于消息队列与新添加的表在不同实例上，将对应新添加的表的记录删除之前可能出故障。一但这时出现故障，新添加的表中会留下一些垃圾内容，但不影响系统正确性，另外这些垃圾内容也是可以正确清理的。虽然由于没有分布式事务的强一致性保证，使用上述方案在系统发生故障时，系统将短时间内处于不一致状态。但基于消息队列和消息应用状态表，最终可以将系统恢复到一致。使用消息队列方案，解除了两个数据库实例之间的紧密耦合，其性能和可伸缩性是分布式事务不可比拟的。
当然，使用分布式事务有助于简化应用开发，使用消息队列明显需要更多的工作量，两者各有优缺点。个人观点是，对于时间紧迫或者对性能要求不高的系统，应采用分布式事务加快开发效率，对于时间需求不是很紧，对性能要求很高的系统，应考虑使用消息队列方案。对于原使用分布式事务，且系统已趋于稳定，性能要求高的系统，则可以使用消息队列方案进行重构来优化性能。