1、DB端连接数过大的问题

在服务器端我们经常可以看到db上存在大量的tcp连接，而通过ss或者netstat命令查看，发现大量的连接处于established状态。

进一步通过redis的client list命令发现，很多连接的idle时间都很大，这意味着很多连接长时间没有活动和传出数据。

服务器端维持很大的连接数，一方面需要消耗很多的进程资源，对于单进程的redis或者twemproxy，需要占用进程的调度时间；

另外，过多的空闲连接数对于db的容量评估也带来错误性的判断。

2、redis/twemproxy和mc的connection timeout

目前在服务器端都没有设置任何连接超时的参数，不用担心服务器端主动断开连接。

因而需要客户端程序主动的释放不再使用的连接和连接池中长时间空闲的连接。

3、redis/mc最大连接数

redis配置中最大允许1w个连接。

mc配置中最大允许接受65535个连接。

当应用程序中的并发连接数超过redis/mc服务器端的允许的连接数时，对redis/mc进行扩容为最佳方案，保证db能够提供高性能服务。

4、客户端连接池的配置要点。

1） 连接池的大小。单个应用程序中，接口的并发的连接数的1.5倍足够满足需求。

2） 保持一定的空闲连接数，这样可以保证客户端可快速的获取连接对象。

3） 合理设置空闲接的回收时间。避免客户端维持大量的空闲连接。

4） 定时检查长连接对象的有效性。主要是防止网络抖动或者db端出现异常时主动关闭连接。

5、JedisPool Config推荐的设置。

jedipool连接池配置推荐的设置 适合v2.5+版本：
// 设置最大连接数，（根据并发请求合理设置）。
config.setMaxTotal(100);
// 多长空闲时间之后回收空闲连接
setMinEvictableIdleTimeMillis(60000);
// 设置最小空闲连接数或者说初始化连接数 （建议和最大空闲连接数相同）
config.setMinIdle(20);
// 设置最大空闲连接数（根据并发请求合理设置）
config.setMaxIdle(20);
// 设置最大等待时间 （根据业务需求调整）
config.setMaxWaitMillis(3000);
// 跟验证有关
config.setTestOnBorrow(true);
// 跟验证有关
config.setTestOnReturn(false);
// 启动空闲连接的测试
config.setTestWhileIdle(false);