开发者如何看待分布式系统中的不确定性 | InfoQ 访谈

分布式系统中有故障是很正常的，分布式系统只能确保一致性、可用性和分区容忍性三项中的两项。但 Kevlin Henney 认为，这种印象将限制了开发者对分布式系统行为方式的了解。Henney 曾于2022年伦敦QCon及2022年五月10-20日QCon Plus中发布了关于“6 个不能”的主题演讲。

Henney 认为，在一段代码中，我们可以透过结构和源代码缩进看到简单的控制流，如序列和分支。但我们看不见的则是网络或后端中损失的时间或序列重排。路由、电缆、主机或者是中间件发生故障并不稀奇，我们不能指望所有东西都能随时保持可用性。Henney 列出了一个可能发生的场景：

如果用于响应用户信息的节点彻底崩溃下线，那么用户将永远无法收到回应。架构师也无法保证节点是否能够恢复使用。当然，我们也可以将缓存中的答案返回给用户，但这个回复可能已经过时了。无论怎么说，用户都不会收到真正的答复。

CAP 定理是分布式系统的“海森堡不确定性原理"：一致性（Consistency）、可用性（Availability）以及分区容忍性（Partition Tolerance）。我们无法同时拥有全部三种属性，正如 Henney 所解释的：

一致性意味着，返回结果只能是最新的、一致的或者错误的三者之一；对可用性来说，错误响应不存在，但却不能保证结果是最新或一致的；分区容忍度是指分布式系统在部分分区网络不可用的情况下仍保持运作的能力。我们只能拥有其中两项，或者说，我们做不到全知全能。

 

Henney 总结说，超时和缓存在分布式系统作用显著的原因不在于它们的变通性或者优化的能力，而是因为从根本上讲，它们是必需的。

InfoQ 就分布式系统采访了Kevlin Henney。

InfoQ：为什么人们会默认分布式系统是可知的？

Kevlin Henney：开发者通常是从 IDE 中看世界的，也就是单一的机器。他们会默认以面前的代码来推理系统的运作。虽然他们能意识到网络是故障、并发、异步以及延迟的来源所在，但受视角所限他们往往不能认清现状：当前的问题实际上是更基础的、系统本质上的。

 

尽管异常处理程序可能会意识到故障的存在，但它们无法反映出故障的异常性。我见过不止一个编码指南如此写道：“异常应该是例外的”。这条建议也不过是文字游戏而已，它既没帮助也不现实。在网络环境中，连接超时、中断以及其他异常情况都一样，都是“正常现象”。

并且，这些“小问题”也不算很小，或者说它们就是分布式系统的组成部分。

InfoQ：我们要如何处理分布式系统的不确定性呢？

Henney：首先，承认不确定性的存在。其次，承认失败或不完整信息是正常情况而非是例外。第三，决定什么样的数据质量是适合应用的。

 

对确定性和可知性的限制意味着架构师必须意识到，状态的一致性是基本决策而非实现细节。数据最终是一致的还是同步交易的，决定了代码、用户体验以及其他系统品质。如果用户做出变更，那么该变更是否需要对其他用户立即且必须可见？这个问题的答案对架构起决定性作用。对数据质量过于严格违背 CAP 原则，或者会严重影响性能，如分布式锁定。

 

这些对分布式的限制影响有很多，比如 Java 的 RMI 之类的分布式垃圾回收机制，在确定一个对象是否不再需要，也就是需要回收的时候，答案并不是唯一的。在托管语言的单个进程中，对象是否可以作为事实声明引用是可以被确定的，但在分布式系统中却不一定。基于超时的租凭机制可以用于确定远程进程是否可以引用某个对象， 但它并不能保证该判断是否绝对正确，只是可能正确而已。

原文链接：

A Distributed System is Knowable: an Impossible Thing for Developers