tcpcopy不适用于redis集群压测，因其仅工作在网络层，无法解析resp协议、处理moved/ask重定向、维持连接状态，导致请求丢失、连接混乱和假瓶颈。
Redis集群压测不能直接用TCPCopy做流量镜像——它不支持Redis协议层的会话状态还原，强行用会丢请求、乱连接、压出假瓶颈。
为什么tcpcopy对Redis集群压测基本无效
TCPCopy是基于TCP流重放的工具，它在网络层复制原始数据包，但Redis集群通信涉及Slot路由、MOVED/ASK重定向、客户端连接复用、Pipeline粘包等协议行为。tcpcopy无法识别MOVED 1234 10.0.1.5:6379这类响应，也不会帮客户端自动跳转；更关键的是，它把所有连接都当成独立流处理，而真实Redis客户端（如Lettuce、Jedis）依赖连接池和长连接状态管理。结果就是：压测流量发出去了，但90%请求卡在重定向循环或连接超时，redis-cli --cluster check看到的错误全是Connection refused或NOAUTH Authentication required（因为认证头被截断或错序）。
- tcpcopy默认不解析应用层协议，只做IP+TCP头转发，对RESP协议零感知
- Redis集群节点间有Gossip通信（端口16379），tcpcopy无法区分client流量和cluster bus流量，一并复制会导致测试环境集群状态混乱
- 若线上用TLS加密（
redis.conf中tls-cert-file启用），tcpcopy捕获到的是密文，转发后目标Redis直接拒绝握手
真正可行的Redis流量镜像方案：用redis-proxy + 日志回放
绕过协议层限制的务实做法，是让流量先落地为可读、可过滤、可重放的命令日志。推荐用redis-proxy（如Twemproxy或自研轻量代理）开启慢日志或全量访问日志，再用redis-replay或自写脚本回放。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在Redis前置代理层加
slowlog-log-slower-than 0（记录所有命令），配合slowlog-max-len 1000000避免截断 - 日志格式需包含完整时间戳、客户端IP、目标key、命令、耗时，例如：
[2026-05-27T13:22:01.123] 10.0.1.8:54321 SET user:1001 {"name":"a","age":28} 1.2ms - 用
redis-replay（GitHub上活跃项目）加载日志：它支持按时间戳重放、QPS限速、key前缀替换（把user:→test:user:）、自动跳过INFO/CONFIG等管理命令 - 注意替换
CLUSTER相关命令：日志里的CLUSTER SLOTS必须删掉，否则回放时会干扰测试集群拓扑
如果非要硬上TCPCopy：必须满足的三个前提条件
极少数场景（如单节点Redis+直连无重定向）下可尝试tcpcopy，但必须提前验证并锁定配置：
- 线上Redis必须是单机模式（非cluster、非sentinel），且禁用
protected-mode yes和requirepass，否则tcpcopy转发的未认证请求全被拒 - 测试机Redis需关闭
tcp-keepalive，并调大net.ipv4.tcp_fin_timeout，否则tcpcopy模拟的短连接风暴会迅速耗尽TIME_WAIT连接数 - tcpcopy启动参数必须加
--port 6379 --ip 127.0.0.1显式指定目标，不能依赖默认；同时在测试机运行intercept时，iptables规则要精确匹配OUTPUT方向的6379端口响应包，否则intercept收不到ACK导致tcpcopy认为连接失败
真正难的不是把流量“复制过去”，而是让Redis集群在压测时相信这些请求来自合法客户端、走对Slot、拿到正确响应、不污染自身状态。协议层盲转发在这里是死路，日志级回放才是可控路径。别在tcpcopy的日志里找MOVED错误原因了——那不是bug，是设计使然。
