AI消除马赛克，上线三天收获近7000星

小结

通过上面的演示，我们知道了如何解决拜占庭将军问题。其实兰伯特在他的论文中也提到过如何解决。

如果叛将人数为 m，将军数 n >= 3m + 1，那么就可以解决拜占庭将军问题。

前提条件：叛将数 m 一致，需要进行 m + 1 轮的作战协商。

这个公式，大家只需要记住就可以了，推到过程可以参考论文。

比如上述的攻打董卓问题，曹操、刘备、孙坚三个人当中，孙坚是叛将，他可以使诈，使作战计划不统一。必须增加一位忠臣袁绍来协商共识，才能达成一致性作战计划。

拜占庭解法二-签名

那可以在不增加忠臣的情况下，解决拜占庭的二忠一判问题呢?

解法二就是通过签名消息。比如将军之间通过印章、虎符等信物进行通信。来保证这几个特征：
 

第二轮孙坚休息，其他副官按照孙坚发送的指令开始向另外的副官发送指令。

• 曹操向刘备和袁绍发送进攻指令。
• 刘备向曹操和袁绍发送进攻指令。
• 袁绍向曹操和刘备发送撤退指令。

如下图所示，最后曹操、刘备、袁绍收到的指令为进攻 2 票，撤退 1 票，按照少数服从多数原则，三个人都是发起进攻。执行了一致的作战计划，保证作战的胜利。
 

孙坚使诈 - 一进一退

假如孙坚使诈，给曹操发送撤退指令，给刘备发送进攻指令，那么刘备收到的作战信息是进攻 3票，肯定会发起进攻了，而曹操收到的作战信息是进攻 2 票，撤退 1 票，最后曹操还是会进攻，所以刘备和曹操还是联合作战击败了反贼董卓。

如此看来，引入了一位指挥官后，确实可以避免孙坚使诈，但如果是孙坚在第一轮作为指挥官，其他人作为副官呢?
 

这时流程如下：

1.  写请求，中间件将会发到主库，同时记录一下此时写请求的 key（操作表加主键等）
2.   读请求，如果此时 key 存在，将会路由到主库
3.  一定时间后（经验值），中间件认为主从同步完成，删除这个 key，后续读将会读从库

这种方案，可以保持数据读写的一致。

但是系统架构增加了一个中间件，整体复杂度变高，业务开发也变得复杂，学习成本也比较高。

缓存路由大法

这种方案与中间件的方案流程比较类似，不过改造成本相对较低，不需要增加任何中间件

（编辑：阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!