应当取（并发线程数+1）*保险系数，遵循以下原则：（为什么+1:线程池的取值（三）阻塞队列边界取值+1，还需要全面了解线程池源码）
1 根据 组合设计qps ，避免过小的连接池压缩上游线程池并发数，进而影响整理吞吐量，只有当n2=n1时，整体吞吐量理论最大
2 也要从限流角度限流怎么做（战略），避免过大的并发数导致下游redis服务器吞吐量至下滑段
像这种问题不是泄露就是并发没给够，下面我们讨论2个案例
案例一：一次redis连接池连接数配置过少引起的性能问题（jstack确认许多线程等待池资源）
设x为上游业务qps，y为redis单连接qps，根据 组合设计qps 组合qps公式
1/150=1/8y + 1/x
1/450=1/100y + 1/x
解出：
y=25.875 （8个redis io，5ms一个，40ms单线程响应时间，single qps=1/0.04=25）
x=537.6
修改前：上游538qps，redis 200qps，总150qps
异步情况下，上游qps到达538，则下游最大生产速度就是538，这种情况下，会压垮200qps的redis层
同步情况下，上游qps达到538，只有在下游执行时间为0的情况下（异步），下游最大生产速度才是538；因为由于同步，下游的执行会拖慢上游的执行，从而带慢其各single线程的qps，使总qps（即总最大生产速度）降到150
修改后：上游538qps，redis 2500qps，总450qps
同步情况下，上游每秒最多生产538到下游（即下游最大生产速度为538），导致下游redis 2500的qps无法充分利用，故导致总qps只有450，此时瓶颈在上游业务代码
案例二：服务运行一段时间，redis缓存就不可用，原来是这个锅！
“每秒请求数=（299/56-49）=42 。omygad的，连接池只有6个可用连接完全不够用。这回真的石锤了。”
总生产速度 42，上游qps未知，redis2次io，算100ms，单连接吞吐量10，6个连接60
设总qps 42，下游redis 60，上游业务qps应>= 1/(0.0238-0.0167)=140.8，意思是只要业务代码qps>=140.8，整体就能扛住42的总请求生产速度
由于总生产速度42，设并发数为最大值42，redis池等待时间=n1/n2*t2-t2=42/6*100ms-100ms=600ms，理应不会达到1.5s的超时
