阿里出的分布式事务组件seata初体验

分布式事务问题一直是业界的难点，目前的就我知道好一些的解决方案有mq方式，tcc,xa 等，都但另有缺点，
阿里出的seata (原名fescar)，给出一个不错的解决办法，对业务侵入少又同时保持了性能。
目前最新版本：0.6.1
简单跑了一下官方的例子，是可以实现分布式事务，也可以实现全部成功，或全部回滚，
但是看了官方文档如下的描述后，想试验一下事务隔离级别，做了如下试验

在数据库本地隔离级别 读已提交 或以上的前提下，Fescar 设计了由事务协调器维护的 全局写排他锁，
来保证事务间的 写隔离，将全局事务默认定义在 读未提交 的隔离级别上。

测试1

测试2个事务操作同一张表，事务1用seata ,事务2不用seata,

图1

用的官方的sample

image.png

步骤如下：
事务1: 按图1的顺序，先更新storage表，将库存从1000 变为999，然后程序打个断点，停止向下执行
事务2： 直接操作mysql storage表,发现表中库存已变为999，将库存改为199
事务1: 执行到更新account表 的时候手动报异常，全局事务回滚，执行undolog ，库存变为了1000，就是事务1更新前的状态。

结论： 多个微服务要用seata,就全用，否则像事务2没有用seata,不会被seata 的全局锁拦住，也会操作成功，但是如果事务1rollback ，之前的操作会全部丢失。

测试2

同测试1一样，只是事务1和事务2全引入seata,事务1跑1半时断点夯住，执行事务2，发现事务2还是可以执行，效果同测试1

测试3

事务1同上，事务2的代码如下：

image.png

事务2在service 中加入 @GlobalTransactional 注解
在事务1跑到一半时，启动事务2，
事务2报错了，如下
Unable to commit against JDBC Connection; nested exception is org.hibernate.TransactionException: Unable to commit against JDBC Connection
说明，如果需要保证对表进行全局锁，所有事务方法都要加上 @GlobalTransactional 注解，