目录
1.微服务架构下的事务问题
问题栗子：
解决问题的办法：
1.减少服务间的调用
2.消息驱动的方式把服务串起来
这种消息驱动的方式没有办法实现强一致性，比如说这个票转移还在处理的时候，用户发一个请求去查看他的余额，这个时候他看到扣款成功了。但是票还没出来。只能等他处理完了才能看到一致的状态。
考虑他的出错的情况，第一个出错的情况，创建订单的时候出错，那么这个事务就会回滚，监听读的消息也会被回滚。但是如果order服务使用的order数据库和消息队列的使用的MQ数据源，这两个不是在一个JTA的事务里面，就可能会出现order服务本地的数据库的写操作已经完成并且提交，但是写消息的这个事务没有提交，写消息失败了怎么办？如果这个消息被重新触发，那这个order的写操作已经完成了，这下重复处理订单的数据怎么办呢？这个时候就需要使用幂等性，全局性id的方式去避免重复处理数据。
如果在user服务出错，如果是在读消息出错，那没什么问题，他会回滚，然后重新处理，但是如果在写消息的时候出错，和上面的一样，user服务本地的数据已经完成提交，这个时候需要考虑数据重复处理的问题。另外一个错误就是在user服务里面如果出现了无法恢复的错误，但是上一步的order服务里面已经完成了订单的创建这个时候怎么办？那么这个创建的订单将永远会停留在未完成的状态。那么这个时候如何处理数据的回滚，处理这种情况的方法有两种，第一种就是将这个还未处理的消息写到一个特定的队列里面，专门用于处理失败消息的队列，通过读这些消息判断去回滚哪些操作，第二种解决的办法是通过一个定时的任务去扫描长时间处于未完成的订单，根据订单的状态处理。比如失败，回滚扣费操作等等。
异常流程：
docker 安装activeMQ: https://www.cnblogs.com/liyiran/p/11523319.html
通过消息驱动的方式，正常的购票流程已经完成了。
如果在锁票阶段出了问题，什么时候会出现锁票失败？当两个人几乎看到票有剩余，然后几乎同时买这个票，前一个人先进来把票锁住了，后面一个人就没办法进行正常的支付流程了对不对？所以后面一个人的订单应该去将他置为失败。
余额不够的失败处理，直接返回了，没法继续完成支付对不对？这个订单处于一个创建的状态，这个票也一直处于一个锁住的状态，用户当然可以重新支付，但是如果用户一直不重新去支付这个订单，那么这个订单岂不是要一直处于新建状态，永远得不到完成，这张票也将永远被锁住。这样肯定是不行的，所以这个时候需要用到第二种处理错误的方法，使用定时任务清理这个超时的订单，主要要做的就是先将这个被锁住的票解锁，然后将这个订单置为失败。 当然扣费失败也可以马上处理将票解锁订单置为失败。
如果票都交了，在订单完的时候出错，这个时候处理失败的时候还要考虑回滚这个交票的操作
user-service服务扣费失败后需要发送有个ticket_error到ticket-service去将锁住的票解锁，解锁票并且写上失败的原因，然后继续发送一个订单失败的消息到
2.并发测试
ab工具：
3.消息驱动模式的使用场景：
