好烦,一封报警邮件,大量服务节点Redis响应超时,又得要捉“虫”

3、网络问题

网络问题，是一个普遍的影响因素。

1）网络资源耗尽

简单来说，就是带宽不够了，整个属于基础资源架构的问题了，对网络资源的预估不足，跨机房，异地部署等都会成为诱因。

2）连接数用完了

一个客户端连接对应着一个TCP连接，一个TCP连接在LINUX系统内对应着一个文件句柄，系统级别连接句柄用完了，也就无法再进行连接了。

查看当前系统限制：ulimit -n

设置：ulimit -n {num}

3）端口TCP backlog队列满了

linux系统对于每个端口使用backlog保存每一个TCP连接。

redis配置：tcp_backlog 默认511

![好烦,一封报警邮件,大量

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

服务节点Redis响应超时,又得要捉“虫”](https://img-blog.csdnimg.cn/img_convert/f31f116c029608f38435e26d56ad9137.png)

高并发情境下，可以适当调整此配置，但需要注意的是，同时要调整系统相关设置。

系统修改命令：echo {num}>/proc/sys/net/core/somaxconn

查看因为队列溢出导致的连接绝句：netstat -s | grep overflowed

4）网络延迟

网络质量问题，可以使用 redis-cli 进行网络状况的测试：

延迟测试：redis-cli -h {host} -p {port} --latency

采样延迟测试：redis-cli -h {host} -p {port} --latency-history 默认15s一次

图形线上测试结果：redis-cli -h {host} -p {port} --latency-dist

4）网卡软中断

单个网卡队列只能使用单个CPU资源问题。

二、redis 服务使用问题

==============

1、慢查询

如果你的查询总是慢查询，那么必然你的使用存在不合理。

1）你的key规划是否合理

太长或太短都是不建议的，key需要设置的简短而有意义。

2）值类型选择是否合理。

hash还是string，set还是zset，避免大对象存储。

线上可以通过scan命令进行大对象发现治理。

3）是否能够批查询

get 还是 mget；是否应该使用pipeline。

4）禁止线上大数据量操作

2、redis 服务运行状况

查看redis服务运行状况：redis-cli -h {host} -p {port} --stat

keys：当前key总数；mem：内存使用；clients：当前连接client数；blocked：阻塞数；requests：累计请求数；connections：累计连接数

3、持久化操作影响

1）fork的进程影响

redis 进行持久化操作需要fork出子进程。fork的进程本身如果时间过长，则会产生一定的影响。

查看命令最近一次fork耗时：info stats

单位微妙，确保不要超过1s。

2）AOF刷盘阻塞
AOF持久化开启，后台每秒进行AOF文件刷盘操作，系统fsync操作将AOF文件同步到硬盘，如果主线程发现距离上一次成功fsync超过2s，则会阻塞后台线程等待fsync完成以保障数据安全性。
3）THP问题
关于redis内存分析，内存优化 中我们讲过透明大页问题，linux系统的写时复制机制会使得每次写操作引起的页复制由4KB提升至2M从而导致写慢查询。如果慢查询堆积必然导致后续连接问题。