作者回复: 你好,很高兴再次收到你的留言,我理解你这是一个很好的方式,我查相关资料的时候,突然意识到,这个方式也是有瑕疵的,比如,串联同步,级联同步,这会被中转服务覆盖掉
作者回复: 你好,WGJ,这里确实我讲的快了一些。这里我按基础顺序理解挨个举个例子,做多机房核心在于解决单个机房损坏无法提供服务问题,一般会做做多机房,当有故障的时候会关闭故障机房让其他机房对外提供服务。但是实际制作的时候发现,大部分业务的数据更新是有一致性要求的。 比如用户账户有100元,如果两个机房同时执行扣款25元而不做互斥的话,会导致两个机房最终用户余额是75而不是50,也就是扣了两次只扣了25元,用户用25元买到两个25元商品。 为了避免这个问题,我给了一个建议就是把用户的这类请求短暂的都调度到一个机房进行处理,这样就不会出现多扣现象,因为同一个机房的很容易用锁去互斥。 这样虽然解决了问题,但是这也带来一个新问题,就是数据如果在一个机房做了修改,需要同步给其他机房,这个同步过程根据距离不同决定了这个同步会很慢,极端情况下用户在用的机房扣款后,其他机房2秒钟后才能同步过去。 而在我们的设计中备份机房只有从库,本地不会修改数据,那么用户扣款后两分钟后才看到主机房的同步后数据刷新是很差的体验,所以,备份机房的服务修改数据后会通知主机房进行更新,同时会刷新备份机房这个用户的账户缓存,用户的查询尽量优先从备份机房的缓存走,等主库更新后再同步过来备份机房的从库后,我们从备份机房的从库才能拿到最新的数据。
作者回复: 你好,答案后期会公布,前期多看大家留言讨论,多查,多独立思考,会有更好的帮助
作者回复: 某个角度来说是这样,读多写少多数属于一个功能中比较频繁访问的情况。独立看起来确实感觉简单,但并不是整个系统都是能满足这个场景,因为还有事务一致性要求,其他情况需要搭配各种业务运营思路技巧,很多情况是组合存在的,这里还少说一个很多情况需要搭配CQRS读写分开思路拆分才可能满足业务需要
作者回复: 你好,piboye,会有这个问题,这里需要注意,客户端在一段时间内只在一个机房活跃就可以避免修改冲突
作者回复: 那么再深入一点,那么如何保证这个标识是唯一的?
作者回复: :)
作者回复: 你好,确实这个机会不多,不过这个不是重点,我们先了解纠结点,这个不仅仅是为了一个知识点讲解,同时也是期望对数据同步一致性有更多的理解
作者回复: 你好,感谢支持!多多交流!
作者回复: 你好,这里有个细节,就是如果是环形并且都是订阅单个主库这里是没问题的,但是如果是多种组合结构,存在多个主库,那么这个方式会麻烦很多