sharding-jdbc分庫連接數優化_ZenDei技術網路在線

本文介紹了分庫分表的概念及優勢,以及sharding-jdbc分庫分表中間件,探究了sharding-jdbc的路由規則的執行流程 ...

一.背景:

配運平臺組的快遞訂單履約中心(cp-eofc)及物流平臺履約中心(jdl-uep-ofc)系統都使用了ShardingSphere生態的sharding-jdbc作為分庫分表中間件, 整個集群採用只分庫不分表的設計,共16個MYSQL實例,每個實例有32個庫,集群共512個庫.

當每增加一臺客戶端主機,一個MYSQl實例最少要增加32個連接(通常都會使用連接池,根據配置的最大連接數,這個連接數可能會放大5~10倍).並且通常一個系統都會分為web,provider,worker等多個應用,這些應用共用一套數據源.隨著應用機器數的增加,MYSQL實例的連接數會很快達到上限,這就對系統的擴容造成了阻礙,無法橫向的增加機器數,只能縱向的提高機器的配置來應對流量的增長.

作為京東物流的核心系統,業務增長迅速,系統所承接的流量也是逐漸增加,所以急需解決這個制約系統擴展的瓶頸點.

二.分庫分表的相關概念介紹

2.1 為什麼要分庫分表

2.1.1 分庫

隨著業務的發展,單庫中的數據量不斷增加,資料庫的QPS會越來越高,對資料庫的讀寫耗時也會相應的增長,這時單庫的讀寫性能必然會成為系統的瓶頸點.這時可以通過將單個資料庫拆分為多個資料庫的方法,來分擔資料庫的壓力,提升性能.同時多個資料庫分佈在不同的機器上也提高了資料庫的可用性.

2.1.2 分表

隨著單表數據量的增加,對於數據的查詢和更新,即使在資料庫底層有一定的優化,但是隨著量變必定會引起質變,導致性能急劇下降.這時可以通過分表的方法,將單表數據按一定規則水平拆分到多個表中,減小單表的數據量,提升系統性能.

2.2 sharding-jdbc簡介

ShardingSphere

是一套開源的分散式資料庫中間件解決方案組成的生態圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（計劃中）這3款相互獨立的產品組成.他們均提供標準化的數據分片、分散式事務和資料庫治理功能，可適用於如Java同構、異構語言、容器、雲原生等各種多樣化的應用場景。

Sharding-JDBC

定位為輕量級Java框架，在Java的JDBC層提供的額外服務。它使用客戶端直連資料庫，以jar包形式提供服務，無需額外部署和依賴，可理解為增強版的JDBC驅動，完全相容JDBC和各種ORM框架。

適用於任何基於Java的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。基於任何第三方的資料庫連接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。

支持任意實現JDBC規範的資料庫。目前支持MySQL，Oracle，SQLServer和PostgreSQL。

我們先看下ShardingSphere官網給出的基於Spring命名空間的規則配置示例:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:sharding="http://shardingsphere.io/schema/shardingsphere/sharding" 
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
                        http://www.springframework.org/schema/beans/spring-beans.xsd
                        http://shardingsphere.io/schema/shardingsphere/sharding 
                        http://shardingsphere.io/schema/shardingsphere/sharding/sharding.xsd 
                        ">
    <!-數據源ds0->
    <bean id="ds0" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName" value="com.mysql.jdbc.Driver" />
        <property name="url" value="jdbc:mysql://localhost:3306/ds0" />
        <property name="username" value="root" />
        <property name="password" value="" />
    </bean>
    <!-數據源ds1->
    <bean id="ds1" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName" value="com.mysql.jdbc.Driver" />
        <property name="url" value="jdbc:mysql://localhost:3306/ds1" />
        <property name="username" value="root" />
        <property name="password" value="" />
    </bean>
    
    <!-分片策略->
    <sharding:inline-strategy id="databaseStrategy" sharding-column="user_id" algorithm-expression="ds$->{user_id % 2}" />
    <sharding:inline-strategy id="orderTableStrategy" sharding-column="order_id" algorithm-expression="t_order$->{order_id % 2}" />
    <sharding:inline-strategy id="orderItemTableStrategy" sharding-column="order_id" algorithm-expression="t_order_item$->{order_id % 2}" />
    
    <!-sharding數據源配置->
    <sharding:data-source id="shardingDataSource">
        <sharding:sharding-rule data-source-names="ds0,ds1">
            <sharding:table-rules>
                <sharding:table-rule logic-table="t_order" actual-data-nodes="ds$->{0..1}.t_order$->{0..1}" database-strategy-ref="databaseStrategy" table-strategy-ref="orderTableStrategy" />
                <sharding:table-rule logic-table="t_order_item" actual-data-nodes="ds$->{0..1}.t_order_item$->{0..1}" database-strategy-ref="databaseStrategy" table-strategy-ref="orderItemTableStrategy" />
            </sharding:table-rules>
        </sharding:sharding-rule>
    </sharding:data-source>
</beans>

配置總結:

1.需要配置多個數據源ds0,ds1;

2.分片策略中配置分片鍵(sharding-column)和分片表達式(algorithm-expression)需符合groovy語法;

3.在sharding數據源中sharding:table-rule標簽中配置邏輯表名(logic-table),庫分片策略(database-strategy-ref)和表分片策略(table-strategy-ref),actual-data-node屬性由數據源名 + 表名組成，以小數點分隔,用於廣播表;

三.問題分析與解決方案

3.1 問題分析

正如文章開頭提到的目前我們的MYSQL集群架構如下,16個MYSQL實例,每個實例有32個庫,集群共512個庫.當客戶端主機啟動後與MYSQL_0實例中的32個庫連接,分別會建立32個數據源,連接池配置的最大連接數為5,也就是說極端情況下一個客戶端與一個MYSQL實例最多會建立32*5=160個連接數.對於物流的一些核心系統在大促時擴容上百台是很常見的,所以很快單個實例的最大連接數就會觸達上限.

目前客戶端連接連接資料庫集群形式如圖所示:

3.2 可行方案

我們的目標就是降低單個MYSQL實例的連接數,其中我們共探討了幾種方案如下:

3.2.1 單實例不分庫只分表

這樣一個客戶端與單個資料庫實例只需通過一個連接池連接,大大降低了連接數.但這種方案改變了現有的分片規則,需要新建一套資料庫集群,根據新規則同步歷史數據和增量數據,還有新舊數據驗證,但難度和風險最高的還是線上切換過程,可能會造成數據不一致,且一旦出問題回滾方案也會非常複雜.

3.2.2 使用支持彈性擴展的資料庫

使用京東的jed,tidb等支持彈性擴展的資料庫,將數據同步到新庫中,這類資料庫的優勢是開發人員只需關註業務,不需要再去處理資料庫連接這些底層細節.

3.2.3 使用sharding-proxy

Sharding-Proxy的定位是透明化的資料庫代理,我們可以在伺服器上部署一套Sharding-Proxy,客戶端只需連接proxy服務,再由proxy伺服器連接MYSQL集群,這樣MYSQL集群的連接數只與proxy伺服器的數量有關,與客戶端解耦.

3.2.4 通過改造sharding-jdbc

理論上我們只要獲取資料庫實例上某個庫的連接,我們就可以通過"庫名.表名"的方式訪問這台實例上其他庫中的數據(當然前提是用戶要擁有要訪問庫的許可權),我們是否可以通過改造sharding-jdbc來實現這種訪問方式?

以上幾種方案,3.2.1和3.2.2都需要新建資料庫,同步歷史和增量數據,還涉及線上切換數據源,3.2.3需要部署一套proxy服務,並且為了高可用必定要以集群方式部署,這三種方案工作量和風險都較高,我們基於成本最小原則,最終選擇改造sharding-jdbc的方案.

3.3 探究sharding-jdbc

3.3.1 工作流程

sharding-jdbc的工作流程可以分為以下步驟:

sql解析-詞法解析和語法解析;
sql路由-根據解析上下文匹配資料庫和表的分片策略，並生成路由路徑;
sql改寫-將邏輯SQL改寫為在真實資料庫中可以正確執行的SQL;
sql執行-使用多線程併發執行sql;
結果歸併-將從各個數據節點獲取的多數據結果集，組合成為一個結果集並正確的返回至請求客戶端;

顯然資料庫和表的分片是在sql路由階段處理,所以我們以sql路由邏輯為入口分析下源碼.

3.3.2 源碼分析

ShardingStandardRoutingEngine類中的route方法為計算路由的入口,返回的結果是資料庫和表的分片集合:

route方法中的核心邏輯在該類的route0方法中,其中routeDataSources方法負責database路由,routeTables方法負責table路由,實際路由計算在StandardShardingStrategy的doSharding方法中,我們繼續深入.

在StandardShardingStrategy類中有兩個成員屬性,preciseShardingAlgorithm(精準分片演算法),rangeShardingAlgorithm(範圍分片演算法),由於我們的sql都只指定分片鍵精準查詢,使用的都是preciseShardingAlgorithm計算出的結果,PreciseShardingAlgorithm是個介面,那我們就可以實現這個介面來自定義分片演算法.

同時在sharding-sphere官網上也找到了相應的標簽支持:

所以我們只需要自己實現PreciseShardingAlgorithm介面並配置在標簽內即可實現自定義分片策略.

3.4 改造步驟

3.4.1 庫分片改造

目前應用配置了ds_0_{ds_511共512個數據源,我們只需配置ds_0}ds_15共16個數據源,每個數據源配置的是單個實例上的第一個庫.

對於分片規則,我們可以依然使用sharding:inline-strategy標簽,只需對Groovy表達式進行重寫,分片鍵為order_code,之前分片演算法為(Math.abs(order_code.hashCode()) % 512)即用order_code列的哈希值對512取模得到0_{511,我們只需要將結果再整除32即可得到0}16,即表達式改寫為(Math.abs(order_code.hashCode()) % 512).intdiv(32).

改造前分庫規則配置:

改造後分庫規則配置:

3.4.2 表分片改造

實現PreciseShardingAlgorithm介面,重寫表分片演算法,使計算結果返回"實際庫名+表名"的形式;

例如:查詢DB_31庫上t_order表的user_id=35711的數據,資料庫分片演算法返回的數據源為"DB_0",表分片演算法返回"DB_31.t_order";

自定義表分片演算法:

在xml中定義sharding:standard-strategy標簽,其屬性precise-algorithm-ref配置為我們自定義的分表演算法.

3.4.3 資料庫連接池參數調整

改造前是一個庫對應一個數據源連接池,改造後一個實例上的32個庫共用一個數據源連接池,那麼連接池的最大連接數,最小空閑連接數等參數需要相應的做調整.這個需要根據業務流量做合理的評估,當然最嚴謹的還是要以壓測結果作為依據.

改造後客戶端連接集群的形式如圖:

優化前後資料庫集群連接數對比:

四.小插曲

在改寫庫分片規則的Groovy表達式時,整除32直接在原有表達式上配置"/32"即Math.abs(order_code.hashCode()) % 512 / 32 ,在調試中發現執行sql會報"no database route info"錯誤信息,經過debug發現sharding-jdbc計算分片規則時會出現小數(例如:ds_14.6857),導致找不到數據源,這是因為Groovy沒有提供專用的整數除法運算符,所以要用.intdiv()方法,最終表達式改寫為(Math.abs(order_code.hashCode()) % 512).intdiv(32).

五.總結

本文介紹了分庫分表的概念及優勢,以及sharding-jdbc分庫分表中間件,探究了sharding-jdbc的路由規則的執行流程.當然在系統設計之初,對於資料庫的分庫分表,到底需不需要做?是多分庫好還是多分表好?並沒有一個放之四海而皆準的法則,需結合系統的特點(例如qps,tps,單表數據量,磁碟規格,數據保留時間,業務增量,數據冷熱方案等因素)來決策權衡,有利有弊才需決策,有取有舍才需權衡.

作者：京東物流張仲良

來源：京東雲開發者社區自猿其說Tech