Twemproxy连Redis集群失败主因是未声明redis协议，需在server_stats上方配置protocol: redis；其不支持SCAN等命令，节点名须带端口和权重；已停更，新项目应避免使用。

Twemproxy 连不上 Redis 集群：配置里漏了 redis 协议声明

Twemproxy 默认用 memcache 协议，连 Redis 会直接返回 ERROR 或静默断连，不是密码错也不是端口错——是协议没切过去。

• redis 协议必须在 server_stats 上方显式声明：protocol: redis
• 不支持 Redis 的 SCAN、PUB/SUB、SCRIPT 等命令，发了会报 NOT_SUPPORTED
• 集群节点名写法要带端口，比如 127.0.0.1:7001:1，最后的 :1 是权重，不能省
• Twemproxy 已停止维护，新项目别踩坑；生产环境遇到连接抖动，优先查 stats 接口里的 server_eof 和 server_econnrefused 计数

Predixy 启动报 can't resolve hostname：DNS 解析发生在代理侧而非客户端

Predixy 读取配置时会立即解析所有 host，如果配置里写了 redis-cluster-01.internal 但代理机器没配 DNS 或 /etc/hosts，启动就失败，和客户端完全无关。

• 要么把所有节点写成 IP（推荐），要么确保 Predixy 所在机器能 nslookup 通那些域名
• auth 密码必须全局统一，Predixy 不支持 per-node 密码，设成空或错一个节点全挂
• 它默认开启 redis_cluster_mode，但只识别 CLUSTER NODES 返回中的 master 角色，从节点被忽略——别指望它自动转发 READONLY 请求
• 配置改完必须 kill -USR2 重载，SIGHUP 不生效

客户端用 redis-cli 直连 Twemproxy/Predixy：别碰 KEYS * 和管道批量命令

代理层对 key 做一致性哈希分片，KEYS * 这种广播型命令会被拆成 N 个请求发给所有后端，响应乱序拼接，结果不可靠；管道命令则可能因 key 落在不同节点而被代理截断或报错。

• Twemproxy 对 MGET 支持有限：所有 key 必须落在同一分片，否则返回部分结果 + ERROR
• Predixy 的 pipeline 要求所有命令 key 哈希一致，否则直接拒绝，错误信息是 cross slot
• 想扫数据？老实用客户端连单个节点，别依赖代理
• 监控时别只看代理的 uptime，重点盯 client_err 和 forward_err —— 前者是协议错，后者才是后端真实故障

为什么加了代理反而延迟更高：TCP 连接复用没开 + 持久化配置冲突

Twemproxy 默认每个 client 连接对应一个 backend 连接（redis_tcp_nodelay: true），高频小请求下建连开销压倒收益；Predixy 默认禁用 tcp_keepalive，长连接容易被中间设备回收。

• Twemproxy 必须加 redis_max_connections: 1000 并配 redis_timeout: 400，否则连接池撑不住
• Predixy 要开 tcp_keepalive: on 和 tcp_keepalive_idle: 60，不然 NAT 网关 5 分钟就断链
• 两者都不支持 Redis 6+ 的 ACL，如果后端启用了 ACL，代理连上去就是 NOAUTH 错误，不是密码问题
• 代理本身不存数据，故障时不会丢命令，但会放大后端节点波动——比如某节点卡住，所有发往它的请求都会超时堆积

代理不是银弹。真正难处理的是跨槽操作、事务、Lua 脚本这些，它们在代理层要么被拒，要么行为未定义。上线前拿真实流量跑一周，重点看 client_err 曲线和慢日志里有没有 crossslot 或 not supported 字样。