Trouble with Distributed Systems (4-1) - Truth and Lies

前几天讲了跟分散式系统有关的网路不可靠、时钟不可靠的鬼故事，不可靠的东西这麽多，我们要如何判断真与假呢？在分散式系统中，我们可以陈述我们对行为所做的假设（系统模型），然後设计符合这些假设的系统，只要演算法证明相关函数正确，意味者可靠的行为正在发生，尽管底层的其他系统模型提供的保证很少也是。

在 Day 12, 13 天，我们将会进一步了解分散式系统有关 真实 (truth) 的知识，这能帮助我们未来在设想假设时，我们的系统能提供保证到什麽程度。

多数决的真实 (The Truth Is Defined by the Majority)

只要多台节点认为你死亡，你就是死亡，尽管你是因为网路问题被丢弃你回覆的讯息，或者的 GC 跑的特别久都一样，在分散式系统中你无法依靠单台节点来当法官，我们会用 quorum (法定人数) (2020 Day 24) 来在各节点中投票，所以一般来说多数决的节点数量一定是比一半多一点，也就能容忍一些节点死亡（3 台节点能容忍 1 台死亡，5 台节点则是 2 台），我们差不多在 Day 14 谈 共识算法 (consensus algorithms) 看有关 quorum 的更多 细节。

领导者和锁 (The leader and the lock)

有些主题用英文写出来觉得正常，但也用中文翻译出来看起来就很奇怪- -

很多分散式系统是使用 single-leader，想像一下 leader 你吃着火锅唱着歌，忽然就被麻匪劫了（你被 quorum 节点们宣告死亡），而你又自认为你还是 leader 时，麻烦就出来了。

像下图 8-4 的例子，展示了不正确实现分散式 lock 机制而造成资料损坏 bug，该 storage 只有在你取得资源 lease (租约) 的时候才写入该资源，Client 1 取得 lease 後，不幸的被 GC 暂停所有行为了，当这个暂停久到 lease 到期了，此时 Client 2 就能针对该资源取得另一份 lease ，Client 1 GC 结束返回之後，误以为它的 lease 还是有效而继续进行写入，所以该资源就被污染了。

击剑令牌 (Fencing token)

除了使用锁和 lease 保护资源外，我们会需要 fencing 技术来保护资源被上述例子的角色所污染，如下图 8-5，现在 Lock service 除了回覆 lease 外，会多回覆 击剑令牌 (Fencing token)，它就是个数字在每次取得 lease 时会累加，现在只要 Storage 多检查後来写入资源的 token 是不是比较小就可以了。

如果使用 Zookeeper 作为锁服务，它的 zxid 或 node 版本 cversion 可以被当做 fencing token。

拜占庭错误 (Byzantine Faults)

真实的事谈完了，我们来看看什麽是假的，在分散式系统中，如果你的节点有对你说谎的风险，举例来说就是有节点宣称他接收到讯息了但其实没有，这种行为被称为 拜占庭错误 (Byzantine Faults) ，在这种不信任的环境中取得共识的问题也被称为 拜占庭将军问题 (Byzantine Generals Problem)。

想了解拜占庭将军问题，强烈建议看 李永乐老师的说明影片。

本系列文的分散式系统节点们虽然不可靠，但我们都是假设它们是诚实的，因为是你或你的组织架构起分散式系统，所以本质上它们是能被信任皫，倘若你的分散系统还要支援 拜占庭容错 (Byzantine fault-tolerant) 的话，只会徒增你系统的复杂度而已，除非你的分散式系统是跑在点对点网路上，你得面对许多不同不由你控制的节点，就像比特币那样。

明天就结束这一章啦啦啦啦！