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"  destroy-method="close">
        <property name="driverClassName" value="https://www.cnblogs.com/Jcloud/p/com.mysql.jdbc.Driver" />
        <property name="url" value="https://www.cnblogs.com/Jcloud/p/jdbc:mysql://localhost:3306/ds0" />
        <property name="username" value="https://www.cnblogs.com/Jcloud/p/root" />
        <property name="password" value="" />
    </bean>
    <!-資料源ds1->
    <bean id="ds1"  destroy-method="close">
        <property name="driverClassName" value="https://www.cnblogs.com/Jcloud/p/com.mysql.jdbc.Driver" />
        <property name="url" value="https://www.cnblogs.com/Jcloud/p/jdbc:mysql://localhost:3306/ds1" />
        <property name="username" value="https://www.cnblogs.com/Jcloud/p/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

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/557170.html

標籤：MySQL

上一篇：再獲認可！萬里資料庫參編中國信通院資料庫研究報告 GreatSQL入選中國資料庫產業圖譜

下一篇：返回列表