背景：我记不住那么多命令，又是Linux命令，又是Git命令，又是kubernetes的命令，又是maven命令，又是redis命令。所谓好记性不如烂笔头，记下来吧。
一. 服务器集群常用命令
0. cluster info 获取集群信息
1. 核心状态指标 cluster_state: 集群的状态。 ok: 集群功能正常，所有哈希槽（hash slots）均已分配且对应的节点在线。 fail: 集群无法正常工作。通常是因为至少有一个哈希槽未分配（节点宕机且无从节点接管）。 cluster_slots_assigned: 已成功分配到节点的哈希槽总数。 对于一个正常的集群，该值必须为 16384。 cluster_slots_ok: 状态正常的哈希槽数量。 cluster_slots_pfail: 处于“疑似下线”（PFAIL）状态的哈希槽数量。这通常意味着集群内部通信发现某些节点响应迟钝，但尚未确认为故障。 cluster_slots_fail: 处于“确认为下线”（FAIL）状态的哈希槽数量。如果此值大于 0，cluster_state 通常会变为 fail。 2. 节点与网络指标 cluster_known_nodes: 集群中已知的节点总数（包括主节点和从节点）。 cluster_size: 集群中包含哈希槽的主节点数量。 注意：如果某个主节点没有分配任何槽位，它不会计入此项。 cluster_current_epoch: 集群的当前纪元（Current Epoch）。这是一个自增的版本号，用于在集群发生故障转移（failover）时解决冲突，确保配置的一致性。 cluster_my_epoch: 当前正在操作的节点的纪元。 cluster_stats_messages_sent: 该节点发送的集群消息总数（如 PING, PONG, MEET 等）。 cluster_stats_messages_received: 该节点接收到的集群消息总数。 3. 性能与运维指标（新版本 Redis） 在较新版本的 Redis 中，你可能还会看到以下指标： total_cluster_links_buffer_limit_exceeded: 超过集群链路缓冲区限制的次数。1. info memory 查看内存情况
以下是该输出中各核心指标的分类详细说明： 1. 核心消耗指标 (基础数据) used_memory: Redis 分配器分配的内存总量（单位：字节）。这是 Redis 存储实际数据占用的内存。 used_memory_human: 以更易读的格式（如 MB, GB）显示 used_memory。 used_memory_rss: 从操作系统的角度看，Redis 进程占用的物理内存（Resident Set Size）。它包括了碎片、堆栈消耗等。 used_memory_peak: Redis 历史上的内存消耗峰值。 used_memory_lua: Lua 引擎消耗的内存。 2. 内存效率指标 (关键性能) mem_fragmentation_ratio: 内存碎片率。公式：$used_memory_rss / used_memory 1.0~1.5：属于正常范围。> 1.5：说明碎片严重，Redis 占用了物理内存但没怎么存数据，可能需要开启 activedefrag（自动清理碎片）。< 1.0：说明物理内存不足，Redis 正在使用 Swap（虚拟内存），这会导致性能急剧下降。 mem_allocator: Redis 使用的内存分配器（通常是 jemalloc）。 3. 内存细分指标 (进阶排查) used_memory_overhead: Redis 为了维护数据集所需要的额外开销（包括主从复制积压缓冲区、查询缓冲区等）。 used_memory_dataset: 实际业务数据占用的内存大小（$used_memory -used_memory_overhead）。 重点： redis的内存中除了实际业务数据占用内存，还有额外的开销占用内存，即与各个客户端的连接，每个连接中包括输入缓冲区和输出缓冲区等占用一些内存。 所以在redis内存中，分为 连接所占内存 和 数据所占内存 ，在排查内存占用率高的时候，一定要看是哪部分所导致，如果是连接所占内存较高则检查各个连接的输入输出缓冲区，可以使用client list来列出所有连接或top20连接， 如果是数据所占内存较高则需要列出bigkey来查看相关信息。 used_memory_dataset_perc: 净数据占总消耗内存的百分比。这个就是关键参数，查看真实数据所占用内存的占比。 maxmemory: 配置的 Redis 最大内存限制（0 表示不限制）。 maxmemory_policy: 当内存达到 maxmemory 时的淘汰策略（如 allkeys-lru, volatile-lru 等）。 4. 重点关注：缓冲区 (Buffers)在高并发或大数据量同步时，这些指标非常关键： mem_clients_slaves: 主从复制过程中，主节点为从节点提供的 输出缓冲区 消耗。 mem_clients_normal: 普通客户端连接消耗的内存。如果连接数过多且缓冲区未限制，这里会暴涨。 mem_aof_buffer: AOF 重写缓冲区消耗的内存。1.1内存字段逐个解释
┌─────────────────────────────────────────────────────────────┐ │ 单个连接的内存组成 │ ├──────────────┬──────────────────────────────────────────────┤ │ qbuf │ 已使用的输入缓冲区 │ │ │ 客户端发来但还没处理完的数据 │ │ │ 默认上限 1GB，你的问题可能在这里 │ ├──────────────┼──────────────────────────────────────────────┤ │ qbuf-free │ 输入缓冲区剩余空间 │ │ │ qbuf + qbuf-free = 当前分配的总 buffer 大小 │ ├──────────────┼──────────────────────────────────────────────┤ │ argv-mem │ 当前正在解析的命令参数占用的内存 │ │ │ 命令执行完就释放，通常很小 │ ├──────────────┼──────────────────────────────────────────────┤ │ multi-mem │ MULTI/EXEC 事务队列占用的内存 │ │ │ 非事务连接为 0 │ ├──────────────┼──────────────────────────────────────────────┤ │ rbs │ 读取缓冲区大小（Read Buffer Size） │ │ │ 固定 16KB，用于读取客户端数据 │ ├──────────────┼──────────────────────────────────────────────┤ │ rbp │ 读取缓冲区已使用（Read Buffer Peak） │ ├──────────────┼──────────────────────────────────────────────┤ │ obl │ 输出缓冲区已写入字节数 │ │ │ （output buffer length） │ ├──────────────┼──────────────────────────────────────────────┤ │ oll │ 输出缓冲区链表长度 │ │ │ （output list length）大于0说明回复堆积 │ ├──────────────┼──────────────────────────────────────────────┤ │ omem │ 输出缓冲区占用内存 │ │ │ 你的 omem=0，说明 Redis 没有堆积要回复的数据 │ ├──────────────┼──────────────────────────────────────────────────┤ │ tot-mem │ 这个连接占用的总内存 ★ │ │ │ = qbuf + qbuf-free + argv-mem │ │ │ + multi-mem + rbs + omem + 固定开销 │ └──────────────┴──────────────────────────────────────────────┘重点：
redis的内存中除了实际业务数据占用内存，还有额外的开销占用内存，即与各个客户端的连接，每个连接中包括输入缓冲区和输出缓冲区等占用一些内存。
所以在redis内存中，分为 连接所占内存 和 数据所占内存 ，在排查内存占用率高的时候，一定要看是哪部分所导致，如果是连接所占内存较高则检查各个连接的输入输出缓冲区，可以使用client list来列出所有连接或top20连接， 如果是数据所占内存较高则需要列出bigkey来查看相关信息。
通过读取tmp2.txt（里面存储这个client list信息），获取top20的连接所占用的内存数
import json def analyze_redis_clients(file_path): try: with open(file_path,"r",encoding="utf-8") as f: data = json.load(f) if not isinstance(data,list): print("not json") return data.sort(key=lambda x: int(x.get("tot-mem",x.get("omem",0))),reverse=True) print(f"{'rank':<6}{'mem(MB)':<18}{'client':<25}{'flags':<15}{'cmd':<10}{'qbuf':<18}{'omem':<18}") print("-" * 100) for i, client in enumerate(data[:20],1): mem_bytes = int(client.get("tot-mem",client.get("omem",0))) mem_mb = mem_bytes / 1024 / 1024 addr = client.get("addr","not know") flags = client.get("flags","N") cmd = client.get("cmd","not cmd") qbuf = client.get("qbuf",0) omem = client.get("omem",0) print(f"{i:<8}{mem_mb:<18.2f}{addr:<25}{flags:<15}{cmd:<10}{qbuf:<18}{omem:<18}") except Exception as e: print(f"error: {e}") if __name__ == "__main__": analyze_redis_clients("tmp2.txt")2. client list 查看连接情况
这是一个内容非常丰富的指标集，通过它可以精准定位“谁在占用连接”、“谁在阻塞命令”以及“谁在消耗内存”。1. 客户端身份与网络指标 id: 客户端的唯一 64 位整数 ID。 addr: 客户端的 IP 地址和端口号（IP:Port）。 fd: 套接字文件描述符。 name: 客户端名称。默认通过 CLIENT SETNAME 设置，默认为空，建议给重要的业务连接起名以便排查。age: 连接已存在的总时长（单位：秒）。 idle: 连接自最近一次执行命令以来的空闲时间（单位：秒）。这是排查“死连接”或“僵尸连接”的关键指标。 2. 状态与标志指标 flags: 客户端状态标志。常见的有：N: 普通客户端。M: 该客户端是主节点。S: 该客户端是从节点。O: 客户端处于监视模式（WATCH）。b: 客户端正被阻塞（如执行 BLPOP 等）。 db: 客户端当前正在使用的数据库索引号。 sub/psub: 客户端订阅的频道（Channel）或模式（Pattern）的数量。 3. 命令执行指标 multi: 事务中已入队的命令数量。如果没有开启事务，则为 -1。 cmd: 客户端最后一次执行的命令名称。 user: 客户端连接所使用的认证用户名（Redis 6.0+ ACL 引入）。 4. 缓冲区与内存指标 (性能调优核心) qbuf: 查询缓冲区（Query Buffer）的大小（字节）。Redis 用来存放客户端发送过来的命令请求。qbuf-free: 查询缓冲区的剩余可用空间（字节）。如果此值为 0，说明缓冲区已满，可能会导致客户端阻塞。 obl: 固定输出缓冲区的大小（字节）。用于存放简单的回复。 oll: 动态输出缓冲区列表（Output List）的长度。当简单缓冲区不够用时（例如 SMEMBERS 返回大量数据），数据会存在这里。 omem: 输出缓冲区占用的总内存大小。如果某个客户端尝试读取海量数据，这个值会飙升，甚至触发 Redis 的 maxmemory 限制导致 OOM。 tot-mem 的详细含义 tot-mem (Total Memory) 代表：Redis 为该特定客户端连接所分配的所有内存总量（单位为字节）。 它是对该客户端消耗内存的“总审计”，涵盖了从接收命令到返回结果的所有环节。 1. 它由哪些部分组成？ tot-mem 并不是一个独立的内存块，它是以下几个指标的总和： 查询缓冲区 (qbuf)：存放客户端发来的、尚未被 Redis 执行的命令。 输出缓冲区 (obl + oll 或统称为 omem)：存放 Redis 执行完命令后，准备发回给客户端的结果数据。 内部协议结构：Redis 跟踪该连接所需的各种 C 语言结构体内存（如 client 结构自身） 5. 常见运维排查场景排查目标关注指标异常表现 找出耗时最长的连接idleidle 值非常大，说明该连接长时间没干活，白白占着连接数。 定位阻塞的原因cmd & flagsflags 包含 b，且 cmd 是 BLPOP, BRPOP, WAIT 等。 内存溢出风险omem如果 omem 达到数十甚至数百 MB，说明该客户端正在接收巨大的结果集，需要优化业务逻辑。 网络延迟排查qbuf如果 qbuf 堆积严重，说明 Redis 处理速度跟不上客户端发送速度，或者是单线程被某个耗时命令（如 KEYS *）卡住了。待补充：
3. monitor
cluster nodes
info clients
config get maxclients
memory stats
