應當取（並發線程數+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的超時
