Redis的SMEMBERS命令是否为确定性操作，能否保证每次调用返回结果顺序固定

核心结论 #

Redis本身从设计层面，不会对任何场景下调用SMEMBERS的返回结果做固定顺序的承诺。同一集合多次执行同一命令、内容完全一致的不同集合实例，返回的元素顺序都可能存在差异，这个特性是由集合本身的无序设计定位决定的。目前SMEMBERS的官方文档也从未提及任何关于返回顺序的保证说明，所有和顺序相关的特殊处理都是特定场景的临时逻辑，不属于命令的固有能力。

底层逻辑说明 #

Redis的集合类型根据存储状态会切换两种底层实现，两种实现都没有对外暴露顺序遍历的契约：

• 当集合元素数量少、且全部为整数类短值时，底层采用intset结构存储，这类结构本身会按元素值大小排布，但这只是为了提升查询效率的内部存储优化，不是对外承诺的返回顺序规则。
• 当集合不满足intset的存储阈值要求时，底层会切换为hashtable结构存储，这类结构的元素遍历顺序完全受哈希分布、动态扩容/缩容、元素增删动作影响，同一批元素在不同运行阶段的遍历结果没有可预测的固定规律。

不同版本下的行为差异 #

你提到的Lua脚本调用场景的特殊逻辑，是不同版本为适配脚本复制机制做的临时处理，不属于SMEMBERS命令本身的特性：

• Redis 4 版本阶段：因为当时的脚本复制机制需要将非确定性的命令返回结果转成确定性结果，才能正确同步到从节点保证主从数据一致，所以会在把SMEMBERS的返回结果传给Lua脚本前，额外做一层静默的字典序排序。这一阶段在Lua里拿到的SMEMBERS结果是固定有序的，但这个处理是脚本执行链路的隐式逻辑，官方始终不建议开发者依赖这个隐式行为。
• Redis 5 版本及之后：脚本复制机制调整为直接传播脚本本身的执行逻辑，不再需要把非确定性命令转换为确定性输出，因此彻底移除了返回给Lua脚本的SMEMBERS结果的隐式排序步骤。此时不管是普通客户端调用，还是Lua脚本内调用，拿到的都是底层结构原生遍历的结果，没有额外的顺序保障。

对应你当前使用版本的提示 #

你当前使用的Redis 5.0.3版本，已经完全移除了Lua链路的隐式排序逻辑，SMEMBERS的返回顺序完全由底层集合的当前存储状态决定：

• 如果集合一直保持intset存储、没有发生元素增删、结构升级，短时间内多次调用可能返回顺序一致，但这只是特定存储状态下的偶然结果，不是Redis对外承诺的稳定特性。
• 一旦集合发生元素增删、触发哈希结构扩容/缩容、满足阈值升级为hashtable存储，返回顺序就很可能发生变化，跨实例、跨节点的同内容集合的返回顺序更没有一致性可言。

实际开发注意事项 #

• 绝对不要将SMEMBERS的返回顺序作为稳定依赖设计业务逻辑，比如不要靠返回顺序判断两个集合的内容是否一致、不要直接将返回顺序作为下游系统的对比校验依据。
• 如果业务需要固定顺序的集合元素，应当在拿到命令返回结果后，在应用层按照自定义规则（比如字典序）做排序处理，不要寄希望于命令本身返回有序结果。

内容的提问来源于stack exchange，提问作者Orkun