前几天跟朋友聊到这个话题，当时没有想到分布式锁，后在google上查询，发现这篇文章逻辑比较清楚——交易系统在分布式环境下的探讨
众所周知在互联网公司，如果你没有对你的系统进行分库分表，那你怎么好意思跟人打招呼？但是分库分表带来的难题也是众所周知的，除了多机查询（分批查询、合并结果等等）等问题，最重要的就是保障事务问题，这一点在交易系统中尤为重要。
最为简单的解决方式就是使用分布式事务，业界已经有了规范–XA，他使用两阶段提交来保证分布式下的事务，具体的规范我就不说了，可以到维基百科上详细了解，看似完美，但是这个解决方案在分库分表的环境下有些“重”。我们完全可以退一步来想，我们既然不能保证强一致性，那么我们保证最终一致性也可以达到理想的结果。我们主要依托如下两个理论来构建一个最终一致性的系统：CAP理论、BASE模型。
让我们举个栗子来说明：假如一个用户在亚马逊上买了一本书，用户需要做的就是点击生成订单，而后付款最后等待收货，此时从技术的角度来看，我们大致有四个系统：用户系统，账户系统，订单系统，物流系统，而订单的状态变化大致如下：初始–已支付–已发货–完成。正常情况下订单状态会依次变更，而后亚马逊收到钱款后组织发货。但是在现实中就没有那么幸福了，用户付款后亚马逊没收到钱，收到钱后没有告知用户发货。因为这四个系统所使用的DB、JVM甚至机房都不一样。对于用户系统，习惯上对于整个交易系统来讲它是用户展示结果的所有我们暂时不去讨论，那么对于账户系统，不管用户使用账户余额支付还是使用网络支付，最终的结构都是用户的余额减少而商家的余额增加。
那么对于这个局部的交易过程（用户余额减少–商家余额增加），我们同样不敢肯定其是否同处一个DB，所以我们使用分布式锁保证同一时间对该资源（账户余额）的其他操作是不可用的（比如同一时刻对该余额做减少操作）。这样我们保证了用户余额减少–商家余额增加这一过程结果的可控性，在分布式这方面，memcache和Redis等都可实现分布式锁。
下面我们讨论当用户的支付过程完成之后的事情，顺利的情况下订单系统拿到支付成功的结果后将订单状态更新为支付成功。可是假如在这个过程，因为超时抑或其他原因，导致用户支付成功，而订单状态已然是未支付该怎么办？这时候我们有两种选择：轮训查询几次支付结果而后更新订单状态，此为同步过程。引入消息中间件，将此过程解耦成异步过程。显然我们应该使用异步方式更优雅，并且解耦之后的扩展性更强。那么如何实现呢，我简单说下：支付成功之后账户系统发送消息到MQ，订单系统轮询MQ获取最新消息，根据消息更新订单状态。这样的结果就是用户系统首先依然认为订单未支付并展示给用户，而后台处理完后可以等待用户主动获取订单状态（刷新页面，京东上就是如此），也可以更高端的主动推送信息给用户。那么物流状态依然引入MQ来完成异步化的操作。
看似我们的这个过程已经“优雅”的完成了，用户看到了支付状态又看到了发货提醒，安心的等待中。
后记：还需继续思考的点
- 分布式锁的竞态处理；
- 消息发送的一致性（100%保证消息送达）
