基本上，分布式系统可以实现比单箱系统更好的可用性：冗余。运行系统所需的软件，状态和其他事项存在于多个位置。当其中一个地方失败时，其他地方可能会接管。这适用于复制的数据库，负载平衡无状态系统，无服务器系统以及几乎所有其他常见的分布式模式。
冗余的一个问题是它增加了复杂性，这可能会降低可用性。另一个问题，以及人们倾向于错过的另一个问题，是冗余ISN＆＃39; t一件事。像安全性一样，冗余是一个单词，我们的意思是我们的架构和系统对不同类型的故障抵抗。这可能意味着基础设施故障，冗余可能意味着多台机器，多个机架，多个数据中心甚至多个大洲。它可以意味着软件故障，其中包括金丝雀部署等公共技术在一个软件版本故障时帮助系统冗余。我还可以指的是逻辑失败，在那里我们认识到该状态会影响我们系统的性能或可用性，我们尝试确保相同的国家不会进入每个主机。有时该状态是配置，有时它＆＃39; s存储的数据或请求和响应。
不幸的是，当我们谈论系统设计时，我们倾向于忘记这些冗余的多种定义，而是只关注基础架构。展示为什么这一事项，让＆＃39; s探索一个例子。
事件日志是合适的一种流行的方式来构建大规模系统。在这些类型的系统中，其中所有更改（写入）流过的有序日志，然后将更改应用于挂起日志的某些系统。这可以读取数据的副本，工作流系统对更改进行操作等。在此模式的简单版本中，有一件事是真的：日志中的每个主机和每个消费者，都以相同的顺序看到相同的更改。
这种架构的一个优点是它可以提供很多违反基础架构故障的冗余。常见事件日志系统（如Kafka）可以轻松处理单个主机的故障。幸存下单个副本的失败也很容易，因为架构使得在同步中保持多个副本非常容易。
现在，考虑到日志下降的事件之一是毒药的情况。这只是意味着消费者不知道如何处理它。也许它说了一些非法（＆＃34;我可以和＃39; t递减这个未签名的0！＆＃34;），或者没有意义（＆＃34;什么＆＃34;什么＆＃34;什么X列中的这个数据？i＆＃39;从未听说过列x！＆＃34;）。也许它说了一个只在未来或过去，软件版本中只有意义的东西。当面对毒药时，副本基本上有两种选择：忽略它或停止。
忽略它可能导致数据丢失，并且停止导致写入不可用。没有人赢。这里的问题是缺乏冗余：运行相同的（确定性）软件在同一状态下每次都会具有相同的坏结果。
此问题不会应用于事件日志体系结构。复制的国家机器，着名，遭受同样的问题。主/备份复制也是如此。它不是一个架构的问题，而是一般分布式系统设计的问题。当您设计系统时，它值得询问关于您的冗余＆＃39;从冗余中获取的问题，以及它保护您的失败。在某种意义上，这是同样的意思，即安全人员在威胁建模时使用：
威胁建模答案问题就像“我最容易受到攻击的地方？”，“最相关的威胁是什么？”，“我需要做些什么来保护这些威胁？”。
几年前，我尝试了为分布式系统设计构建威胁建模框架，称为Calisto，但我从未找到过我所爱的东西。但是，我做了思维方式。 ＆＃34;我很容易受到伤害的？ 34;
如果你的回答＆＃34;我易受伤害的失败？＆＃34;没有包括软件错误，你＆＃39;比我更乐观。