前言
这个还是比较常见的，也就是比较对开发有用的部分。
正文
1.无法从连接池获取到连接
JedisPool中的Jedis对象个数是有限的，默认是8个。这里假设使用的默 认配置，如果有8个Jedis对象被占用，并且没有归还，此时调用者还要从 JedisPool中借用Jedis，就需要进行等待（例如设置了maxWaitMillis>0），如 果在maxWaitMillis时间内仍然无法获取到Jedis对象就会抛出如下异常：
redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool … Caused by: java.util.NoSuchElementException: Timeout waiting for idle object at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool. java:449)
还有一种情况，就是设置了blockWhenExhausted=false，那么调用者发现 池子中没有资源时，会立即抛出异常不进行等待，下面的异常就是 blockWhenExhausted=false时的效果：
redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool … Caused by: java.util.NoSuchElementException: Pool exhausted at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool. java:464)
可能的原因:
客户端:
1. 客户端：高并发下连接池设置过小，出现供不应求，所以会出现上面 的错误，但是正常情况下只要比默认的最大连接数（8个）多一些即可，因 为正常情况下JedisPool以及Jedis的处理效率足够高。
2. 客户端：没有正确使用连接池，比如没有进行释放
3. 客户端：存在慢查询操作，这些慢查询持有的Jedis对象归还速度会比 较慢，造成池子满了。
服务端:
服务端：客户端是正常的，但是Redis服务端由于一些原因造成了客户 端命令执行过程的阻塞，也会使得客户端抛出这种异常。
2.客户端读写超时
造成该异常的原因也有以下几种：
·读写超时间设置得过短。
·命令本身就比较慢。
·客户端与服务端网络不正常。
·Redis自身发生阻塞。
- 客户端连接超时
-1. 连接超时设置得过短
-2. Redis发生阻塞，造成tcp-backlog已满，造成新的连接失败。
-3. 客户端与服务端网络不正常。
- 客户端缓冲区异常
造成这个异常的原因可能有如下几种：
1）输出缓冲区满。例如将普通客户端的输出缓冲区设置为1M,如果使用get命令获取一个bigkey（例如3M），就会出现这个异常。
2）长时间闲置连接被服务端主动断开
- 不正常并发读写：Jedis对象同时被多个线程并发操作，可能会出现 上述异常
5.Lua脚本正在执行
如果Redis当前正在执行Lua脚本，并且超过了lua-time-limit，此时Jedis调用Redis时，会收到下面的异常。
这个时候使用kill script
- Redis正在加载持久化文件
Jedis调用Redis时，如果Redis正在加载持久化文件
- Redis使用的内存超过maxmemory配置
Jedis执行写操作时，如果Redis的使用内存大于maxmemory的设置，会 收到下面的异常，此时应该调整maxmemory并找到造成内存增长的原因
- 客户端连接数过大
如果客户端连接数超过了maxclients，新申请的连接就会出现如下异常
解决方案:
客户端：如果maxclients参数不是很小的话，应用方的客户端连接数基 本不会超过maxclients，通常来看是由于应用方对于Redis客户端使用不当造 成的。此时如果应用方是分布式结构的话，可以通过下线部分应用节点（例 如占用连接较多的节点），使得Redis的连接数先降下来。从而让绝大部分 节点可以正常运行，此时再通过查找程序bug或者调整maxclients进行问题的修复
服务端: 如果此时客户端无法处理，而当前Redis为高可用模式（例如 Redis Sentinel和Redis Cluster），可以考虑将当前Redis做故障转移。
结
下一节redis 常见案例分析。