mysql

1. mysql查询突然变的很慢，需要怎么排查

检查查询本身

• 查看SQL查询是否可以优化，比如使用合适的索引、避免全表扫描等。
• 复杂的JOIN操作：确认是否有多个大的表连接，或者是不必要的复杂操作

查看数据库性能

慢查询日志：启用并查看慢查询日志（slow_query_log）。查看最近哪些查询执行时间较长。

检查系统负载

系统资源：查看CPU、内存、磁盘IO、网络等资源是否有瓶颈，可以通过 top 或 htop 等工具监控。 磁盘IO：查看磁盘读写是否成为瓶颈。可以用 iostat 或 vmstat 等工具查看磁盘IO情况。

检查锁和并发问题

锁情况：查看是否有锁等待或死锁问题。使用以下SQL语句查看当前的锁状态： 如果有很多线程处于“Locked”状态，可能需要进一步分析锁的来源和解决方法。

网络延迟

如果是远程连接MySQL，确认网络连接是否稳定，延迟是否较高。

redis

1.热key、大key问题

热key问题

• 热key：指被频繁访问的key，可能导致数据库性能下降。

影响：

• CPU 集中在一个 Redis 节点
• QPS 不均匀，集群负载失衡
• 延迟飙升、请求超时
• 导致节点触发 failover

解决方案

• 业务层分流/分桶 将热请求拆成多个 key，提高并发承载。
• 增加缓存层：本地缓存 + Redis 二级缓存，减少对 Redis 的直接访问
• 使用多 Key 拆分读压力，一个热门大 key 分成多个子 key
• Redis Proxy 层热点保护，代理层可识别热点并做降级
• 客户端本地限流 + 降级

大key问题

• 大key：指key对应的值非常大，占用了大量的内存空间。

影响：

• 迁移槽时（CLUSTER ADDSLOTS/MIGRATE）非常慢
• 可能阻塞 Redis 主线程
• 删除时触发阻塞（del O(n) 操作
• 压垮网络带宽
• 读写延迟变大
• Failover 恢复慢

解决方案

• 业务层拆分：将大 key 拆分成多个小 key，每个小 key 只存储一部分数据。
• 分页读取：不使用 hgetall/smembers/zrange，使用scan / 分段取
• 提前限制 value 的大小： 在服务侧做 key 大小限制
• 避免在 Redis 存储日志、消息、长文本

如何发现大key

• Redis的SCAN命令
• redis-cli -h 127.0.0.1 -p 6379 —bigkeys
• 开源工具Redis RDB Tools，分析RDB文件，扫描出Redis大key。

kafka

1.消费堆积如何处理

消息堆积原因

• 生产者短时间内生产大量消息到Topic，消费者无法及时消费。
• 消费者的消费能力不足（消费者并发低、消息处理时间长），导致消费效率低于生产效率。
• 消费者异常（如消费者故障、消费者网络异常等）导致无法消费消息。
• Topic分区设置不合理，或新增分区无消费者消费。
• Topic频繁重分配导致消费效率降低。

解决方法

从消息堆积的原因看，消息堆积问题可以从消费者端、生产者端和服务端三个方面进行处理。

• 消费者端
  • 根据实际业务需求，合理增加消费者个数（消费并发度），确保分区数/消费者数=整数，建议消费者数和分区数保持一致。
  • 提高消费者的消费速度，通过优化消费者处理逻辑（减少复杂计算、第三方接口调用和读库操作），减少消费时间。
  • 增加消费者每次拉取消息的数量：拉取数据/处理时间 >= 生产速度。
• 生产者端
  • 生产消息时，给消息Key加随机后缀，使消息均衡分布到不同分区上。
• 服务端
  • 合理设置Topic的分区数，在不影响业务处理效率的情况下，调大Topic的分区数量。
  • 当服务端出现消息堆积时，对生产者进行熔断，或将生产者的消息转发到其他Topic。