Twemproxy（nutcracker）是管理Redis 2.8–4.x旧版本集群最稳定、侵入性最小的代理方案，不依赖Redis集群协议，仅通过透明分片和连接复用实现轻量级集群管理，适用于单机或主从架构且无需修改应用代码的场景。
twemproxy（即 nutcracker）至今仍是管理 Redis 2.8–4.x 等旧版本集群 最稳定、侵入性最小的代理方案——它不依赖 Redis 自身的集群协议（CLUSTER 命令族），完全在客户端与服务端之间做透明分片和连接复用。如果你的 Redis 实例是单机或主从结构、版本低于 5.0、又不想改应用代码，twemproxy 就是实际可用的解法。
nutcracker 启动失败：常见报错和依赖检查
启动 nutcracker 时卡住或报错，90% 出在编译环境或运行时依赖上：
- 报错
error: Autoconf version 2.64 or higher is required：系统自带autoconf版本太低（如 CentOS 6 默认 2.63），必须卸载后手动安装 2.69+ - 报错
./configure: No such file or directory：漏了autoreconf -fvi步骤，源码未生成 configure 脚本 - 启动后立即退出、无日志：配置文件路径错、
listen地址被占用、或servers列表里有不可达的 Redis 地址（比如防火墙阻断、bind配置为127.0.0.1却从远程连） - 日志里反复出现
server X.X.X.X:6379 failed：后端 Redis 未开启tcp-backlog或未允许外部连接（检查redis.conf中bind和protected-mode no）
建议启动时加 -d -v -c /path/to/nutcracker.yml，用 -v 查看详细错误，别直接后台运行。
nutcracker.yml 配置中几个关键参数的实际含义
twemproxy 的行为几乎全由 YAML 配置驱动，但文档模糊，容易配错：
hash：决定 key 如何映射到后端节点。旧版 Redis 不支持HASH TAG外的复杂路由，推荐固定用fnv1a_64（比md5快，碰撞率低）distribution：必须选ketama；modula在增减节点时会导致 100% 数据重分布，random完全不可控-
auto_eject_hosts+server_failure_limit+server_retry_timeout是故障转移核心：
CPA Update - Secure CLI Proxy API Maintenance下载安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
auto_eject_hosts: true才会自动摘除故障节点 -
server_failure_limit: 1表示只要一次连接/命令失败就摘除（对旧 Redis 主从切换不稳很关键） -
server_retry_timeout: 2000（单位毫秒）是摘除后多久尝试恢复，设太短会反复震荡
-
redis: true必须显式开启，否则按 Memcached 协议解析，SET/GET会失败timeout：是代理等待后端响应的超时（毫秒），旧 Redis 在慢查询或 AOF rewrite 时可能卡住，建议设为 500–1000，别盲目调大
示例片段：
alpha:
listen: 0.0.0.0:22121
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: true
redis: true
timeout: 500
server_retry_timeout: 2000
server_failure_limit: 1
servers:
- 192.168.1.10:6379:1
- 192.168.1.11:6379:1
使用 redis-cli 连 twemproxy 时的兼容性陷阱
twemproxy 不支持所有 Redis 命令，旧版本尤其明显：
-
KEYS *、SCAN、INFO、CONFIG、CLIENT LIST等管理类命令会被直接拒绝或只发给第一个 backend，返回结果不可靠 -
MGET、MSET、DEL等多 key 命令，只有所有 key 落在同一节点才成功；否则报cross-slot keys类错误（注意：这不是 Redis Cluster 的错误，而是twemproxy自己拦截的） - 想跨节点批量操作？只能靠客户端拆成单 key 请求，或改用
HASH TAG（如{user1001}.name和{user1001}.email）强制同节点 -
WATCH/MULTI/EXEC事务在twemproxy下完全不可用，因为无法保证所有 key 在同一连接上执行
验证是否走通：用 redis-cli -h proxy_ip -p 22121 连上后，只测 SET k v → GET k → INCR counter，别一上来就跑压测脚本。
twemproxy 的本质是“无状态分片代理”，它不存数据、不协调节点、不处理主从切换逻辑——这些都得靠你在后端 Redis 层自己搞定（比如用哨兵 + 脚本 reload 配置）。最容易被忽略的一点是：它不会自动感知 Redis 主从角色变化。如果主挂了、哨兵切了新主，你必须手动更新 nutcracker.yml 并 kill -HUP 重载，或配合外部工具轮询哨兵获取最新 master 地址再触发 reload。这点在旧版 Redis 生产环境里，恰恰是最常出问题的地方。
