本页介绍了 Memorystore for Redis 集群如何对实例执行维护。此外，它还提供了一些信息和配置建议，您的客户端应用应了解这些信息和建议，以便利用 Memorystore for Redis 集群的零停机维护设计。这些建议既适用于高可用性集群，也适用于没有副本的集群。不过，我们强烈建议您为所有生产使用情形配置高可用性。
Memorystore for Redis Cluster 会定期更新实例，以确保服务可靠、高效、安全且最新。这些更新称为维护。维护完全由服务管理，旨在实现零停机时间影响。
维护通常分为以下几类：
- Memorystore 功能。如需启动某些功能，Memorystore 需要进行维护更新。
- 操作系统补丁。我们会持续监控操作系统中新发现的安全漏洞。发现漏洞后，我们会修补操作系统，以防范新风险。
- 数据库补丁。维护可能包括 Redis 更新，以提升实例安全性、性能和可靠性特征，使其超出 OSS Redis 所能提供的水平。
配置客户端应用
如需在维护期间尽可能提升客户端应用的性能和可用性，请按以下步骤操作：
- 根据 Redis 客户端最佳实践中的指导使用和配置 OSS Redis 集群客户端，确保任何预定维护都不会影响您的客户端应用。我们建议的客户端配置可以通过定期内联拓扑刷新和后台连接轮换来避免连接重置。
- 在主节点和副本节点上运行代表性工作负载时，通过一系列更新操作（例如缩减或扩缩、副本数更改）测试客户端应用，并监控对客户端的影响。这些更新测试了客户端上的内嵌拓扑刷新逻辑、完整同步影响、新节点发现和现有节点移除功能。测试有助于确保 OSS Redis 集群客户端配置正确，以免对应用产生任何负面影响。
计划性维护
Memorystore for Redis Cluster 采用逐步部署和先创建后销毁的生命周期策略，以避免维护造成的任何停机影响。通过将 OSS Redis 集群协议的请求重定向功能与以下 Memorystore 机制结合使用，可实现零停机维护：
- 协调的故障切换，不会丢失任何数据。
- 平稳移除节点，使客户端能够及时了解集群拓扑更新，而不会影响可用性。
- 集群的 Private Service Connect 端点不受维护影响。如需详细了解这些端点，请参阅集群端点。
以下各部分中描述的服务行为仅适用于计划的维护。如需了解硬件故障等意外事件的影响，请参阅意外故障切换期间的客户端行为。
逐步部署策略
Memorystore for Redis 集群维护部署的范围会逐步扩大，并且以足够快的速度进行，以便尽早检测到故障，从而减轻影响并建立稳定性信心。在服务规模上，将烘烤时间（应用更新并监控的时间，之后才会认为更新成功并继续进行）集成到整个 Memorystore 集群中。此外，烘烤时间已集成到区域内各可用区（多个故障网域）的集群中，以尽可能减少影响范围。
对于配置为高可用性的集群，在任何给定时间最多更新一个容错网域/可用区，以确保集群分片（包括主分片和副本）在整个更新过程中都具有高可用性。此外，在任何给定时间，只有少数 Redis 节点会更新。更新使用“先创建后销毁”的生命周期机制，以最大限度地提高集群稳定性。在更新包含许多分片的集群时，此策略可带来最大好处。仅在任意给定时间将更新应用于整个用户密钥空间的一小部分，可最大限度地提高数据可用性。
创建前销毁生命周期策略
Redis 集群有多个分片。每个分片都有一个主节点和零个或多个副本节点。Memorystore 使用以下流程来更新分片中的任何现有主 Redis 节点或副本 Redis 节点：
- Memorystore for Redis Cluster 首先会向分片添加一个具有最新软件更新的全新副本。Memorystore 会创建一个全新的节点，而不是更新现有节点，以确保在发生意外的启动失败时保留您配置的容量。
- 如果待更新分片中的某个节点是主节点，则在移除之前，系统会先使用协同故障切换将其转换为副本。
- 接下来，Memorystore 会移除使用旧版软件的副本。
- 系统会针对集群中的每个节点重复执行此流程。
与就地更新的典型滚动部署相比，先创建后销毁策略有助于保留集群的预配容量，但会导致客户端应用出现可用性中断（有时还会丢失数据）。对于没有副本的分片，Memorystore for Redis Cluster 仍会先预配新副本，协调故障切换，最后替换分片的现有主节点。
第 1 步：添加 Redis 副本
创建前销毁机制的第一步是添加一个具有最新软件的副本节点，并使用完全同步 OSS Redis 机制将数据从主节点复制到副本节点。为此，系统会派生一个子进程，并利用无磁盘复制来引导副本。
您可以预配更多分片，以减小节点内的键空间大小，从而充分利用集群的横向扩缩架构。每个节点的数据集越小，完整同步操作的分叉延迟影响就越小。它还可以加快跨节点复制数据的速度。
第 2 步：协调主故障切换
如果需要更新的 Redis 节点是主节点，Memorystore 会先对新添加的副本节点执行协调的故障切换，然后再继续执行节点移除。在协调的故障切换期间，客户端和 Redis 节点会协同工作，并使用以下策略来避免应用停机：
- 在主节点上临时屏蔽传入的客户端请求，以便提供一个时间窗口来确保现有副本与主节点完全同步。
- 副本完成选举过程，接管主角色。
- 之前的主节点（现在是副本）会解除对现有请求的阻塞，并使用 OSS Redis 集群协议将这些请求重定向到新选出的主节点。发送到之前副本节点的所有新请求都会继续重定向到新的主节点。
- 支持 Redis 集群的客户端会刷新其内存中的拓扑。它会学习新主端点的地址，不再需要重定向。
协调的故障切换通常需要数十毫秒。不过，集群总大小可能会增加故障切换延迟时间。同样，待刷新到副本的正在传输的数据也会丢失。集群大小可能会影响主节点之间的收敛，进而影响有关选择新主节点的决策。
第 3 步：移除 Redis 副本
先创建后销毁机制的最后一步是移除旧版软件上的副本节点。突然移除节点会对客户端应用产生影响，因为客户端会缓存端点信息和集群拓扑。Memorystore for Redis Cluster 在设计时考虑到了 Redis 副本的正常移除，以便客户端应用在遇到节点硬关机之前刷新其拓扑。拓扑经过自定义，以便客户端了解新的副本。拓扑还会忘记在移除之前要移除的副本。
运行旧版软件的副本节点会在一段耗尽期（通常为几分钟）内保留，在此期间，它会开始将传入的读取请求重定向到相应分片的主节点。它允许 OSS Redis 集群客户端刷新集群拓扑并了解新的副本端点。如果客户端在排空期结束后尝试访问已移除的节点，则尝试会失败，这会触发集群客户端上的集群拓扑刷新，以便客户端了解副本更改。集群拓扑的新刷新不会看到要移除的副本节点。
维护设置
借助 Memorystore，您可以自定义维护时间表，以满足应用的需求并最大限度地减少中断。 您可以通过为集群配置维护窗口来达到这个目的。
维护窗口是针对每个 Memorystore 集群设置的，并允许以下配置选项：
- 星期几。指定进行维护的日期。
- 开始小时。开始维护的小时。
维护窗口的时长为 1 小时。请注意，在某些情况下，维护可能会超出您选择的维护窗口期。
为集群实例配置维护窗口后，系统会根据为维护窗口设置的偏好设置来安排未来的自动维护。
默认维护窗口
如果您未设置维护窗口，Memorystore 会根据集群的时区在以下某个时间窗口中更新集群：
工作日时段（星期一至星期五）。晚上 10 点至早上 6 点
周末窗口。周五晚上 10 点至周一早上 6 点
维护示例
作为管理零售商购物车服务的开发者，您有责任监督包含 Memorystore for Redis Cluster 实例的生产环境。为确保维护期间的性能达到最佳状态，您应尽量在集群流量最少时（通常在周日午夜前后）安排维护。
在这种情况下，您可以将生产集群的维护窗口设置为：
- 星期几。周日。
- 开始小时。凌晨 1 点。
即将进行的维护通知
为确保您及时了解集群的维护事件，您可以设置电子邮件通知，以便在安排维护前至少一周收到有关即将进行的维护的通知。这些通知的主题行为 "Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]"。
当集群开始维护时，系统也会发送通知。电子邮件的主题行将为 "Maintenance
is undergoing for your Cloud Memorystore instance [your-cluster-name]"。
维护完成后，系统会发送完成通知。电子邮件标题为 "Completed Maintenance
for your Cloud Memorystore instance [your-cluster-name]"。
如果 Memorystore 重新安排维护，您会收到一封电子邮件，其中会通知您维护已被取消。此电子邮件的主题行将为 "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]"。
您必须选择接收这些维护通知。如需订阅维护通知，请按以下步骤操作：
如需接收来自 Memorystore 的维护通知，请确保您已在实例的计划性维护更新前至少一周完成上述步骤。如果您未及时执行此操作，系统将没有足够的时间来通知您即将进行的维护。
通知会发送到与您的 Google 账号关联的电子邮件地址。您不能配置自定义电子邮件别名（例如团队电子邮件别名）。目前，我们不支持将通知发送到其他电子邮件地址。
订阅维护通知后，您将收到指定项目内所有计划进行维护的 Memorystore 集群的提醒。如果您已订阅，则会针对每个集群收到单独的通知。
如需了解如何查找计划维护，请参阅查找计划维护。
重新安排维护
如果您的集群配置了维护窗口，本部分将提供有关如何重新安排维护的指南。例如，如果计划在当前维护窗口期间启动新服务，您可能需要将维护窗口推迟到启动后几天内。
您可以在原定安排的时间后两周内随意重新安排维护。在重新安排会议时，您可以选择以下任一选项：
- 立即更新。您可以立即将更新应用到集群，而不是等待安排的维护窗口。
- 自定义日期和时间。这样，您可以选择在原定安排的维护时间后的 2 周内的任意特定时间。
重新安排维护时，需要遵循以下限制：
- 如果距离当前安排的维护时间不到一小时，您将无法重新安排维护。
- 成功重新安排后，系统会发送一封电子邮件，确认取消之前的维护，并发送一封新的即将进行的维护通知，其中包含更新后的安排。
如需了解如何重新安排维护，请参阅重新安排维护。
常见问题解答
以下是关于 Memorystore for Redis 集群维护政策的一些常见问题：
如何知道集群的计划维护时间？
我们建议您订阅通知并配置维护窗口，以便了解何时为您的实例安排维护。您还可以使用查找预定的维护手动检查，看看响应中是否设置了 maintenance_schedule 字段。
我何时会收到即将进行的维护的通知？
如果您订阅了维护通知并设置了维护窗口，则至少会在维护事件发生前 1 周收到电子邮件提醒。
我可以将维护推迟多长时间？
为集群安排维护之后，您可以立即开始更新实例，也可以将更新从最初安排的维护时间开始推迟最多 2 周。例如，如果将维护安排在 10 月 11 日晚上 11 点 15 分，则可以推迟到 10 月 25 日晚上 11 点 15 分。如果您不执行任何操作，维护将在所安排的时间进行。
如需了解详情，请参阅重新安排维护。
我应该遵循哪些最佳做法来获得流畅的维护更新体验？
我们建议您采取以下操作，以确保获得流畅的维护更新体验：
- 按照说明配置客户端应用
- 您应该设置维护期的时间，确保不会在 Redis 使用高峰时段进行维护。
- 您应该选择接收维护通知，以便在为实例安排维护更新前至少七天收到电子邮件提醒。
- 如果您的应用使用情况没有低影响或无影响时段，我们建议您使用服务默认的逐步推出，其中包含最佳实践。 如需了解详情，请参阅计划性维护。
我何时应该立即进行维护？
您可以立即在测试集群上应用维护更新，以了解其对应用的影响。这样，您就可以观察维护所产生的影响，并根据需要/在条件允许时推迟生产集群上的维护操作。
如果当前时间适合您的集群，并且您预计集群未来会承受高负载，也可以立即安排维护。
维护更新是否始终在维护期内完成？
更新会在您指定的维护窗口内开始。更新通常在维护期内完成，但不能保证。
我可以先停止对某些集群进行维护或安排维护吗？
不可以，您无法选择停用维护，也无法控制集群的维护顺序。不过，在收到初始维护通知后，您可以重新安排维护，使其最多推迟 2 周。
后续步骤
- 查看管理 Redis 集群维护窗口所需的权限。