了解 Azure Redis 缓存的常见问题、模式和最佳做法。
Redis 许可模式
Redis 许可已发生哪些更改？
Redis 开源项目已更改为支持 Redis 源可用许可证版本 2 (RSALv2) 或服务器端公共许可证版本 1 (SSPLv1) 的双许可证模型。 有关详细信息，请参阅 Redis 新闻发布。 另请参阅有关 Redis 许可更改的 Microsoft 博客文章。
RSALv2 和 SSPLv1 许可证现在是否还涵盖 Azure Cache for Redis？
不涵盖，向客户提供 Azure Cache for Redis 需依据 Microsoft 服务条款。 RSALv2 和 SSPLv1 许可证不适用于对 Azure Cache for Redis 的使用。
我的 Azure Cache for Redis 实例是否会继续接收补丁和 bug 修补程序？
是，即使在许可公告之后，Azure Cache for Redis、Azure Cache for Redis Enterprise 和 Enterprise Flash 也将继续接收补丁和 bug 修补程序。
作为 Azure Cache for Redis 客户，此许可公告需要我执行哪些操作？
我们的 Azure 客户无需就许可公告采取任何操作。
弃用的服务
哪些 Azure Cache for Redis 服务已弃用？
依赖于云服务（经典）的缓存
对于依赖于云服务（经典）的任何 Azure Cache for Redis 实例，我应该采取哪些措施？
应该迁移依赖于云服务（经典）的所有缓存。 在 2021 年 8 月，我们已宣布云服务（经典）将于 2024 年 8 月 31 日停用。 依赖于云服务（经典）的任何 Azure Cache for Redis 实例需要在该日期前停用。
应在 2024 年 8 月 31 日之前迁移依赖于云服务（经典）的缓存。
有多少缓存受到影响？
我们努力地以透明方式迁移了尽可能多的缓存。 因此，只有少量的缓存和客户会受到影响。
我如何知道缓存是否受影响？
检查 Azure 顾问建议。 如果缓存受到影响，则会在订阅中看到建议。
如何将云服务（经典）缓存迁移到 Azure 虚拟机规模集？
我们已迁移大多数缓存，使其构建在 Azure 虚拟机规模集上，而不是构建在云服务（经典）上。 迁移到 Azure 虚拟机规模集可以消除依赖关系。 可通过三种方法为虚拟网络中的缓存启动此过程：
使用专用链接迁移到新缓存。
创建一个使用专用链接进行网络隔离而不是使用虚拟网络注入的新缓存，然后将数据迁移到此缓存。 此选项提供最佳且最安全的网络隔离体验，同时还确保使用更新的基础结构创建所有新缓存。
迁移到新 Azure 资源管理器 VNet 子网中的新缓存。
在经典 VNet 中创建缓存会创建云服务（经典）缓存，而不会创建 Microsoft Azure 虚拟机规模集缓存。 迁移到新的 Azure 资源管理器 VNet 子网中的新缓存会解决对云服务的底层依赖问题，同时保留类似的虚拟网络体验。
我们已迁移大多数缓存，使其构建在 Azure 虚拟机规模集上，而不是构建在云服务（经典）上。 若要迁移，请删除现有缓存，并在新的 Azure 资源管理器 VNet 子网中创建新缓存。 强烈建议在迁移缓存时不要使用旧子网。 有关迁移缓存中数据的建议选项，请参阅迁移到 Azure Cache for Redis。
丢失数据的自动迁移（推荐）。
我们可以将缓存从使用 Microsoft Azure 云服务（经典）迁移到自动使用虚拟机规模集，并保留缓存配置（包括访问密钥和主机名）。 但是，这种方法需要大约 30 分钟的故障时间，并完全丢失缓存中的数据。 可以使用导入/导出功能在迁移之前保存数据的副本。
若要使用此选项，请联系 azurecachemigration@microsoft.com 或创建支持请求以请求迁移。
我的缓存未使用 VNet 注入，但我却收到了有关需要迁移的通知。 应采取何种操作？
检查缓存是否使用异地复制。 如果是，则必须将数据从当前的异地复制对迁移到新的异地复制对。
例如：
- 新建与当前缓存对的配置匹配的异地复制高级缓存对。
- 取消链接原始的异地复制缓存对，并从主要缓存中导出 RDB 文件。
- 将 RDB 文件导入到新异地复制对的主要缓存中。
新的异地复制缓存对与云服务不存在相同的依赖关系。
如果我无法创建新的缓存实例，并出现“子网受 Microsoft Azure 云服务停用影响”错误消息，我该怎么办？
我们将开始阻止使用 Microsoft Azure 云服务（经典）部署模型创建新缓存。 如果缓存是在曾经包含 Microsoft Azure 云服务缓存的虚拟网络子网中创建的，或者缓存部署到经典 VNet 中，那么仍可使用这个旧部署模型创建新缓存。 如果看到此消息，请在要将缓存部署到的 VNet 中创建新子网。 在虚拟网络中创建子网可确保在不使用 Microsoft Azure 依赖项的情况下创建缓存。
若要检查子网中是否有一个或多个基于云服务的缓存，可在门户中查看 Azure 顾问，或使用资源导航链接 REST API。
将 resource-navigation-links API 与订阅 ID、资源组名称、虚拟网络名称和子网名称配合使用，以获取该子网中使用 Microsoft Azure 的任何缓存。
如果要使用 REST API 创建新缓存，还请确保不会随创建请求一起传递 redis 配置 {"CacheVmType": "CloudService"}。 该参数是一个未记录的参数，因此不太可能执行此操作。
如果需要使用 Microsoft Azure（经典）部署模型创建新缓存，请联系 azurecachemigration@microsoft.com 或创建支持请求来请求豁免。
如果在 2024 年 8 月 31 日之前未升级/迁移缓存，会发生什么情况？
这些缓存将被关闭，缓存中的所有数据将会丢失。
支持时间表是什么？
停用将分三个阶段进行，让你有充足的时间进行迁移：
活动阶段（从现在到 2023 年 4 月 30 日）
缓存完全受支持，其状态与目前没有变化。 这段时间让客户能够从容地从云服务（经典）过渡，而且只会造成极轻微的服务中断。
维护阶段（2023 年 5 月 1 日到 2023 年 12 月 31 日）
缓存将接收关键的安全修复、稳定性修复和 bug 修复，但不会接收新功能。
非活动阶段（2024 年 1 月 1 日到 2024 年 8 月 31 日）
缓存只会接收关键的安全修复。 在收到支持之前，所有有支持问题的客户都需要迁移到基于 VMSS 的缓存。 客户必须在 2024 年 8 月 31 日之前迁移其缓存。
此时间线是否适用于 Redis 4.0 上运行的缓存？
不是。 此时间线仅适用于 Redis 6.0 上运行的缓存。 Redis 4.0 是在 Microsoft Azure 云服务（经典）停用之前完成的单独停用的一部分。 2023 年 10 月 31 日之后，在 Microsoft Azure 云服务（经典版）上使用 Redis 4.0 的所有剩余缓存将自动迁移到使用 Microsoft Azure 虚拟机规模集和 Redis 6.0。 此迁移方法需要故障时间并且缓存中的全部数据会丢失，因此如果想避免故障时间或数据丢失，请提前迁移。 请联系 azurecachemigration@microsoft.com 或创建支持请求，以在 2023 年 10 月 31 日之前请求自动升级。
如果我对此次停用有其他疑问，可以从何处获取更多信息？
请在问答页上发布有关云服务（经典）停用的任何问题。 此外，可以向 azurecachemigration@microsoft.com 发送电子邮件以获取更多信息。
一般问题
如果此处没有我的 Azure Cache for Redis 问题的解答，该怎么办？
如果此处未列出问题，请联系我们寻求答案。
若希望更多的人看到问题，可以将问题发布在有关 Azure 缓存的 Microsoft Q&A 问题页面并与 Azure 缓存团队和社区的其他成员讨论。
如果想要发出功能请求，可将请求和意见提交到 Azure Redis 缓存 User Voice。
还可以在 azurecache@microsoft.com 上向我们发送问题。