
190
|
第
11
章
CAP 中的可用性也不同于前面提到的
高可用性
[KLEPPMANN15]。CAP 的定义对执行
延迟没有限制。另外,与 CAP 相反,数据库中的可用性并不要求每个非故障节点响应
每个请求。
CAP 猜想用于解释分布式系统、推理故障场景和评估可能的情况,放弃一致性并不意味
着系统可以提供不可预测的结果,它们之间有所区别。
如果使用正确,声称具备可用性的数据库仍然能够提供来自副本的一致结果,前提是要
存在足够多的活着的副本。当然,还有更复杂的故障场景,CAP 猜想只是一条经验法则,
并不一定能说明全部事实
注 1
。
11.2.2
收成与产量
CAP 猜想仅以它们最强的形式讨论一致性和可用性:
可线性化
和系统最终响应每一个请
求的能力。
这迫使我们在这两个属性之间做出艰难的权衡。然而,有些应用程序可以从稍微放松的
假设中获益,我们可以用它们较弱的形式来思考这些属性。
系统不一定非得在一致或可用中二选一,也可以提供更宽松的保证。我们可以定义两个
可调度量:
收成
(harvest)和
产量
(yield),在两者之间进行选择仍然可以形成正确的行
为 [FOX99]:
收成
收成定义查询的完成程度:如果查询必须返回 100 行,但由于某些节点不可用而只
能获取 99 行,这仍然比查询完全失败而不返回任何内容要好。
产量
产量指成功完成的请求数与尝试请求总数之比。产量与正常运行时间(uptime)不
同,例如一个繁忙的节点没有宕机,但仍然可能无法响应某些请求。
这就把权衡的重点从绝对条件变成了相对条件。我们可以用收成换取产量 ...