Azure托管 Redis 中的闪存优化层通过自动将不太频繁访问的数据从内存（RAM）移动到快速 NVMe 闪存存储，从而为非常大的数据集实现经济高效的缩放。 热数据保留在 RAM 中，以实现低延迟访问；而冷数据则存放在 NVMe 中，并在被访问时传输到 RAM，其每 GB 成本低于纯内存层。
Flash Optimized 的工作原理
Azure托管 Redis Flash Optimized 使用分层存储方法：
- 热数据 - 经常访问的密钥和值保留在 DRAM 中，延迟为子毫秒。
- 冷数据 - 访问频率较低的数据会自动移动到主机 VM 上的本地 NVMe 存储，并在访问时传输回 RAM。
- 客户端托管 - 分层完全由系统管理。 客户端使用标准 Redis 命令与缓存交互，而不知道数据的物理驻留位置。
与内存中部署相比，此体系结构允许以明显更低的成本维护 TB 范围内的缓存。
Note
通过 Flash Optimized 将数据存储在 NVMe 上不会 增加数据复原能力。 对于持久性，除了闪存存储之外，还配置 数据持久性 （RDB 或 AOF）。
何时使用 Flash Optimized
Flash Optimized 非常适合以下情况：
- 数据集非常大（数百 GB 到多个 TB）。
- 相当一部分数据很少被访问（“冷数据”）。
- 你需要面向热数据的 Redis 语义和性能，但又希望避免将所有数据都保存在 DRAM 中所带来的成本。
- 你的工作负载相较于内存层，能够容忍冷数据读取略高的延迟。
常见用例包括：
- 分析和报告 - 大型查找表、聚合数据集
- 社交和游戏 - 用户配置文件、会话历史记录、带有长尾的排行榜
SKU 规格
| SKU | 大小(GB) | 地位 |
|---|---|---|
| A250 | 235 | GA |
| A500 | 480 | GA |
| A700 | 720 | GA |
| A1000 | 960 | GA |
| A1500 | 1,440 | GA |
| A2000 | 1,920 | 公共预览版 |
| A4500 | 4,500 | 公共预览版 |
有关每个 SKU 的连接限制，请参阅 最大客户端连接数。 有关定价详细信息，请参阅 Azure 托管 Redis 定价。
功能支持
下表汇总了 Flash 优化层上的功能可用性：
| 特性 | 支持 |
|---|---|
| SLA | 是的 |
| 传输中的数据加密（专用终结点） | 是的 |
| 复制和故障转移 | 是的 |
| 网络隔离（专用链接） | 是的 |
| Microsoft Entra ID 身份验证 | 是的 |
| Scaling | 是的 |
| 高可用性（区域冗余） | 是的 |
| 数据持久性 （RDB/AOF） | 是的 |
| 连接审核日志（基于事件） | 是的 |
| RedisJSON | 是的 |
| 导入/导出 | 是的 |
| 主动异地复制 | 否 |
| 非群集实例 | 否 |
| RediSearch /矢量搜索 | 否 |
| RedisBloom | 否 |
| RedisTimeSeries | 否 |
Important
RedisJSON 是 Flash Optimized 层上唯一支持的模块。 不支持活动异地复制、非聚集模式、RediSearch/矢量搜索、RedisBloom 和 RedisTimeSeries。
有关跨所有Azure托管 Redis 层的功能的完整比较，请参阅 什么是Azure托管 Redis？。
最佳做法
如何使用闪存存储
在闪存优化实例上，20% 的缓存空间位于 RAM 上，其他 80% 则使用 Flash 存储。 所有密钥都存储在 RAM 中，而值可以存储在闪存存储或 RAM 中。 Redis 软件智能地确定值的位置。 经常访问的热值存储在 RAM 中，而不太常用的冷值保存在 Flash 上。 在读取或写入数据之前，必须将其移动到 RAM，成为热数据。
由于 Redis 将进行优化以实现最佳性能，因此在向 Flash 存储添加项之前，该实例将首先填满可用的 RAM。 先填充 RAM 会对性能产生一些影响：
- 在按低内存使用率进行测试时，可能会出现更好的性能和较低的延迟。 使用完整缓存实例进行测试可能会降低性能，因为在低内存使用率测试阶段仅使用 RAM。
- 向缓存写入更多数据时，与 Flash 存储相比，RAM 中的数据比例会降低，这通常也会降低延迟和吞吐量性能。
非常适合 Flash 优化的工作负载
在闪存优化层上可能运行良好的工作负载通常具有以下特征：
- 读取密集型，其读取命令与写入命令的比率较高。
- 访问侧重于使用频率远高于数据集其余键的一部分键。
- 与键名称相比，值相对较大。 （由于键名始终存储在 RAM 中，因此较大的值可能会成为内存增长的瓶颈。）
不太适合闪存优化的工作负载
某些工作负载的访问特征针对 Flash 层设计进行的优化较少：
- 写入密集型工作负载。
- 大多数数据集中的随机或统一数据访问模式。
- 键名称较长，但值的大小相对较小。
优化热/冷数据比率
访问模式越可预测，优化闪存性能越好：
- 访问频率稳定的键可从稳定的分层中受益。
- 整个数据集中具有极其随机访问模式的工作负荷将导致延迟下降
- 使用
INFO和监控来了解您的命中率和淘汰行为。
使用数据持久性实现持久性
闪存存储用于性能分层， 不适用于数据保护。 配置 RDB 快照或 AOF 持久化，以防止因中断导致的数据丢失。 Flash Optimized 支持这两个持久性选项。
网络和安全性
- 专用终结点 - 始终使用 专用链接，使流量保留在你的 Azure 虚拟网络内。
- Microsoft Entra ID - 尽可能使用无密码身份验证来提高安全状况。
- 客户管理密钥（CMK） - 使用 Azure 密钥保管库 配置静态加密，以满足合规要求。
客户端配置
- 有关客户端超时和连接复原指南，请参阅 连接复原最佳做法。
- 使用管道传送来最大化吞吐量。
- 首选许多小键而不是几个大型键。
- 监视连接、延迟百分位数（尤其是 p99）和 CPU。
常见问题和故障排除
尽管仍有可用的闪存容量，大值仍会导致 OOM
具有大值的键可能会导致 Flash 缓存出现问题。 最佳做法是将值大小保持在 512KB 以下。
所有密钥名称始终存储在 RAM 中。 过大的值会被固定在 RAM 中，无法卸载到 Flash，这可能会导致内存不足（OOM）错误，即使 Flash 存储仍有可用容量。
缓解：将大值分解为较小的键，使用压缩或分块策略。
小数据值与闪存效率
非常小的值（如果值大小接近或小于键名称大小）也会在 Flash 上表现不佳，因为没有足够的数据卸载。 当值的大小大于键名的大小，但又不能过大时，RoF 的效果最佳。