Redis 经典问题处理-常见面试题

Redis 经典问题处理-常见面试题

Redis 连接数问题

Redis 服务器连接不上，应用程序无法获取连接。可能是以下的原因，以及对应解决的方案

1、最大连接数

原因
Redis 服务器默认设置的最大连接数 maxclients 是 10000，但是这个受服务器最大文件数影响，服务器默认最大文件数是 1024，所以 redis 最大连接数为 1024-32=992

解决方案

1. 首先查看当前连接数

    ./redis-cli –h host –p port info clients
   

2. 查看最大连接数

    ./redis-cli –h host –p port config get maxclients
   

3. 如果连接数远远小于最大连接数，就是服务器最大文件数的影响，修改对应的文件

    # 修改 /etc/security/limits.conf，添加下面内容
    *   soft    nofile    65536
    *   hard    nofile    65536
    # 重启服务生效后，使用 ulimit -a 查看
   

2、大量的长连接导致

原因
监控平台查看到 redis 客户端连接数过大，超过最大限制 1W
通过下面命令分析具体的连接信息

./redis-cli –h host –p port client list

如果存在大量的空闲连接，主节点 cmd=null，从节点 cmd=readonly，并且 idle 空闲时长太长，导致连接池维持了太多的连接。

默认情况下，如果客户端空闲了很多秒，Redis 的最新版本不会关闭与客户端的连接：连接将永远保持打开状态。

解决方案

1. 设置 timeout

    ./redis-cli –h host –p port CONFIG SET timeout 30
   

2. 设置 tcp-keepalive

    # 用来定时向client发送tcp_ack包来探测client是否存活的
    ./redis-cli –h host –p port config set tcp-keepalive 300
   

3. 应用程序配置自动释放连接

Redis CPU 问题

在 Redis 官方文档 reids面试题 有这么一句话：CPU 基本不可能成为的 Redis 的瓶颈，通常 Redis 受限于内存或网络

然而在实际生产环境中，还是会遇到 redis cpu 占用过高的场景

1、高消耗命令导致 CPU 使用率过高

原因
高消耗命令 (慢查询 或 value 值过大) ：即时间复杂度为 O(N) 或更高的命令。通常情况下，命令的时间复杂度越高，在执行时会消耗较多的资源，从而导致 CPU 使用率上升

这是因为 Redis 是用 “单线程-多路复用io模型” 来实现高性能的内存数据服务的，这种机制避免了使用锁，但是同时这种机制在进行 sunion 之类的比较耗时的命令时会使 redis 的并发下降。因为单线程，所以耗时的命令会导致并发下降，读写并发都会下降，从而导致 CPU 使用率上升

解决方案

1. 评估并禁用高风险命令和高消耗命令
2. 优化业务程序，避免频繁执行数据排序操作
3. 调整 redis 架构为读写分离架构，对高消耗命令或应用进行分流

2、连接数过多导致 CPU 使用率过高

参考前面的 Redis 连接数问题

3、数据持久化 AOF

原因
Redis 提供两种持久化方式：RDB (默认) 和 AOF (阿里云默认)

RDB 是 Redis 默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为 dump.rdb。通过配置文件中的 save 参数来定义快照的周期

AOF 持久化(即 Append Only File 持久化)，则是将 Redis 执行的每次写命令记录到单独的日志文件中，当重启 Redis 会重新将持久化的日志中文件恢复数据

在 Redis