keydb可直接替换redis但需调整go-redis/v9配置：禁用client setname、设minidleconns=1、关闭routebylatency、重写lua脚本强制master读，并显式配置maxmemory-policy。
KeyDB 能直接替换 Redis，只要客户端用的是标准 RESP 协议——go-redis/v9 完全没问题，连代码都不用改，但必须关掉 pipeline 的 auto-flush、禁用连接池预热、并显式设置 MaxRetries 为 0。
为什么 go-redis/v9 连 KeyDB 默认会出错
KeyDB 默认关闭了 CLIENT SETNAME 命令（出于安全加固），而 go-redis/v9 初始化时会自动发这条命令设 client name。一旦失败，整个连接池就卡死在 failed to set client name 状态，后续所有 rdb.Get() 都 timeout。
- 临时解法：启动 client 时加
DisableClientName: true - 正确做法：在 KeyDB 配置里打开
client-setname yes（不推荐生产环境） - 更稳妥的：用
redis.NewUniversalClient+redis.NewFailoverClient绕过初始化逻辑（适合集群场景）
多线程下连接复用必须调低 MinIdleConns
KeyDB 多线程模型对单个连接的并发请求容忍度比 Redis 低——不是性能差，而是它把 I/O 和命令执行拆到不同线程，连接复用率过高反而引发内部锁争用。实测 MinIdleConns=5 时 QPS 反比 MinIdleConns=1 低 18%。
- 建议设为
MinIdleConns: 1，MaxIdleConns: runtime.NumCPU() * 2 - 别依赖
ConnPoolSize，KeyDB 不吃这套；v9 里它只影响底层 net.Conn 数量，和实际命令吞吐无关 - 如果用了
redis.NewClusterClient，记得关掉RouteByLatency: true，KeyDB 的 slot 路由响应时间抖动大，开这个反而导致请求打偏
Active Replication 场景下解锁 Lua 脚本要重写
KeyDB 的 Active Replication 支持多主写入，但它的 GET 命令默认读本地副本，而 DEL 会路由到 key 所在 master。你用标准 Redis 解锁脚本：if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end，在跨主写入时可能 GET 到旧值、DEL 却删掉别人刚设的锁。
- 必须改成带
READONLY标识的脚本，强制走 master 读：redis.replicate_commands(); if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end - 调用前加
script.Load(ctx, rdb).Run(ctx, rdb, []string{key}, clientID)，不能缓存 script 实例——KeyDB 对 script cache 的一致性保障弱于 Redis - 别信文档里“完全兼容”的说法，Active Replication 下的原子性边界变了
最易被忽略的是 KeyDB 的 maxmemory-policy 默认是 noeviction，而多数 Redis 部署习惯用 allkeys-lru。如果你没显式配置，内存爆掉时 KeyDB 直接拒绝写入，错误是 OOM command not allowed when used memory > 'maxmemory'，而不是像 Redis 那样悄悄淘汰——这个细节会让压测结果看起来“性能断崖”，其实只是配置漏了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
