不能直接用set更新配置，因其缺乏原子性、无法校验json结构合法性；应使用eval lua脚本原子读取、解析、合并、序列化并写回，读操作也须统一走封装脚本，并配合版本键切换或发布订阅机制保障一致性。
为什么不能直接用 SET 更新配置？
直接用 SET 覆盖配置键看似简单，但会丢失原子性：比如更新 config:rate_limit 时，新旧值之间存在短暂窗口，客户端可能读到中间态（如部分字段已更新、部分未更新），或触发并发写覆盖。更麻烦的是，若配置含多个字段（如 JSON 字符串），SET 无法校验结构合法性，错误格式写入后服务可能直接崩溃。
EVAL 脚本里如何安全合并新旧配置？
用 Lua 脚本做原子合并，核心是读取旧值 → 解析 → 合并新字段 → 序列化 → 写回。Redis 自带 cjson，但要注意：cjson.decode() 遇到非法 JSON 会报错中断脚本，必须用 pcall 包裹；cjson.encode() 对 nil 值默认转成 null，而很多业务逻辑把 nil 当“删除字段”处理，需手动过滤。
常见做法：
- 先用
redis.call("GET", KEYS[1])获取旧配置，判空后决定是否初始化 - 用
pcall(cjson.decode, old_json)解析，失败则拒绝更新并返回错误 - 遍历
ARGV[1]（传入的新配置表）逐字段覆盖，对值为nil的键执行table.remove模拟删除 - 最终用
cjson.encode输出，再redis.call("SET", ...)
热更新时怎么避免客户端读到脏数据？
即使 Lua 是原子的，客户端仍可能在脚本执行前后读到不一致状态。关键不是“脚本快”，而是“读写契约统一”。建议强制所有读配置逻辑走同一个 Lua 脚本（如 get_config），该脚本内部加一层 redis.call("GET", KEYS[1]) + cjson.decode 封装，确保每次读都拿到合法 JSON；同时禁止任何直连 GET 的代码路径。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
额外要点：
- 配置键建议加版本号后缀（如
config:feature:v2），更新时先写新键，再用RENAME原子切换，避免单键更新期间的读抖动 - 若业务允许秒级延迟，可用
PUBLISH config:update通知监听者刷新本地缓存，比轮询高效 - 不要在 Lua 里做耗时操作（如循环遍历上千字段），Redis 单线程下会阻塞其他命令
调试 Lua 脚本时最常踩的坑
Redis Lua 环境受限：没有 print，不能 require 外部库，os.time() 返回的是服务器时间而非脚本启动时间。出错时只返回 (error) ERR Error running script，非常模糊。
实操建议：
- 本地用
redis-cli --eval script.lua key1 key2 , arg1 arg2测试，逗号前后分隔 KEYS 和 ARGV - 在脚本开头加
if not cjson then return "cjson not loaded" end，确认环境支持 - 对关键步骤用
redis.log(redis.LOG_WARNING, "step: decode ok")记录日志（需 Redis 配置loglevel warning） - 传入的
ARGV全是字符串，数值需用tonumber()转换，否则10 > 2会按字符串比较得 false
真正难的不是写脚本，而是让所有服务方和配置发布方对“配置即代码”的一致性达成共识——比如谁负责校验 schema，谁兜底降级，这些不在 Lua 里，但在生产环境里天天出事。
