对于一个DBA，客户端连接异常问题可以说是家常便饭的事情，处理多了都想吐。
root cause无疑发生在三个地方，先找自身的原因，依次排查下去：
1）服务器端db的负载，如果负载太高，创建socket太慢引起超时。另外服务器端socket的个数太多，也可以导致创建连接需要很长的时间或者创建连接不成功。
2）网络是够有抖动，包括lvs/twemproxy重启操作。
3）客户端的连接配置参数是否合理，连接池的大小，超时参数大小。还有客户端服务器的状态，负载和tcp连接状况。
下面是近三个工作日碰到的redis/twemproxy连接问题。
1、不合理的jedispool配置，连接池设置的太小
错误信息：
daemon prio=10 tid=0x00002ab367888000 nid=0x1881 in Object.wait() [0x00002ab3e5754000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1315) at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:557) ...
监控的连接数显示：redis的连接数每秒维持在200+个, 比较正常。
jedispool配置：最大允许创建的连接个数为50个，相比连接数，这个值偏小。
解决方法：
1）增大连接池的大小，但是不要太大，避免客户端和服务器端维持大量的空闲了连接。
2）可以设置minIdle和EvictIdle的时间，加快获取连接对象和释放空闲的连接。
3）设置testOnBorrow=True参数，每次get连接时候进行连接有效性检测。
ps：jedis/jedispool的很多默认参数配置并不适合用，需要按照应用需求何求调整。
2、没有返回连接对象
错误信息：
an error occurred when executing function getJedis(): Could not get a resource from the pool
jedispool连接池的使用方式:
Jedis jedis = JedisFactory.jedisPool.getResource(); try{
jedis.set("key","val");}finally {
JedisFactory.jedisPool.returnResource(jedis); }
连接使用完之后，需要归还到连接池中。
After each Jedis method call, return the resource pool. Your app has probably used all the threads and waits for some to be dropped.This may cause behavior you're explaining and the app is probably blocked.
3、容错处理
网络链路并不能保证绝对的稳定，db服务也不能提供99.999%的可靠服务。代码需要能够捕获异常和异常处理，而不是应用程序报错。
原创文章，作者：s19930811，如若转载，请注明出处：http://www.178linux.com/2488
