【Azure Redis 缓存 Azure Cache For Redis】Redis支持的版本及不同版本迁移风险

问题描述

1. Azure Redis缓存支持的版本包括4.0以及6.0(预览）

这种情形下，可以使用PaaS服务提供的 Azure Redis 缓存(4.0版本)。Azure Redis对6.0的支持目前仍处于预览阶段，并且其使用的RESP协议也发生了变化。详情请见：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-overview

Azure Cache for Redis 基于开源软件 Redis 提供内存中数据存储。 Redis 极大地提高了在后端数据存储上使用的应用程序的性能和可伸缩性。它将经常访问的数据保留在可快速读写的服务器内存中，从而能够处理大量应用程序请求。 Redis 为新式应用程序带来了关键的低延迟、高吞吐量数据存储解决方案。

Azure Cache for Redis 以托管服务的形式提供 Redis。它提供安全的专用 Redis 服务器实例，且完全兼容 Redis API。该服务由 Microsoft 管理并在 Azure 中托管，可供 Azure 内外的任何应用程序访问。

Azure Cache for Redis 可用作分布式数据或内容缓存、会话存储和消息中转站等。它可单独部署，也可与其他 Azure 数据库服务（如 Azure SQL 或 Cosmos DB）一起部署。

2. 关于不同Redis版本间的迁移风险，从低版本（3.2）向高版本（4.0）迁移基本上不存风险。

具体说来，迁移的风险通常存在以下两个环节：

1) 现存客户端是否可以成功连接高版本的Redis?

Redis 3.2以及4.0均使用的是相同的RESP协议。因此，不存在兼容性问题，理论上只需要更新连接字符串指向新创建的Azure Redis资源即可。https://redis.io/topics/protocol

2) 是否会发生数据格式兼容性导致的内存数据丢失?

文档提供了关于从本地环境迁移至Azure Redis的多种选项，无需担心数据丢失（例如所有缓存中的数据都从DB中读入），则可以选择创建新的Redis。

https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-migration-guide

创建新的 Azure Cache for Redis

从技术上讲，这种方法不是迁移。如果无需担心丢失数据，则迁移 Azure Cache for Redis 的最简单方法是创建缓存实例并将应用程序连接到该实例。例如，如果将 Redis 用作数据库记录的后备缓存，则可以轻松地从头开始重新生成缓存。

实现此选项的一般步骤如下：

创建新的 Azure Cache for Redis 实例。

更新应用程序以使用新实例。

删除旧的 Redis 实例。

如果需要确保内存数据不丢失，高版本Redis向下兼容低版本的RDB文件格式。所以可选择文档中提供的其他两种不依赖于RDB格式的方式进行迁移。

https://github.com/sripathikrishnan/redis-rdb-tools/blob/master/docs/RDB_Version_History.textile

将数据导出到 RDB 文件并将该文件导入 Azure Cache for Redis

开源 Redis 定义了一种标准机制，用于获取缓存的内存中数据集的快照并将其保存到文件中。此文件名为 RDB，可由另一个 Redis 缓存读取。 Azure Cache for Redis 高级层支持通过 RDB 文件将数据导入缓存实例。可以使用 RDB 文件将数据从现有缓存传输到 Azure Cache for Redis。

3. 关于不同Redis之间连接数和性能的介绍

maxclients 对于每个 Azure Redis 缓存定价层都是不同的

基本缓存和标准缓存
- C0 (250 MB) 缓存 - 最多支持 256 个连接
- C1 (1 GB) 缓存 - 最多支持 1,000 个连接
- C2 (2.5 GB) 缓存 - 最多支持 2,000 个连接
- C3 (6 GB) 缓存 - 最多支持 5,000 个连接
- C4 (13 GB) 缓存 - 最多支持 10,000 个连接
- C5 (26 GB) 缓存 - 最多支持 15,000 个连接
- C6 (53 GB) 缓存 - 最多支持 20,000 个连接
高级缓存
- P1 (6 GB - 60 GB) - 最多支持 7,500 个连接
- P2 (13 GB - 130 GB) - 最多支持 15,000 个连接
- P3 (26 GB - 260 GB) - 最多支持 30,000 个连接
- P4 (53 GB - 530 GB) - 最多支持 40,000 个连接

虽然每个缓存大小最多允许一定数量的连接，但与 Redis 的每个连接都具有其关联的开销。此类开销的一个示例是，由于 TLS/SSL 加密而导致的 CPU 和内存使用。给定缓存大小的最大连接限制假定轻负载缓存。如果连接开销的负载和客户端操作的负载超出了系统容量，那么即使未超出当前缓存大小的连接限制，缓存也可能会遇到容量问题。

Azure Redis 缓存性能（参考官方说明：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-planning-faq#azure-cache-for-redis-performance）

4. Redis 高可用性

Azure Redis针对标准版以上的redis 都是提供主从的功能，这是azure redis内置的功能：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-high-availability

Azure Cache for Redis 具有内置的高可用性。其高可用性体系结构的目标是确保托管的 Redis 实例正常运行，即使其基础虚拟机 (VM) 受计划内或计划外中断的影响。它提供的可用性百分比率要远高于将 Redis 承载在单个 VM 上的情况。

Azure Cache for Redis 使用多个称为“节点”的用于缓存的 VM 来实现高可用性。它将这些节点配置为以协调的方式进行数据复制和故障转移。它还会协调维护操作，例如 Redis 软件修补。 “标准”和“高级”层级中提供了各种高可用性选项

另外针对高级版Redis，也提供了持久化的功能，能够在出现异常状况（主从同时不工作）的情况下，保证数据不丢失，Azure Redis会在恢复时自动加载持久化数据。持久化参考文档： https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-premium-persistence

什么是数据暂留？

Redis 暂留可让你保留存储在 Redis 中的数据。还可以获取快照并备份数据，以便在出现硬件故障时进行加载。这相对于基本级别或标准级别是一项巨大优势，因为基本级别或标准级别将所有数据存储在内存中，在出现故障的情况下，如果缓存节点停机，则可能导致数据丢失。

Azure Redis 缓存使用以下模型提供 Redis 暂留：

RDB 暂留 - 配置 RDB（Redis 数据库）暂留以后，Azure Redis 缓存按照可配置的备份频率，将 Azure Redis 缓存的快照以 Redis 二进制格式暂留在磁盘上。如果发生了灾难性事件，导致主缓存和副缓存都无法使用，则会使用最新快照重新构造缓存。详细了解 RDB 暂留的优点和缺点。

AOF 暂留 - 配置 AOF（仅追加文件）暂留后，Azure Redis 缓存将每个写入操作保存到日志，此日志每秒至少保存到 Microsoft Azure 存储帐户一次。如果发生了灾难性事件，导致主缓存和副缓存都无法使用，则会使用存储的写入操作重新构造缓存。详细了解 AOF 暂留的优点和缺点。

暂留将 Redis 数据写入你拥有和管理的 Azure 存储帐户。可在缓存创建过程中通过“新建 Azure Redis 缓存”边栏选项卡进行配置，也可以在现有高级缓存的“资源”菜单上配置。

5. Azure Redis突然连不上了，恢复了之后，数据清空了

在无法连接Redis期间，如果Redis有版本更新和重启，则有可能发生数据丢失的情况，这个与在Azure中使用的Redis的版本非常相关。如基础版(Basic)，因为它是单个缓存节点，所以在重启后会出现数据清空的情况。因此建议基本版Redis一般是用在开发/测试环境中。而标准版及以上定价层的Redis底层是基于主/从复制的生产级别缓存服务，在出现版本更新或重启的时候不会出现主从节点同时发生。所以能尽可能避免数据丢失。

Redis 实例故障

Redis 是内存中数据存储。数据保存在托管 Redis 缓存的物理机或虚拟机上。 “基本”层中的 Azure Cache for Redis 实例只在单个虚拟机 (VM) 上运行。如果该 VM 关闭，则缓存中存储的所有数据都会丢失。

“标准”层和“高级”层中的缓存在复制的配置中使用两个 VM，能够以更高的复原能力防范数据丢失。当此类缓存中的主节点发生故障时，副本节点将会接管工作并自动提供数据。这些 VM 位于独立的容错域和更新域中，从而可以最大程度地减少主节点和副本同时发生故障的几率。但是，如果发生严重的数据中心故障，这些 VM 仍可能会一起关闭。此时，数据将会丢失，但这种情况非常罕见。

考虑使用 Redis 数据持久性和异地复制来改善数据保护，防范此类基础结构故障。

故障转移的说明

当某个副本节点将其自身提升为主节点，且旧主节点关闭现有连接时，将发生故障转移。主节点重新启动后，它会注意到角色的变化，从而将自身降级为副本节点。然后，它将连接到新的主节点并同步数据。故障转移可以是计划性的，也可以是非计划的。

计划性故障转移发生在系统更新（例如 Redis 修补或 OS 升级）和管理操作（例如缩放和重启）过程中。由于节点会提前收到更新通知，因此它们可以协作交换角色，并在更改后快速更新负载均衡器。计划性故障转移通常可在 1 秒内完成。

发生非计划性故障转移的可能原因是硬件故障、网络故障或主节点的其他意外中断。副本节点可将自身提升为主节点，但该过程需要更长时间。副本节点必须先检测到其主节点不可用，然后才能启动故障转移过程。副本节点还必须验证此非计划性故障不是暂时性的或局部性的，以避免不必要的故障转移。检测时出现的这种延迟意味着非计划性故障转移通常要在 10 到 15 秒内完成。