原理介紹

Apache ShardingSphere是開源的分布式數據庫增強計算引擎，通過在應用和數據庫之間部署ShardingSphere-Proxy代理，來實現非應用侵入式的分庫分表。

PolarDB多主集群（庫表）通過將不同的邏輯數據庫分散至不同的主節點（RW），來實現讀寫能力水平擴展。

ShardingSphere-Proxy結合PolarDB多主集群（庫表），將數據通過ShardingSphere分散至多個數據庫，再結合PolarDB多主集群（庫表）實現讀寫能力擴展。原理圖如下所示：

• 如果僅使用ShardingSphere，在需要提升數據庫集群讀寫能力時，需要先使用傳統數據庫運維手段進行數據復制和備份恢復，再配合業務系統停寫、規則切換、數據驗證、業務系統恢復等步驟來提升數據庫集群的讀寫能力，其中，數據庫的運維操作尤為復雜耗時。

• 使用PolarDB多主集群（庫表）之后，您可以省去絕大部分手工擴展數據庫集群的工作，您只需要通過控制臺或OpenAPI為PolarDB多主集群（庫表）增加節點，然后在業務低峰期，執行ALTER DATABASE name POLARDB_WRITE_NODE x等操作，即可在數秒內將數據庫集群的讀寫擴展到新增的節點上，大幅減少了數據庫停寫維護的時間，提高了業務系統的SLA。

  PolarDB多主集群（庫表）在執行ALTER DATABASE name POLARDB_WRITE_NODE x切換數據庫所在的主節點時，目標數據庫會有秒級的不可訪問，顯示為查詢阻塞或獲取表全局鎖失敗錯誤。如果能夠在切換節點期間避免訪問該數據庫，或者避免訪問該庫的查詢阻塞過久搶占訪問其他庫的資源，均可以減少切換數據庫所在的RW節點時對業務的影響。

  • 切換節點期間，避免訪問切換中的數據庫。

    ShardingSphere借助注冊中心實現集群管理，在/metadata/${schemeName}/dataSources路徑下，記錄了一個邏輯庫的數據源。ShardingSphere會感知該路徑值的變化，并動態更新和重建相關連接池。通過聯動注冊中心配置變更和PolarDB進行多主集群（庫表）的彈性擴容，先禁用指定的數據源，再執行ALTER DATABASE，最后再恢復數據源。您可以將業務影響控制在預期范圍（只影響與需要遷移的數據庫相關的查詢）的情況下獲得接近線性的數據庫讀寫能力擴展。

  • 切換節點期間，避免訪問切換中的數據庫時查詢阻塞過久。

    使用JDBC URL配置ShardingSphere的數據源，您可以在URL中配置connectTimeout和socketTimeout參數。通過將這兩個超時時長配置為500ms，也可以使訪問到正在切換的數據庫的查詢，盡可能快地超時失敗，從而釋放線程和連接資源去訪問其他數據庫。

性能測試

測試環境

PolarDB多主集群（庫表）包含4個數據庫，4個RW節點（4C16GB），ShardingSphere-Proxy以內存模式部署于ECS，ShardingSphere-Proxy提供1個邏輯庫4張邏輯表，每張邏輯表均按id%4散列于PolarDB多主集群（庫表）的4個數據庫。

測試過程

初始狀態下，4個數據庫全部負載于其中一個RW節點，使用Sysbench啟動2048個線程對所有邏輯表執行基準測試。測試期間，將3個數據庫依次切換至空閑的RW節點，最終每個RW節點上均有且僅有一個數據庫，查看集群整體的性能變化趨勢。

• 如果業務的寫入以自動提交（autoCommit=1）為主，PolarDB多主集群（庫表）結合ShardingSphere-Proxy可以實現接近線性的性能提升。

  • 配置較短的超時時間。

    • QPS與MPS：

    • TPS與CPU使用率：

  • 聯動注冊中心。

    • QPS與MPS：

    • TPS與CPU使用率：

• 如果業務的寫入以顯式事務（autoCommit=0）為主，PolarDB多主集群（庫表）結合ShardingSphere-Proxy可以實現僅次于線性的性能提升。以256個線程進行寫入測試，彈性擴容效果如下：

  • 配置較短的超時時間。

    • QPS與MPS：

    • TPS與CPU使用率：

  • 聯動注冊中心。

    • QPS與MPS：

    • TPS與CPU使用率：