问题索引
如何监控实例的运行状态？
分布式缓存数据库提供30余项监控指标，最小采集粒度为5秒，覆盖以下维度：
资源监控：CPU 使用率、内存使用率、连接数使用率、带宽使用率。
性能监控：QPS（每秒查询数）、命令执行延迟、慢查询数量。
流量监控：入流量、出流量、每秒读写次数。
键值监控：Key 总数、过期 Key 数量、淘汰 Key 数量。
同时支持配置告警策略，当指标达到阈值时自动通过短信、邮件或微信推送通知。建议至少配置以下告警：内存使用率 > 80%、CPU 使用率 > 90%、连接数使用率 > 80%。
此外，DBbrain 智能诊断功能可自动发现大 Key、热 Key 等性能瓶颈，并提供优化建议。
实例 CPU 使用率达到100%怎么办？
CPU 使用率持续飙高是用户最常遇到的性能问题之一，通常由以下原因引起：
高复杂度命令
执行时间复杂度较高的命令（如 KEYS *、SORT、SUNION、大集合的 SMEMBERS）会长时间占用 CPU。建议通过控制台的慢查询日志排查耗时命令，替换为低复杂度方案：
用 SCAN 替代 KEYS * 进行遍历。
用 SSCAN 替代大集合的 SMEMBERS。
避免对超大集合执行 SORT，改为业务层排序。
热 Key 集中访问
大量请求集中访问少数 Key（热 Key），导致单个数据节点 CPU 过载。可通过 DBbrain 的热 Key 分析功能定位热 Key，处理方式包括：
对热 Key 进行本地缓存（Local Cache），降低对 Redis 的访问频率。
将热 Key 拆分为多个子 Key，分散到不同节点。
集群架构下，开启读写分离将读请求分发至从节点。
短时大量 Key 集中过期
当大量 Key 在同一时间集中过期时，Redis 的过期清理机制会消耗额外 CPU 资源。建议为 Key 的过期时间添加随机偏移量（如 TTL + random(0, 300)），避免集中过期。
连接数过多
过高的客户端连接数也会增加 CPU 开销。通过控制台监控连接数使用率，若连接数异常偏高，检查客户端是否使用连接池、是否存在连接泄漏。
排查建议：
1. 在控制台查看 CPU 使用率监控曲线，确认飙高时间段。
2. 查看该时段的慢查询日志，定位耗时命令。
3. 使用 DBbrain 的智能诊断功能，系统自动分析 CPU 异常原因并给出优化建议。
实例数据被误删后如何恢复？
若实例数据被误删（如误执行 FLUSHALL 或 DEL 命令），可通过以下方式恢复：
1. 从备份恢复：在控制台的备份列表中，选择误删前的备份集，将数据恢复到一个新实例中。确认数据完整后，可将应用切换至新实例。
2. 回档恢复（如已开启）：若开启了数据回档功能，可将实例数据回档至指定时间点，恢复精度为秒级。
预防建议：
在控制台禁用 FLUSHALL、FLUSHDB 等高危命令。
配置多账号权限控制，限制普通业务账号的命令执行范围。
确保自动备份策略正常运行，关键变更前手动触发一次备份。
如何获取客户端连接信息和统计数据？
通过 CLIENT LIST 命令可以查看所有连接到实例的客户端信息和统计数据，常用于排查连接泄漏和业务下线前的连接确认。返回的关键字段包括：
|
id | 唯一的64位客户端 ID |
addr | 客户端的地址和端口 |
name | 客户端通过 CLIENT SETNAME 设置的名称 |
age | 以秒计算的已连接时长 |
idle | 以秒计算的空闲时长 |
cmd | 最近一次执行的命令 |
说明：
在高负载和大规模部署环境下，CLIENT LIST 命令可能对特定分片造成较大内存压力，建议在业务低峰期执行。
从节点与主节点数据不同步怎么办？
由于 Redis 采用异步复制技术，从节点的数据更新可能略滞后于主节点，这是正常现象。若延迟持续较大，可能原因包括：
主节点的 I/O 写入量超过了从节点同步的速度。
主节点和从节点之间存在网络延迟。
建议通过以下方式排查：
1. 在控制台查看主从同步延迟监控指标。
2. 检查是否存在大 Key 频繁写入，导致同步缓冲区溢出。
3. 确认主从节点的网络带宽是否充足。
若同步延迟持续过大，可在控制台执行主从切换或重启从节点来恢复同步。
慢查询日志和 Proxy 慢日志有什么区别？
分布式缓存数据库提供两层慢日志：Proxy 层慢日志和 Redis 引擎层慢查询日志，两者记录的维度不同，排查问题时需结合使用。具体信息，请参见 慢查询。 |
记录位置 | Redis 数据节点 | Proxy 代理层 |
计时范围 | 仅命令执行耗时 | 包含排队等待 + 网络转发 + 命令执行的全链路耗时 |
适用场景 | 定位单个慢命令 | 定位全链路延迟问题 |
常见排查场景：
Proxy 慢日志有记录，但 Redis 引擎慢查询无记录：说明延迟发生在排队或网络层，可能是连接数过高或带宽不足导致请求排队。
两层都有记录：说明命令本身执行耗时过长，需优化命令复杂度或处理大 Key。
Redis 引擎慢查询有记录，但 Proxy 慢日志无记录：一般不会出现此情况，若出现可联系技术支持。
主从节点内存使用率不一致怎么办？
主从节点出现内存使用率差异是较常见的现象，常见原因和处理方式如下：
输出缓冲区（output buffer）占用
从节点在同步全量数据或客户端读取大量数据时，输出缓冲区会临时占用额外内存。这属于正常行为，同步完成后缓冲区会释放。
过期 Key 的惰性删除
Redis 的过期 Key 删除采用"惰性删除 + 定期扫描"机制。从节点上的过期 Key 必须等待主节点发送 DEL 指令才会删除，因此从节点可能暂时持有已过期但未被清理的 Key，导致内存偏高。
数据结构碎片化
主从节点的内存碎片率可能不同。若从节点碎片率明显高于主节点，可尝试在控制台执行内存碎片整理（activedefrag 参数）。
处理建议
1. 在控制台对比主从节点的内存使用率和碎片率监控。
2. 若差异在10% 以内且趋于稳定，属于正常范围，无需处理。
3. 若差异持续扩大，检查是否有大量 Key 集中过期或存在大 Key 写入。
4. 必要时可执行主从切换或重启从节点来重新同步数据。
实例发生主备倒换是什么原因？对业务有什么影响？
主备倒换（也称主从切换、HA 切换）是指实例的主节点因故障或运维操作而切换到从节点继续提供服务。这是分布式缓存数据库的高可用保障机制，确保实例在主节点异常时自动恢复服务。
触发主备倒换的常见原因
|
主节点故障 | 主节点进程异常退出、宕机或心跳超时，系统自动触发切换 |
运维操作 | 版本升级、参数变更（部分参数需重启生效）、扩缩容、跨可用区迁移 |
手动触发 | 用户在控制台手动执行主从切换（用于容灾演练或主动迁移） |
资源异常 | 主节点内存或 CPU 使用率过高，触发系统保护性切换 |
对业务的影响
连接闪断：切换过程中会出现秒级的连接中断，客户端会收到连接断开或超时错误。
短时只读：切换过程中可能有最长1分钟的只读状态（等待数据同步完成）。
数据一致性：计划内切换（版本升级、扩缩容等运维操作）会先完成全量和增量数据同步再执行切换，不会导致数据丢失；仅在非计划故障切换（主节点宕机）时，由于 Redis 采用异步复制，尚未同步到从节点的少量写入可能丢失。
业务适配建议
1. 客户端配置自动重连机制，设置合理的重试策略（如重试3次，间隔200ms）。
2. 对写入操作做好幂等设计，避免重试导致数据重复。
3. 通过控制台订阅实例事件告警，及时获知主备切换通知。
4. 使用连接池并设置心跳检测，确保连接断开后能快速恢复。
带宽使用率超过100%是怎么回事？
在控制台监控中，带宽使用率有时会显示超过100%，这并非系统异常，而是由统计口径导致的正常现象。
原因说明
分布式缓存数据库的带宽使用率统计包含两部分流量：
业务流量：客户端读写产生的入流量和出流量。
主从同步流量：主节点向从节点同步数据产生的内部流量。
控制台展示的带宽限速阈值仅针对业务流量，但监控曲线中可能累加了主从同步流量，因此在主从全量同步或大量写入场景下，监控值可能超过100%。
带宽超限后的影响
当业务流量确实超过实例的带宽限制时，会触发流控机制：
入方向超限：客户端写入请求会被限速，表现为响应延迟升高或超时。
出方向超限：客户端读取请求被限速，大 Value 的读取可能超时。
处理方式
1. 在控制台查看入带宽和出带宽的分别监控，确认是哪个方向超限。
2. 排查是否有大 Key 读写导致瞬时带宽飙高。
3. 若业务带宽需求确实超出当前规格限制，可在控制台调整带宽（目前免费）或升级实例规格。
4. 集群架构可通过增加分片分散流量。
集群架构下出现数据倾斜怎么办？
数据倾斜是指集群各分片之间的内存使用量或请求量分布不均匀，导致个别分片负载过高，而其他分片资源空闲。
判断数据倾斜
在控制台的节点管理页面，查看各分片的内存使用率和 QPS：
内存倾斜：某个分片内存使用率明显高于其他分片（如高出20%以上）。
请求倾斜：某个分片的 QPS 远高于其他分片。
常见原因
|
大 Key 集中 | 多个大 Key 通过 Hash 算法被分配到同一分片 |
Hash Tag 使用不当 | 业务使用 {tag} 强制将大量 Key 路由到同一 Slot |
热 Key | 热 Key 集中在某一分片，导致请求倾斜 |
Slot 分布不均 | 少数场景下 Slot 数据量天然不均 |
处理方法
1. 定位倾斜分片：通过控制台节点监控，找到内存或 QPS 偏高的分片。
2. 排查大 Key：对倾斜分片执行大 Key 分析，拆分或清理大 Key。
3. 优化 Hash Tag：避免将大量无关 Key 使用相同 Hash Tag 强制路由到同一 Slot。
4. 分散热 Key：通过添加随机后缀拆分热 Key 到不同分片。
5. 扩容分片：增加分片数量后系统会自动进行 Slot 重分布，改善数据均衡。
监控数据出现毛刺或突变如何排查？
监控曲线出现突增突降（毛刺），通常由以下原因引起：
内存使用率突增
大量新 Key 写入或大 Key 创建。
主从全量同步时临时缓冲区占用。
大量 Key 集中过期后被定期扫描清理（表现为先升后降）。
CPU 使用率突增
执行了高复杂度命令（可通过慢查询日志确认）。
大量 Key 集中过期触发清理。
短时高并发请求。
连接数突增
业务侧发布上线，大量客户端同时建连。
连接池配置不当，客户端频繁创建新连接。
网络抖动导致旧连接断开后重连。
QPS 突降
客户端侧网络异常或服务中断。
实例触发流控（带宽或连接数超限）。
主备倒换期间短暂不可用。
排查方法
1. 确定毛刺出现的精确时间段（建议查看5秒粒度监控）。
2. 对照该时段的慢查询日志、事件告警、运维操作记录。
3. 检查客户端日志是否有对应的异常报错。
4. 若毛刺周期性出现，排查是否有定时任务（如全量扫描、数据同步）触发。