Redis 8.8 array 数据结构适合哪些索引式数据场景

Redis 8.8 新增的 array，适合解决一个很具体的问题：数据的“位置”本身就是业务索引。比如文档第 4821 行、某分钟的采样值、设备编号对应的槽位，读取时希望直接按数字位置拿到值，而不是从头遍历。若数据只需要先进先出，继续用 List；若字段名比数字位置更重要，Hash 更合适。

官方资料：https://redis.io/docs/latest/develop/whats-new/8-8/

Redis array 最适合哪类数据

判断标准不是“它是不是数组”，而是索引有没有稳定含义。array 的元素是字符串，索引从 0 开始；可以连续写入，也可以在很大的位置写一个值，中间空槽不必逐个占位。官方文档把它归为稀疏、可索引的序列，并区分“逻辑长度”和“已有元素数量”。

典型场景有四类：按行号定位文档或日志；按时间槽保存采样快照；只保留最近一段事件；以及用稀疏索引表示编号并不连续的对象。最后一类尤其适合“编号很大、实际值很少”的数据，但仍要评估索引范围和内存预算。

用最小命令验证连续和稀疏索引

先用连续写入建立一个小数组，再用 ARMSET 写入分散位置。ARGET 读取空位置时返回空值，不会把空槽误当成空字符串。

# 连续写入三条状态，索引从 0 开始
redis-cli ARSET device:42:status 0 "idle" "running" "done"

# 直接读取第 1 个位置，随机访问不需要遍历前面的元素
redis-cli ARGET device:42:status 1

# 用非连续索引表达设备编号或时间槽，中间位置保持为空
redis-cli ARMSET sensor:room-a 0 "21.4" 60 "21.8" 300 "22.1"

# 读取已写入位置与空位置
redis-cli ARMGET sensor:room-a 60 61 300

ARSET 适合一段连续索引，ARMSET 适合一次写多个“索引-值”对。需要统计时，不要只看 ARLEN：它反映最高索引加一；ARCOUNT 才是非空元素数量。这个区别能避免把大量空槽误算成真实数据量。

滑动窗口、聚合和搜索何时值得用

如果需求是“始终保留最近 N 个事件”，ARRING key size value... 直接表达环形缓冲区，写入满后覆盖更旧的数据。相比客户端执行 RPUSH 再 LTRIM，它把窗口动作收进一个命令，减少拼接逻辑和往返。

如果索引范围内的值还要做计算，可以考虑 AROP：数值支持 SUM、MIN、MAX，布尔标志支持 AND、OR、XOR，还可判断已使用位置。日志或文本行场景则可用 ARSCAN 按范围返回索引和值，或用 ARGREP 做匹配搜索。

不要把 array 当成 List 的全量替代

array 的优势是按数字索引和范围工作，不代表它在所有有序数据上都更好。需要两端 push/pop 的队列、需要在中间插入元素的序列，List 的语义更直接；需要 user_id、status 这类字段名访问对象，Hash 更自然；需要消费组、待确认消息和重投递，应该继续使用 Stream。

还要注意两个边界：array 存的是字符串值，复杂嵌套对象仍需由应用序列化或改用 Hash/JSON；另外，范围聚合的成本取决于访问的范围和实际元素，不能只根据单点读取的 O(1) 就推断所有操作都一样快。上线前应按真实索引分布、空槽比例和窗口大小压测。

相关问题

Redis 8.8 array 能替代 Hash 吗？

只有当字段可以稳定映射为数字索引时才考虑替代。字段名经常变化或需要按字段表达业务含义时，Hash 更易读也更易维护。

array 的空索引会自动补很多内存吗？

array 支持稀疏索引，写入大索引不会按空槽数量线性填满内存；但实际占用仍与数据量、值大小和内部切片结构有关，生产数据要实测。

什么时候继续用 List？

当主要动作是从两端入队、出队，或需要在序列中插入元素时，List 的操作模型更贴合，没必要迁移到 array。

如何确认当前 Redis 支持 array？

先确认服务端为 Redis 8.8 或更高版本，再在测试 key 上执行 ARSET 和 ARGET。正式环境还要核对客户端是否已经封装这些命令，必要时通过通用命令接口调用。