最近一直再做一些系统上的压测，并对一些问题做了优化，从这些里面收获了一些很多好的优化经验，后续的文章都会以这方面为主。

在本篇文章中我们在SpringCloud环境下通过使用Seata来模拟用户购买商品时由于用户余额不足导致本次订单提交失败，来验证下在MySQL数据库内事务是否会回滚。

阿里巴巴自从跟SpringCloud共同发起创建微服务开源社区时，开启了SpringCloud Alibaba分支，而且在生态内提供了一款适用于分布式应用程序（Dubbo、SpringCloud等）的事务框架Seata，该框架经过多个大版本的发布，已经支持MySQL、Oracle这两种数据库事务回滚（Rollback）以及提交（Commit）控制，每次发版都会修复一些用户反馈的Issue以及添加一些新特性。

在这次SpringBoot升级后，之前的系统内使用实体传输受到了限制，如果使用SpringBoot默认的序列化方式不会出现信任package的问题，之所以出现这个问题是因为项目使用fastjson方式进行类的序列化已经反序列化，在之前SpringBoot 1.5.10版本的时候 RabbitMQ依赖内的DefaultClassMapper类在构造函数内配置*，表示信任项目内的所有package，在SpringBoot 2.0.0版本时，DefaultClassMapper类源码构造函数进行了修改，不再信任全部package而是仅仅信任java.util、java.lang。

在2018-3-1日SpringBoot官方发版了2.0.0.RELEASE最新版本，新版本完全基于Spring5.0来构建，JDK最低支持也从原来的1.6也改成了1.8，不再兼容1.8以下的版本，更多新特性请查看官方文档。

我们在之前的两个章节第四十一章： 基于SpringBoot & RabbitMQ完成DirectExchange分布式消息消费、第四十二章： 基于SpringBoot & RabbitMQ完成DirectExchange分布式消息多消费者消费提高了RabbitMQ消息队列的DirectExchange交换类型的消息消费，我们之前的章节提到了RabbitMQ比较常用的交换类型有三种，我们今天来看看TopicExchange主题交换类型。

在上一章/rabbitmq-direct-exchange.html我们讲解到了RabbitMQ消息队列的DirectExchange路由键消息单个消费者消费，源码请访问SpringBoot对应章节源码下载查看，消息队列目的是完成消息的分布式消费，那么我们是否可以为一个Provider创建并绑定多个Consumer呢？

消息队列目前流行的有KafKa、RabbitMQ、ActiveMQ等，它们的诞生无非不是为了解决消息的分布式消费，完成项目、服务之间的解耦动作。消息队列提供者与消费者之间完全采用异步通信方式，极力的提高了系统的响应能力，从而提高系统的网络请求吞吐量。
每一种的消息队列都有它在设计上的独一无二的优势，在实际的项目技术选型时根据项目的需求来确定。