没有理由在分布式系统中反对冗余 (马克)


从根本上说,分布式系统比单机系统具有更高的可用性是一个根本原因:冗余。运行系统所需的软件,状态和其他内容在多个地方存在。当其中一个地方发生故障时,其他地方可以接管。这适用于复制的数据库,负载平衡的无状态系统,无服务器系统以及几乎所有其他常见的分布式模式。
冗余的一个问题是它增加了复杂性,这可能会降低可用性。冗余可能意味着多台计算机,多个机架,多个数据中心甚至多个洲。这可能意味着软件故障,其中诸如金丝雀部署之类的通用技术可以在一个软件版本出现故障时帮助系统实现冗余。
当我们谈论系统设计时,我们往往会忘记冗余的这些多重定义,而只关注基础架构。为了说明冗余为什么如此重要,让我们研究一个例子。
事件日志理应是构建大型系统的一种流行方法。在这类系统中,有一个有序日志,所有更改(写操作)都会流经该日志,然后将更改应用于挂起该日志的某些系统。可以是读取的数据副本,工作流系统可以对更改执行操作,等等。在此模式的简单版本中,一件事是正确的:日志中的每个主机和每个使用者都以相同的顺序看到相同的更改。
该体系结构的一个优势是,它可以为基础结构故障提供大量冗余。通用事件日志系统(例如Kafka)可以轻松处理单个主机的故障。克服单个副本的故障也很容易,因为该体系结构使保持多个副本同步非常容易。
现在,考虑一下日志中发生的事件之一是毒丸的情况。这只是意味着消费者不知道如何处理它。也许它说是非法的(“我不能减少这个无符号0!”),或者是没有道理的(“ X列中的数据是什么?我从未听说过X列!”)。也许它说的只有在软件的未来版本或过去的版本中才有意义。当面对毒药时,复制基本上有两种选择:忽略它或停止。
忽略它可能导致数据丢失,而停止复制则会导致写操作不可用。没有人赢。这里的问题是缺乏冗余:在相同的状态下运行相同的(确定性)软件每次都将具有相同的不良结果。
此问题不仅适用于事件日志体系结构。众所周知,复制的状态机也遇到相同的问题。主/备份复制也是如此。这不是一个体系结构的问题,而是总体上分布式系统设计的问题。
在设计系统时,值得提出以下问题:您从冗余中得到了什么,以及哪些故障可以保护您免受损害。