IcyFenix

me too

> @O-ll-O > 想要亲笔签名版，咋搞啊，周老师 先感谢支持。 等6月底出版了，大概我会做个转发微博/朋友圈送签名书的活动配合出版社宣传一下吧。会自费送10本签名版的。

> 纸质书和本网站的内容有什么区别吗 99%的内容是一样的，书籍毕竟是正规出版物，稍微删减/调整了一些在网上可以写，但是不方便写到书上的语句

> 纸质版的书和这里的内容有什么区别？ 99%的内容是一样的，书籍毕竟是正规出版物，稍微删减/调整了一些在网上可以写，但是不方便写到书上的语句

> @UUNNFLY > 周老师，假如现在有一个比较庞大的单体系统，现在我逐渐分离出多个微服务（提取一部分内聚的业务逻辑为一个新服务，并把之前代码里相关逻辑改为调用该服务），这种算是换房子吗？还是说必须把原来的单体系统彻底抛弃才算换房子？ 这相当于把房子拆了，从里面拿出还有用的钢筋水泥和家具家电，重新造另一套新房子，我认为当然算换房子。 但有另一种情况，而且还挺普遍的是：单体系统向微服务改造时，经常遇到某些部分“舍不得拆”，或者牵绊过多，或者不肯付出足够的工作量去进行分离。最典型的数据库，尤其是多个模块中都要共用到的主数据部分，这导致微服务改造后，既没有得到微服务的好处，又平白付出微服务的代价。 如果将这种情况继续用前面“房子”的比喻来描述，就是将一所三室两厅的房子，强行加上围栏，当作是五个单间，这样每个房间既没有独立，本质上还是原来的房子，也丧失了原本独立的功能区域。

> "这听起来无论如何不算上什么"是否应该是“算不上” > “见族群运作的复杂度就越高”感觉删掉“就”读起来更通顺一些 > “这是一种随着规模增长呈平方级增长复杂度”加个“的”变成“增长的复杂度”会好一些 十分感谢。均已修正。

> @yanyuyouyou > 内容非常精彩，受益颇多~ > > 有个小小的问题： > 反向恢复（Backward Recovery）：如果Ti事务提交失败，则一直执行Ci对Ti进行补偿，直至成功为止（最大努力交付）。这里要求Ci必须（持续重试后）执行成功。反向回复的执行模式为：T1，T2，…，Ti（失败），Ci（补偿），…，T2，T1。 > > 我的理解这里最后应该是Tn 吧？ 经提醒发现这段写错了，T1，T2，…，Ti（失败），Ci（补偿），…，C2，C1才对，就是此前提交的T1-i的事务都应该被反向顺序地补偿掉。

@lan-cyl > GTS就是SAGA的一种实现吧？ > 1.子事务Ti=每个数据源 > 2.补偿Ci=根据日志自动产生的逆向SQL > > > 另外GTS加上全局锁后，系统吞吐量跟2PC没差别了吧？资源的释放也只能等到全局事务结束吧？正常情况倒是能减少一次网络调用 GTS是阿里的事务框架，和SAGA完全不是可以比较的概念。 根据上下文，你是想说Seata的AT模式是SAGA的实现？文中说了，广义上，它们的思路是一致的。细节上，你可以参考一下Seata的[SAGA模式](http://seata.io/zh-cn/docs/user/saga.html)和[AT模式](http://seata.io/zh-cn/docs/dev/mode/at-mode.html)的区别。

> @lambert-shi > 周老师你好，结合本地事务篇我对以下这段话有一些疑问，希望能够指教。 > > 完全有可能两个客户在短时间内都成功购买了同一件商品，而且他们各自购买的数量都不超过目前的库存，但他们购买的数量之和却超过了库存。如果这件事情处于刚性事务，且隔离级别足够的情况下是可以完全避免的，譬如，以上场景就需要“可重复读”（Repeatable Read）的隔离剂别，以保证后面提交的事务会因为无法获得锁而导致失败。 > > 无法获得锁的话不是应该进行锁等待，获取到锁之后继续执行事务吗？为什么会导致后面提交的事务失败？而且只依赖“可重复读”隔离级别是否会出现丢失更新导致的超卖情况发生呢？ > 你好。 这里的“失败”不是指没有锁的事务直接被出错回滚，它当然是会被阻塞的，失败表达的就是“一直被阻塞，如果达到超时阈值之后，将会被回滚”的意思。

> @lambert-shi > > 感谢周老师解答，那么按照周老师的场景事例，如果数据库采用的是MVCC方案，是否有可能出现以下这种超售情况 > > 初始quantity值为10，事务： T1和事务： T2都想要将quantity减8 > ```sql > SELECT quantity FROM books WHERE id=1 /* 时间顺序：1，事务： T1 */ > SELECT quantity FROM books WHERE id=1...