本文介紹了設定應用端串連數的方法。
概述
當應用程式串連PolarDB-X執行個體執行操作時，從PolarDB-X執行個體的角度看，會有如下兩種類型的串連：
前端串連：由應用程式建立的，到PolarDB-X計算節點（CN）中邏輯庫的串連。
後端串連：由PolarDB-X計算節點建立的，到後端資料節點（DN）中物理庫的串連。
其中後端串連由CN管理，通過私人協議實現TCP串連與後端串連解除綁定，對使用者透明。前端串連由使用者建立和管理，本文主要討論前端串連管理的最佳實務。
為了簡化描述，下文中的串連均代指前端串連。
根據QPS和RT計算所需串連數
每秒查詢請求數 (Query Per Second，QPS) 和回應時間 (Response Time，RT) 是衡量應用對資料庫效能需求的基本指標，QPS代表應用並發訪問資料庫的需求，RT代表單條語句的處理效能。RT的高低與執行的SQL是否複雜和掃描的資料量緊密相關，OLTP系統中查詢RT較低，通常以毫秒為單位。
PolarDB-X相容MySQL協議，請求在單個串連上串列執行，不同串連上的請求可以並存執行，由此得到以下公式：
單個串連的QPS上限=1000/RT
說明QPS為每秒查詢請求數，RT的單位是毫秒，1000是1秒換算成毫秒的數。
串連數=應用訪問單個CN的QPS上限/單個串連的QPS上限
按照平均RT為5ms計算，單個串連的QPS上限為200，假設應用預估需要的QPS為5000，則至少需要建立25個串連。
串連數限制
PolarDB-X中前端串連僅與網路模組綁定，理論上串連數僅受限於CN可用的記憶體大小和網路連接數。但在實際的情境中，應用建立串連是為了執行查詢請求，串連數需要與執行線程的數量相匹配才能達到最佳效能。
如上圖所示，應用發起串連請求後，首先由網路模組進行許可權認證，認證通過則建立連線物件。與 MariaDB相似，PolarDB-X計算節點收到查詢請求後，會嘗試從線程池中分配一個執行線程，用於處理查詢請求。單個CN節點預設維護一個1024大小的線程池，如果並發查詢數量超過線程池大小，後續請求會排隊等待。由此可以得到以下公式：
應用訪問單個CN節點的QPS上限=單個串連的QPS上限×MIN(串連數,線程池大小)
應用訪問資料庫的QPS上限=單個串連的QPS上限×MIN(串連數,線程池大小)×CN節點的個數
以下兩個樣本介紹了公式的實際應用：
樣本1
問：查詢的平均RT為10ms，理想情況下2個CN節點能提供多少QPS?
答：平均RT為10ms，則單個串連的QPS上限為1000/10=100。理想情況下（CPU不成為瓶頸），包含2個CN節點的PolarDB-X執行個體預設能夠提供的QPS上限為100×1024×2=204800。這裡需要注意，CN節點能夠同時處理的查詢數量與CN規格和查詢複雜度有關，實際情境下通常不能做到1024個線程完全並行，QPS上限會低於204800。
樣本2
問：在CN規格為16C的PolarDB-X執行個體上壓測，CPU剛好跑滿時，某查詢的平均RT為5ms。 僅考慮CN節點，支撐40w的QPS應當如何選擇執行個體規格和設定應用端串連數量？
答：平均RT為5ms，則單個串連的QPS上限為1000/5=200。應用端串連池大小設定為400000/200=2000可以將額外開銷降到最低。保持單個CN節點上的並行度不超過1024，需要2個16C節點構成的32C的PolarDB-X執行個體。
使用Druid設定資料庫串連池
資料庫連接池是對資料庫連接進行統一管理的技術，主要有以下優勢：
提高系統響應效率：串連的初始化工作完成後，所有請求可以直接利用現有串連，避免了串連初始化和釋放的開銷，提高了系統的響應效率。
資源複用：串連可以重複利用，避免了頻繁建立、釋放串連引入的效能開銷。在減少系統消耗的基礎上，增強了系統的平穩性。
避免串連泄漏：串連池可根據預設的回收策略，強制回收串連，從而避免了串連資源泄漏。
如果是Java程式，推薦使用 Druid 串連池，版本要求1.1.11及以上。
Druid的Spring標準配置如下：
<bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver" />
<!-- 基本屬性 URL、user、password -->
<property name="url" value="jdbc:mysql://ip:port/db?autoReconnect=true&rewriteBatchedStatements=true&socketTimeout=30000&connectTimeout=3000" />
<property name="username" value="root" />
<property name="password" value="123456" />
<!-- 配置初始化大小、最小、最大 -->
<property name="maxActive" value="20" />
<property name="initialSize" value="3" />
<property name="minIdle" value="3" />
<!-- maxWait 擷取串連等待逾時的時間 -->
<property name="maxWait" value="60000" />
<!-- timeBetweenEvictionRunsMillis 間隔多久才進行一次檢測，檢測需要關閉的空閑串連，單位是毫秒 -->
<property name="timeBetweenEvictionRunsMillis" value="60000" />
<!-- minEvictableIdleTimeMillis 一個串連在池中最小閒置時間，單位是毫秒-->
<property name="minEvictableIdleTimeMillis" value="300000" />
<!-- 檢測串連是否可用的 SQL -->
<property name="validationQuery" value="select 'z' from dual" />
<!-- 是否開啟空閑串連檢查 -->
<property name="testWhileIdle" value="true" />
<!-- 是否在擷取串連前檢查串連狀態 -->
<property name="testOnBorrow" value="false" />
<!-- 是否在歸還串連時檢查串連狀態 -->
<property name="testOnReturn" value="false" />
<!-- 是否在固定時間關閉串連。增加此參數可以均衡後端服務節點參數 -->
<property name="phyTimeoutMillis" value="600000" />
<!-- 是否在固定SQL使用次數之後關閉串連，增加此參數可以均衡後端服務節點參數-->
<property name="phyMaxUseCount" value="10000" />
</bean>串連池與負載平衡
串連池模式（TCP長串連）效率更高，但以下情境中對分布式負載平衡不友好，可能導致CN負載不均勻：
突發建立串連，導致分布不均；
如果應用存在突發建立大量串連的情況，負載平衡裝置無法及時重新整理統計資訊，可能出現部分CN上串連較多，結合串連池化，最終導致部分CN壓力高於其他CN，影響系統總體效能。
負載平衡探活異常，導致分布不均
負載平衡通過主動探活來判斷CN節點是否正常，當探活出現偶發異常時，可能導致部分CN上串連較少，結合串連池化，最終導致部分CN壓力低於其他CN，影響系統總體效能。
Druid串連池增加了phyTimeoutMillis/phyMaxUseCount參數，定期（例如執行10000次或者10分鐘）重新整理串連池中的串連，可以在解決上述問題的同時保持效能基本不變，建議預設添加這兩個配置。
應用線程數與串連池
應用程式訪問資料庫的一種常見模式，是在應用程式中建立多個線程，每個線程擷取一個到資料庫的串連並執行查詢。為了減少建立、釋放線程的開銷，通常會使用線程池來管理線程，線程池的一個重要參數是最大線程數，需要根據實際情況調整。
理想情況下，查詢的RT波動不大，可以應用上文介紹的公式，根據RT計算出合理的串連池大小，並按照每個線程一個資料庫連接的思路確定最大線程數。實際情境中，查詢RT受到熱點、鎖、資料扭曲等多種因素的影響，可能出現突發RT增長，甚至部分串連失去響應。如果完全按照理想情況計算串連池和線程池，可能由於部分慢查詢耗盡串連池或線程池，導致應用失去響應，影響關聯絡統。因此，建議按照理想情況的1.5到2倍來設定最大串連數和線程數。