https://blog.csdn.net/crisis_hiding/article/details/81490158
生产环境长时间的运行后，经常会有接口返回数据失败的情况，或者是从监控上发现数据库压力某一时间暴增。查看客户端日志发现这样的错误：
redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
从错误日志看，是提示无法获取连接。有两种情况：
1、客户端的连接池满了，无法创建新的连接
检查客户端连接最大限制maxActive是否足够
2、redis服务端连接溢出，无法分配新的连接
检查服务端tcp连接：netstat -nat|grep -i "6379"|wc -l
检查服务端连接是否达到最大值：查看服务端支持的最大连接：CONFIG GET maxclients，查看当前服务端建立的 连接：connected_clients
通过上述检查后，发现redis服务端connected_clients连接数持续过高，经常在最大值徘徊。但是结合客户端配置的最大连接配置maxActive，计算出所有客户端连接占满的情况下最大的连接数也达不到connected_clients的连接数。
执行client list命令，发现大量的client的idle时间特别长：
正常的client连接，在持续使用的情况下，是不可能空闲这么长时间，连接长时间空闲，客户端也会关闭连接。
查看redis服务端下面两项配置：
timeout：client连接空闲多久会被关闭（这个配置容易被误导为：连接超时和操作执行超时）
tcp-keepalive：redis服务端主动向空闲的客户端发起ack请求，以判断连接是否有效
检查上述配置发现 timeout和tcp-keepalive均未启用（均为0），这种情况下，redis服务端没有有效的机制来确保服务端已经建立的连接是否已经失效。当服务器和客户端网络出现闪断，导致tcp连接中断，这种情况下的client将会一直被redis服务端所持有，就会出现上面我们看到的idle时间特长的client连接。
接下来设置timeout和tcp-keepalive来清理失效的连接。
突然间服务不能访问，返回错误：
redis.clients.jedis.exceptions.JedisDataException: MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.
从错误提示，可以看出是向磁盘保存数据失败。引起这个问题的原因一般是内存不足，但是生产环境我们一般都会为系统分配足够的内存运行，而且查看内存情况也显示还有可用内存。
查看redis日志，发现有这个错误：Can’t save in background: fork: Cannot allocate memory
redis在保存内存的数据到磁盘时，为了防止主进程假死，会Fork一个子进程来完成这个保存操作。但是这个Fork的子进程会需要分配和主进程相同的内存，这时候就相当于需要的内存double了，如果这时候可用内存不足以分配需要的内存，将会导致Fock子进程失败而无法保存数据到磁盘。
修改linux内核参数：vm.overcommit_memory=1。至此，问题解决。
overcommit_memory有三种取值：0， 1， 2
0：:检查是否有足够的可用内存供进程使用；有则允许申请，否则，内存申请失败，并把错误返回给应用进程；
1：表示内核允许分配所有的物理内存，而不管当前的内存状态如何；
2：表示内核允许分配超过所有物理内存和交换空间总和的内存。
优化总结
1、结合实际使用场景，考虑是否需要用到redis的持久化，如果单纯用来做应用层的缓存（在缓存未命中的情况下访问数据库），可以关闭持久化。
2、缓存模式下，尽量为每块缓存设置时效性，避免冷数据长时间占用资源。
3、生产环境中尽量避免使用keys操作，由于redis是单线程模式，大量的keys操作会阻塞其他的命令执行。
4、设置合理的内存回收策略，保证内存可用性的同时能适当的提供缓存的命中率。
5、提前计算出系统可能会用的内存大小，合理的分配内存。需要注意在开启持久化模式下，需要预留更多的内存提供给Fock的子进程做数据磁盘flush操作。