本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

在预置 MSK 集群上进行修补

Amazon MSK 会定期更新集群中代理上的软件。维护包括计划内更新或计划外修复。计划内维护包括操作系统更新、安全更新以及维护集群运行状况、安全和性能所需的其他软件更新。进行计划外维护是为了解决基础设施性能突然退化的问题。我们对标准代理和快速代理进行维护，但体验有所不同。

标准代理修补

如果您遵循最佳实践，标准代理更新不会对您的应用程序的写入和读取产生影响。

Amazon MSK 使用软件的滚动更新来维持集群的高可用性。在此过程中，代理将逐个重启，并且 Kafka 会自动将领导权转移给另一个在线代理。Kafka 客户端具有内置机制，可自动检测分区领导权的变化，并继续将数据写入和读取到 MSK 集群中。在任何时候（包括在修补期间）都要遵照 Apache Kafka 客户端的最佳实践，以使集群平稳运行。

当代理离线后，客户端上出现暂时断开连接错误是正常的。您还会观察到在短暂时段内（最多 2 分钟，通常更少）p99 读写延迟出现一些峰值（通常为几毫秒，最多约 2 秒）。这些峰值是预料之中的，是由于客户端重新连接到新的领导代理引起的；它不会影响您的生产或消费，并且会在重新连接后解决。有关更多信息，请参阅代理离线和客户端失效转移。

您还将观察到指标 UnderReplicatedPartitions 增加，这是预期的，因为已关闭的代理上的分区不再复制数据。这对应用程序的写入和读取没有影响，因为托管在其他代理上的这些分区的副本现在正在处理请求。

软件更新后，当代理恢复在线时，它需要“赶上”离线期间生成的消息。在追赶过程中，您可能还会观察到卷吞吐量和 CPU 使用率增加。如果您的代理上有足够的 CPU、内存、网络和卷资源，这些应该不会对集群的写入和读取产生影响。

快速代理修补

快速代理没有维护窗口。Amazon MSK 会以分时的方式持续自动更新集群，这意味着在一个月内可能偶尔会有单个代理重启。这样可以确保无需针对一次性集群范围的维护窗口制定任何计划或做出任何调整。与往常一样，在代理重启期间流量仍将保持不中断，因为领导者将切换到继续处理请求的其他代理。

快速代理配置了最佳实践设置和安全护栏，这使集群能够灵活适应维护期间可能发生的负载变化。Amazon MSK 为快速代理设置了吞吐量配额，以减轻集群过载的影响，过载可能会导致在代理重启期间出现问题。借助这些改进，在使用快速代理时就无需提前通知、计划和维护窗口。

快速代理始终以三种方式复制数据，确保客户端在重启期间自动进行失效转移。您无需担心因为复制因子设置为 1 或 2 导致主题不可用的问题。此外，快速代理重启后的同步速度也比标准代理更快。快速代理的修补速度更快，这意味着您可能为集群安排的任何控制面板活动，其计划性中断会降至最短。

与所有 Apache Kafka 应用程序一样，连接到快速代理的客户端仍存在共用的客户端-服务器合约。配置客户端以处理代理之间的领导者失效转移仍然至关重要。在任何时候（包括在修补期间）都要遵照 Apache Kafka 客户端的最佳实践，以使集群平稳运行。当代理重新启动后，客户端上出现暂时断开连接错误是正常的。这不会影响生成和使用，因为跟随者代理将接管分区领导权。Apache Kafka 客户端将自动进行失效转移，并开始向新的领导者代理发送请求。