作者回复: 使用MQ的事务消息模式 + 事务日志表记录执行状态 + batch job扫表做反向补偿。最经济实惠的方法
作者回复: 传统的方式其实就是利用MQ的事务型消息,或者整一个事务表控制执行状态(有的干脆就直接在业务表上记状态也成),再加一个batch job定时跑批补偿。没啥高端的货
作者回复: 同学发现了一个小机关,没错,这个是在0.9版里的一个改进,不用再显示的声明,seata框架会在背后把datasource放到proxy里。我在课程里把这一步单独拿了出来手动操作,主要是想让大家对seata底层的工作原理,即数据源代理,有一个直观一些的认识
作者回复: 1. 数据库表,seata框架做CRUD 2. 通过GlobalTransactional注解和datasource拦截器 3. 不会,因为当前业务在二阶段了,一定已经持有了全局锁。另一个拿到本地锁的业务会因为无法获取全局锁而回滚,进而释放本地锁 4. 回滚是二阶段异步执行
作者回复: 没错,一阶段commit其实已经提交了happy flow里的业务数据,并记录rollback上下文。问题二,分布式方案要在可用性和一致性之间做取舍,如果一定要保证一致性那么就是类似重量级xa方案,那么seata相当于牺牲了一部分一致性换来了可用性的提升。 针对你说的这个问题,在写阶段由于全局锁本地锁的机制在,不会出现对同一条记录的并发修改。但读的业务里,你就要考虑这个业务对一致性的容忍程度是多少,如果要将读来的数据做任何写操作且不一致性低容忍,那么通常做法就是业务层做日志表,代替框架的lock机制,或者最终修改的时候sql update里做版本控制(version字段)
作者回复: 看上去可能是seata锁占用的问题,同学你打开seata的日志,如果是global/local锁竞争应该有相关error log打印出来,盯紧Rollback关键字,看一下报错的具体error是什么
作者回复: 本地锁可以理解为当前微服务对应的后台DB中,该次请求所操作的对象上的锁,生命周期绑定本地事务