怎样使用twemproxy代理架构管理旧版本Redis集群-Redis-PHP中文网

twemproxy（nutcracker）是管理redis 2.8–4.x旧版本集群最稳定、侵入性最小的代理方案，不依赖redis集群协议，仅通过透明分片和连接复用实现轻量级集群管理，适用于单机或主从架构且无需修改应用代码的场景。

怎样使用twemproxy代理架构管理旧版本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 生产环境里，恰恰是最常出问题的地方。