2019-09-18目前主流的做法不是通过异步消息来实现的吗。下单同步调用扣减库存接口。然后业务线监听订单状态接口实现业务。对于扣减库存如果发生超时，下单失败。商品中心监听费单消息，加回库存。来实现最终一致性。其他业务类同作者回复: MQ实现的分布式事务也是TCC的一种实现方式，也是主流的一种分布式解决方案
3
2019-08-28不太理解seata默认隔离级别为啥是未提交读，不怕脏读？还是为了保证性能才做的妥协？作者回复: 默认情况下，seata认为大多数分布式业务涉及到脏读的可能性比较小，所以保证了大多数场景下的高效性。
如果需要达到全局的 读已提交，seata也提供了相应的机制来达到目的。 2
2019-09-03老师有个问题阿里的开源分布式方案是事务管理器是单点的，如果挂掉了会不会引起事务不一致？作者回复: 会的，我在文中已经提到了
1
2019-08-27分页式事务中常用的方法：
1.二阶段提交
2.三阶段提交
3.TCC事务
4.Seata（有待验证） 1
2019-08-27老师好!
Seata 设计通过事务协调器维护的全局写排它锁，来保证事务间的写隔离，而读写隔离级别则默认为未提交读的隔离级别。
这个全局写排他锁支持那几种锁啊?
行锁，表锁，间隙锁，元数据锁别的记不起来了
如果支持的锁粒度不够吞吐量也会降低很多吧。作者回复: 赞，全局写排它锁是根据resourceId + table + pks实现。
1 1- 2019-08-27课后习题:全局写锁，第一阶段没有准确的提交或者回滚前，后续业务无法持有锁。我本来还想问下老师这个是怎么做到的，不过老师最后写了嘿嘿省的问了。默认读为提交，不怕脏读么?
TCC协议具体每一步怎么做讲一下么老师?
已订单支付为例，
try:尝试预扣处理,怎么预扣呢。用redis锁库存还是直接怎么锁。(抢购装备，游戏币和装备都在try阶段锁定。冲突大的后try，提交的时候冲突大的先commit?)。
try阶段，如果同时有多个事务进行try操作都能try成功么?如果支持try成功感觉有可能出现课后问题的情况。try这一步很重要啊，需要保证try以后，一定能提交成功，也一定能回滚。会不会有万一的?万一兜底解决是人工处理么?展开作者回复: 对的，我们首先要使用重试机制，其次保证记录日志。
1 
2020-02-08我司分布分布系统面临分布式事务的问题,也是打算使用TCC来解决，看了老师提到阿里开源的Seata，有必要试一下
2020-01-30老师好，分布事务在稳定性上还存有一些问题，可能导致数据不一致。从文章中来看老师是更推荐Seata吗？如果出现问题是要人工处理吗还是？我们在实际项目实战中采用 如:下单请求调用订单服务，同一个请求中还会调用:扣减库存（商品服务）、用券或者红包（促销服务）等其他服务。在整个方法体中做控制，如果调用的其他微服务接口返回失败就抛异常回滚整个请求来保证一致性，这种老师怎么看？- 2020-01-15我一直有个问题想请问一下，如果是基于MQ实现的最终一致性，如果需要回滚，要怎么操作？
作者回复: 常规做法是，主业务事务完成之后，其他业务通过mq通知，我们不做回滚操作，通过重试机制或者mq的内部ack机制要保证mq的消息能成功被消费掉。
2019-11-26老师您好，是不是可以这样理解，Seata是通过TM管理全局事务，所有用Seata的AP都可以实现写的隔离，也就是对同一行数据有影响的时候，并不存在分布的A事务没有操作完毕，B事务就开始操作的情况。
Seata默认采用了很乐观的分布式策略，CAP里面优先保证了A，并没有彻底解决脏读的问题。
而如果设置为读“已提交”，那就要Seata在内存记录额外的数据，用于返回已提交的"正确数据"？而这个就又扯出内存管理或崩溃时这些"正确数据"持久化的问题，导致系统复杂度上升？这样理解对吗？展开作者回复: 是的
2019-10-30为什么JTA不能适合单一数据源的分布式事务？作者回复: 适用，不同的分布式事务各有自己的优缺点，可以根据自己的需求来选择最适合自己的分布式事务的实现方式。
2019-09-22TCC 也是基于二阶事务提交原理实现的，但 TCC 的二阶事务提交是提到了服务层实现。
Seata将RM也提升到了服务层实现。
--------老师，这两种服务层实现，应该不是一回事吧作者回复: 是的，seata的RM提升到了服务层
2019-09-18思考题：为什么SeaTac不会产生脏数据，第一点因为全局排它锁，全局排它锁的结构是【resourceId + table + pks】，精确到某个资源某张表的某个条数据。第二点，如果A事务对于【Select * from table where id = pks for update】数据执行失败，且未回滚【resourceId+table+pk】，这时全局锁尚未释放。B事务申请相同资源的全局锁会失败。该条数据只能看不能处理，也说不上产生脏数据了。
2019-09-04文中“如果 RM 决议要全局回滚，会通知 RM 进行回滚操作”，按照学习后的理解，应该是TC决定是否要进行全局回滚，不知道我理解的是否有偏差，忘老师指正作者回复: 对的，已修正
2019-09-041.第一次听到TCC,感觉也是两阶段提交的思想，只是把询问变成try操作。
2.至于补偿，感觉mq的方式更像是在补偿。（在这里，因为mq是最终一致所以个人觉得更像补偿）
3.分布式事务框架还有个lcn，事务的搬运工。
2019-09-01老师您好，微服务间在事务中通过dubbo调用的方式是不是也可以实现分布式事务？作者回复: 可以的，Seata中有个基于dubbo实现的分布式事务的例子，有兴趣可以自己参考手动实践一下
2019-08-28老师好，我看网上有些是用mq消息中间件来解决分布式事务的，其实这个方案能不能解决分布式事务问题的？他的思想是基于tcc的吗？作者回复: 可以的，目前很多团队用过MQ实现分布式事务，也是基于TCC的思想实现。
2019-08-27全局写锁，如果线程还没有提交或者回滚事务，其他线程无法获得锁
老师，默认的隔离级别是读未提交，不是会发生脏读吗，这里是不是有问题作者回复: 默认情况下，seata认为大多数分布式业务涉及到脏读的可能性比较小，所以保证了大多数场景下的高效性。
- 2019-08-27老师，会讲Paxos算法么，面试经常会问道
作者回复: 可以考虑加餐
- 2019-08-27老师是全能！