• 背景
• 分庫、分錶帶來的後遺症
• 分表策略
• 一些注意事項

背景

最近一段時間內結束了資料庫表拆分專案，這裡做個簡單的小結。

本次拆分主要包括訂單和優惠券兩大塊，這兩塊都是覆蓋全集團所有分子公司所有業務線。隨著公司的業務飛速發展，不管是儲存的要求，還是寫入、讀取的性都基本上到了警戒水位。

訂單是交易的核心，優惠券是營銷的核心，這兩塊基本上是整個平臺的正向最核心部分。為了支援未來三到五年的快速發展，我們需要對資料進行拆分。

資料庫表拆分業內已經有很多成熟方案，已經不是什麼高深的技術，基本上是純工程化的流程，但是能有機會進行實際的操刀一把機會還是難得，所以非常有必要做個總結。

由於分庫分表包含的技術選型和方式方法多種多樣，這篇文章不是羅列和彙總介紹各種方法，而是總結我們在實施分庫分表過程中的一些經驗。

根據業務場景判斷，我們主要是做水平拆分，做邏輯 DB 拆分，考慮到未來資料庫寫入瓶頸可以將一組 sharding 表直接遷移進分庫中。

分庫、分錶帶來的後遺症

分庫、分表會帶來很多的後遺症，會使整個系統架構變的複雜。分的好與不好最關鍵就是如何尋找那個 sharding key，如果這個 sharding key 剛好是業務維度上的分界線就會直接提升效能和改善複雜度，否則就會有各種腳手架來支撐，系統也就會變得複雜。

比如訂單系統中的使用者__ID__、訂單__type__、商家__ID__、渠道__ID__，優惠券系統中的批次__ID__、渠道__ID__、機構__ID__ 等，這些都是潛在的 sharding key

如果剛好有這麼一個 sharding key 存在後面處理路由（routing）就會很方便，否則就需要一些大而全的索引表來處理 OLAP 的查詢。

一旦 sharding 之後首先要面對的問題就是查詢時排序分頁問題。

歸併排序

原來在一個數據庫表中處理排序分頁是比較方便的，sharding 之後就會存在多個數據源，這裡我們將多個數據源統稱為分片。

想要實現多分片排序分頁就需要將各個片的資料都彙集起來進行排序，就需要用到 歸併排序 演算法。這些資料在各個分片中可以做到有序的（輸出有序），但是整體上是無序的。

我們看個簡單的例子：

shard node 1: {1、3、5、7、9}
shard node 2: {2、4、6、8、10}
 

這是做 奇偶 sharding 的兩個分片，我們假設分頁引數設定為每頁4條，當前第1頁，引數如下：

pageParameter：pageSize：4、currentPage：1

最樂觀情況下我們需要分別讀取兩個分片節點中的前兩條：

shard node 1: {1、3}
shard node 2: {2、4}

排序完剛好是 {1、2、3、4}，但是這種場景基本上不太可能出現，假設如下分片節點資料：

shard node 1: {7、9、11、13、15}
shard node 2: {2、4、6、8、10、12、14}

我們還是按照讀取每個節點前兩條肯定是錯誤的，因為最悲觀情況下也是最真實的情況就是排序完後所有的資料都來自一個分片。所以我們需要讀取每個節點的 pageSize 大小的資料出來才有可能保證資料的正確性。

這個例子只是假設我們的查詢條件輸出的資料剛好是均等的，真實的情況一定是各種各樣的查詢條件篩選出來的資料集合，此時這個資料一定不是這樣的排列方式，最真實的就是最後者這種結構。

我們以此類推，如果我們的 currentPage:1000 那麼會出現什麼問題，我們需要每個 sharding node 讀取 __4000(1000*4=4000)__ 條資料出來排序，因為最悲觀情況下有可能所有的資料均來自一個 sharding node 。

這樣無限制的翻頁下去，處理排序分頁的機器肯定會記憶體撐爆，就算不撐爆一定會觸發效能瓶頸。

這個簡單的例子用來說明分片之後，排序分頁帶來的現實問題，這也有助於我們理解分散式系統在做多節點排序分頁時為什麼有最大分頁限制。

深分頁效能問題-改變查詢條件重新分頁

一個龐大的資料集會通過多種方式進行資料拆分，按機構、按時間、按渠道等等，拆分在不同的資料來源中。一般的深分頁問題我們可以通過改變查詢條件來平滑解決，但是這種方案並不能解決所有的業務場景。

比如，我們有一個訂單列表，從C端使用者來查詢自己的訂單列表資料量不會很大，但是運營後臺系統可能面對全平臺的所有訂單資料量，所以資料量會很大。

改變查詢條件有兩種方式，一種是顯示的設定，儘量縮小查詢範圍，這種設定一般都會優先考慮，比如時間範圍、支付狀態、配送狀態等等，通過多個疊加條件就可以橫豎過濾出很小一部分資料集。

那麼第二種條件為隱式設定。比如訂單列表通常是按照訂單建立時間來排序，那麼當翻頁到限制的條件時，我們可以改變這個時間。

sharding node 1:
orderID     createDateTime
100000      2018-01-10 10:10:10
200000      2018-01-10 10:10:11
300000      2018-01-10 10:10:12
400000      2018-01-10 10:10:13
500000      2018-01-20 10:10:10
600000      2018-01-20 10:10:11
700000      2018-01-20 10:10:12

sharding node 2:
orderID     createDateTime
110000      2018-01-11 10:10:10
220000      2018-01-11 10:10:11
320000      2018-01-11 10:10:12
420000      2018-01-11 10:10:13
520000      2018-01-21 10:10:10
620000      2018-01-21 10:10:11
720000      2018-01-21 10:10:12

我們假設上面是一個訂單列表，orderID 訂單號大家就不要在意順序性了。因為 sharding 之後所有的 orderID 都會由發號器統一發放，多個叢集多個消費者同時獲取，但是建立訂單的速度是不一樣的，所以順序性已經不存在了。

上面的兩個 sharding node 基本上訂單號是交叉的，如果按照時間排序 node 1 和 node 2 是要交替獲取資料。

比如我們的查詢條件和分頁引數：

where createDateTime>'2018-01-11 00:00:00'

pageParameter：pageSize：5、currentPage：1

獲取的結果集為：

orderID     createDateTime
100000      2018-01-10 10:10:10
200000      2018-01-10 10:10:11
300000      2018-01-10 10:10:12
400000      2018-01-10 10:10:13
110000      2018-01-11 10:10:10

前面 4 條記錄來自 node 1 後面 1 條資料來自 node 2 ，整個排序集合為：

sharding node 1:
orderID     createDateTime
100000      2018-01-10 10:10:10
200000      2018-01-10 10:10:11
300000      2018-01-10 10:10:12
400000      2018-01-10 10:10:13
500000      2018-01-20 10:10:10

sharding node 2:
orderID     createDateTime
110000      2018-01-11 10:10:10
220000      2018-01-11 10:10:11
320000      2018-01-11 10:10:12
420000      2018-01-11 10:10:13
520000      2018-01-21 10:10:10

按照這樣一直翻頁下去每翻頁一次就需要在 node 1 、node 2 多獲取 5 條資料。這裡我們可以通過修改查詢條件來讓整個翻頁變為重新查詢。

where createDateTime>'2018-01-11 10:10:13'

因為我們可以確定在 ‘2018-01-11 10:10:13’ 時間之前所有的資料都已經查詢過，但是為什麼時間不是從 ‘2018-01-21 10:10:10’ 開始，因為我們要考慮併發情況，在 1s 內會有多個訂單進來。

這種方式是實現最簡單，不需要藉助外部的計算來支撐。這種方式有一個問題就是要想重新計算分頁的時候不丟失資料就需要保留原來一條資料，這樣才能知道開始的時間在哪裡，這樣就會在下次的分頁中看到這條時間。但是從真實的深分頁場景來看也可以忽略，因為很少有人會一頁一頁一直到翻到500頁，而是直接跳到最後幾頁，這個時候就不存在那個問題。

如果非要精準控制這個偏差就需要記住區間，或者用其他方式來實現了，比如全量查詢表、sharding 索引表、最大下單 tps 值之類的，用來輔助計算。

（可以利用資料同步中介軟體建立單表多級索引、多表多維度索引來輔助計算。我們使用到的資料同步中介軟體有 datax、yugong、otter、canal 可以解決全量、增量同步問題）。

分表策略

分表有多種方式，mod、rang、presharding、自定義路由，每種方式都有一定的側重。

我們主要使用 mod + presharding 的方式，這種方式帶來的最大的一個問題就是後期的節點變動資料遷移問題，可以通過參考一致性 hash 演算法的虛擬節點來解決。

資料表拆分和 cache sharding 有一些區別，cache 能接受 cache miss ，通過被動快取的方式可以維護起 cache 資料。但是資料庫不存在 select miss 這種場景。

在 cache sharding 場景下一致性 hash 可以用來消除減少、增加 sharding node 時相鄰分片壓力問題。 但是資料庫一旦出現數據遷移一定是不能接受資料查詢不出來的。所以我們為了將來資料的平滑遷移，做了一個 虛擬節點 + 真實節點 mapping 。

physics node : node 1 node 2 node 3 node 4
virtual node : node 1 node 2 node 3.....node 20

node mapping :
virtual node 1 ~ node 5 {physics node 1}
virtual node 6 ~ node 10 {physics node 2}
virtual node 11 ~ node 15 {physics node 3}
virtual node 16 ~ node 20 {physics node 4}

為了減少將來遷移資料時 rehash 的成本和延遲的開銷，將 hash 後的值儲存在表裡，將來遷移直接查詢出來快速匯入。

hash 片 2 的次方問題

在我們熟悉的 hashmap 裡，為了減少衝突和提供一定的效能將 hash 桶的大小設定成 2 的 n 次方，然後採用 hash&(legnth-1) 位與的方式計算，這樣主要是大師們發現 2 的 n 次方的二進位制除了高位是 0 之外所有地位都是 1，通過位與可以快速反轉二進位制然後地位加 1 就是最終的值。

我們在做資料庫 sharding 的時候不需要參考這一原則，這一原則主要是為了程式內部 hash 表使用，外部我們本來就是要 hash mod 確定 sharding node 。

通過 mod 取模的方式會出現不均勻問題，在此基礎上可以做個 自定義奇偶路由，這樣可以均勻兩邊的資料。

一些注意事項

1.在現有專案中整合 sharding-JDBC 有一些小問題，sharding-jdbc 不支援批量插入，如果專案中已經使用了大量的批量插入語句就需要改造，或者使用 輔助hash計算物理表名，在批量插入。

2.原有專案資料層使用 Druid + MyBatis，集成了 sharding-JDBC 之後 sharding-JDBC包裝了 Druid ，所以一些 sharding-JDBC 不支援的sql語句基本就過不去了。

3.使用 springboot 整合 sharding-JDBC 的時候，在bean載入的時候我需要設定 IncrementIdGenerator ，但是出現classloader問題。

IncrementIdGenerator incrementIdGenerator = this.getIncrementIdGenerator(dataSource);

ShardingRule shardingRule = shardingRuleConfiguration.build(dataSourceMap);
((IdGenerator) shardingRule.getDefaultKeyGenerator()).setIncrementIdGenerator(incrementIdGenerator);

private IncrementIdGenerator getIncrementIdGenerator(DataSource druidDataSource) {
...
    }

後來發現 springboot的類載入器使用的是 restartclassloader，所以導致轉換一直失敗。只要去掉 spring-boot-devtools package即可，restartclassloader 是為了熱啟動。

4.dao.xml 逆向工程問題，我們使用的很多資料庫表mybatis生成工具生成的時候都是物理表名，一旦我們使用了sharding-JDCB之後都是用的邏輯表名，所以生成工具需要提供選項來設定邏輯表名。

5.為 mybatis 提供的 SqlSessionFactory 需要在Druid的基礎上用shading-JDCB包裝下。

6.sharding-JDBC DefaultkeyGenerator 預設採用是 snowflake 演算法，但是我們不能直接用我們需要根據 datacenterid-workerid 自己配合zookeeper來設定 workerId 段。
（snowflake workId 10 bit 十進位制 1023，dataCenterId 5 bit 十進位制 31 、WorkId 5 bit 十進位制 31）

7.由於我們使用的是 mysql com.mysql.jdbc.ReplicationDriver 自帶的實現讀寫分離，所以處理讀寫分離會方便很多。如果不是使用的這種就需要手動設定 Datasource Hint 來處理。

8.在使用 mybatis dao mapper 的時候需要多份邏輯表，因為有些資料來源資料表是不需要走sharding的，自定義shardingStragety 來處理分支邏輯。

9 全域性id幾種方法
9.1 如果使用 zookeeper 來做分散式ID，就要注意 session expired 可能會存在重複 workid 問題，加鎖或者接受一定程度的並行（有序列號保證一段時間空間）。

9.2.採用集中發號器服務，在主DB中採用預生成表+incrment 外掛（經典取號器實現，innodb 儲存引擎中的 TRX_SYS_TRX_ID_STORE 事務號也是這種方式）

9.3.定長髮號器、業務規則發號器，這種需要業務上下文的發號器實現都需要預先配置，然後每次請求帶上獲取上下文來說明獲取業務型別

10.在專案中有些地方使用了自增id排序，資料表拆分之後就需要進行改造，因為ID大小順序已經不存在了。根據資料的最新排序時使用了id排序需要改造成用時間欄位排序。

作者：王清培 （滬江集團資深JAVA架構師）