info命令仅返回单节点瞬时流量指标instantaneous_input_kbps和instantaneous_output_kbps（kb/s），需逐节点执行；redis-cli --stat不支持集群遍历；全集群流量监控须依赖redis_exporter+prometheus聚合。
直接用 INFO 命令看单节点流量，但要注意字段含义
Redis 本身不提供“集群总流量”聚合视图，INFO 返回的是当前连接节点的实时指标。关键字段是：instantaneous_input_kbps 和 instantaneous_output_kbps，它们代表**当前秒级的入/出带宽（KB/s）**，不是累计值。这两个值波动大、瞬时性强，适合观察突发流量，不适合做长期趋势分析。
执行方式很简单：
redis-cli -c -h 192.168.1.10 -p 6379 INFO | grep -E "instantaneous_(input|output)_kbps"
注意：必须对每个节点单独执行，不能靠集群代理自动路由——redis-cli -c 会把 INFO 转发到目标节点，但不会帮你遍历所有节点。
redis-cli --stat 只能连单点，无法反映集群整体压力
redis-cli --stat 是个方便的实时监控命令，但它只连接你指定的那个节点，并持续刷新该节点的 instantaneous_ops_per_sec、used_memory_human 等字段。它**不会自动发现或轮询其他节点**，更不会合并计算。
- 如果你只连主节点 A，看到 ops 飙升，可能只是 A 上的 slot 分布密集，不代表整个集群负载高
- 如果连的是从节点，
instantaneous_input_kbps可能包含大量主从同步流量，和客户端请求混在一起，难以区分 - 它没有输出时间戳，不方便做日志归档或告警比对
想看全集群流量，得靠 redis_exporter + Prometheus
生产环境真正可行的方式是部署 redis_exporter，为每个 Redis 节点起一个 exporter 实例，再由 Prometheus 抓取并聚合。这是唯一能跨节点做 sum by(instance)(rate(redis_connected_clients[1m])) 这类计算的方案。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
几个实操要点：
- 每个节点配独立的
redis_exporter，监听不同端口（如 9121～9126），避免端口冲突 - Prometheus 的
scrape_configs必须显式列出全部节点地址，不能只写一个 —— 它不会自动发现集群拓扑 - 关键指标用
rate(redis_net_input_bytes_total[1m])和rate(redis_net_output_bytes_total[1m])，比instantaneous_*更稳定，适合画趋势图 - 别依赖
redis_cluster_keys类指标算“数据量”，它只统计 key 数量，和实际流量无关
临时排查突发流量，MONITOR 有用但极耗资源
当怀疑某节点被恶意刷请求或某个业务突发写入时，可以用 MONITOR 抓原始命令流。但它会让 Redis 单线程阻塞在日志输出上，**在生产环境开启超过 10 秒就可能引发超时雪崩**。
安全做法是：
- 先用
INFO clients看connected_clients和client_longest_output_list，确认是否真有异常连接 - 只在低峰期、对单个节点执行
redis-cli -h x.x.x.x -p 6379 MONITOR | head -n 1000 > monitor.log - 用
awk '{print $3}' monitor.log | sort | uniq -c | sort -nr | head -10快速识别高频命令（比如全是SET或LPUSH）
真正要长期盯流量，别指望手工命令；exporter + Prometheus 是目前最轻量又可靠的路径，漏掉任何一个节点的 exporter，那部分流量就彻底不可见了。
