• 事务

单一数据库的时候，我们比较容易使用程序控制数据库事务，那么当数据库逐渐增加、分库分表的需求越来越多，我们将会面对很多的数据库，这时候使用程序控制 事务就会遇到很多问题，甚至原来很容易的事现在变的有些复杂了（如，当下单后商品减少、订单增加的情况，商品与订单分属不同的服务与数据库）。当然可以采 用分布式事务，但是分布式事务实现复杂、性能损耗大同时分布式事务规范本身有些问题不可避免。

分布式事务经常会涉及到的概念有两阶段提交、一阶段提交、事务补偿等等，可参考相关文档说明了解详细内容。

这里我们要分析一下，使用事务的最终目的是什么？首先想到的是同时成功或失败，再深入分析一下，我们终于明白要的是什么了：数据的一致性，一致性又分为 最终一致、强一致和弱一致三种。那么是不是所有的场景都要求必须要达到数据的强一致呢？显然不是，这需要我们根据实际情况分析（鱼与熊掌不可兼得，这是一 个不使用任何程序控制事务的场景，一个操作先插入从属信息再插入主信息，即便主信息插入失败也不会给用户带来影响，类似这样以空间换时间的方式也未尝不 可）。

数据的最终一致性业界有了很多的解决方案（非事务方式）。
1）使用MQ、Redis进行协调控制从而达到数据最终一致；
2）通过分析MySQL的Binlog达到数据最终一致；
3）根据行业、业务特点自己实现的数据最终一致。

• 消息队列

在服务化架构中，消息队列的作用时不可替代的。服务化架构的异步通信、流量消峰、跨语言调用、通知协调等等很多功能都会用到消息队列。

在选用MQ时，要考虑一下我们的需求和MQ自身功能是否匹配，超前的使用有时候并不能给我们带来相应的好处，反而可能会成为使用的障碍。

通常使用消息对立，有以下问题需要注意：
是否保证消息顺序；
消息拉取／推送模式有哪些；
水平扩展能力；
实时能力；
消息堆积能力；
监控功能是否完整／是否提供了完善的监控接口；
是否有持久化能力；
down机重启后，是否可以继续消费；
社区活跃度、更新频率；
成功使用案例。

【推荐】
从All-In-One到SOA——技术及架构的演进过程（一）
从All-In-One到SOA——技术及架构的演进过程（二）
从All-In-One到SOA——技术及架构的演进过程（三）
从All-In-One到SOA——技术及架构的演进过程（四）
从All-In-One到SOA——技术及架构的演进过程（五）
从All-In-One到SOA——技术及架构的演进过程（六）