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 字样。
