Redis 脚本在集群模式下有哪些一致性问题，如何处理？
未标记
考查重点：单节点原子性与集群故障窗口。Lua 只保证单节点执行原子，多键集群操作通常需同槽；主从切换仍有复制窗口，跨槽流程另设计事务/补偿
本题目录
参考答案
核心回答
需要分清三件事：脚本在单个 Redis 节点上的执行原子性、Cluster 的跨槽限制，以及主从复制和故障切换的一致性。Lua 脚本不会因为部署在 Cluster 中就失去单节点原子执行能力；但它不能自动变成跨分片事务，也不能保证已确认写入在任意故障下都不丢失。
各类问题如何处理
多个 Key 跨槽：普通 Redis Cluster 中，一个脚本涉及的 Key 应落在同一哈希槽，且通过 KEYS 参数显式声明。可以把同一业务聚合内的键设计成 stock:{sku123} 与 request:{sku123}，共同的 hash tag 让它们进入同一槽。仅仅当前恰好在同一节点，并不等于满足同槽要求。
同槽设计应保持业务局部性；把所有数据都塞进一个 tag 会形成单分片热点。确实跨聚合的操作，应重新划分原子边界，或在应用层设计持久状态、幂等、补偿与对账；不能先在多个节点各执行一段 Lua，就宣称整体原子。
执行报错：原子执行表示期间不会穿插其他客户端命令，不等于数据库式失败回滚。脚本前半段已经成功的写入，可能在后续命令报错后保留。应先检查参数、类型、业务条件，再执行尽可能短小的写入段；关键结果仍需可查询、可对账。
主从与故障切换：Redis Cluster 使用异步复制，主节点返回成功后、写入尚未到达副本时故障，仍可能丢失这次结果。从副本读也可能得到旧值。业务不能用“Lua 是原子的”替代持久化与容灾设计；库存、支付等重要事实需要合适的事实存储和恢复机制。
超时与脚本缓存：客户端超时不代表脚本没执行，重试可能重复扣减，应带业务请求标识并原子去重。节点重启或切主后还可能出现 NOSCRIPT，客户端需要重新加载脚本；槽迁移期间的重定向或暂不可用错误，也应由支持集群路由的客户端按明确策略处理。
常见追问
hash tag 解决了一致性吗？ 它解决相关 Key 的同槽布局，为单节点原子执行创造条件；并没有解决故障丢写、跨系统事务或重复请求。
脚本越长越好吗？ 不是。长脚本会占用节点执行时间，拖慢其他请求。应限制处理规模，避免无界遍历，把重计算移到适合的位置。
参考资料
- 国内：JavaGuide / Snailclimb：Redis 常见问题（下）：Lua：借鉴 Lua 执行隔离与报错后保留既有写入的说明，区分正文中的原子执行与失败回滚。
- 国内：小林 coding：为什么要有 Redis Cluster 集群：参考 Hash Tag 与从节点读取，解释正文中同槽布局和复制延迟分别影响的范围。
- 国内：白宸 / 阿里云开发者社区：阿里云 Redis Lua 命令支持及相关限制说明：采用跨槽报错与 Key 参数要求，解释正文中 Cluster 脚本接入需要同槽并显式声明键的原因。
- 国外：Redis：Scripting with Lua：依据脚本隔离、显式 Key 参数与缓存重载的说明，界定正文中 Lua 的单节点执行范围及 NOSCRIPT 后的处理。
- 国外：Redis：Redis Cluster specification：写安全与多 Key 章节解释异步复制丢写窗口、同槽要求和迁移期间的暂不可用。
