溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
標簽： sharding 數據表拆分
最近一段時間內結束了數據庫表拆分項目，這里做個簡單的小結。
本次拆分主要包括訂單和優惠券兩大塊，這兩塊都是覆蓋全集團所有分子公司所有業務線。隨著公司的業務飛速發展，不管是存儲的要求，還是寫入、讀取的性都基本上到了警戒水位。
訂單是交易的核心，優惠券是營銷的核心，這兩塊基本上是整個平臺的正向最核心部分。為了支持未來三到五年的快速發展，我們需要對數據進行拆分。
數據庫表拆分業內已經有很多成熟方案，已經不是什么高深的技術，基本上是純工程化的流程，但是能有機會進行實際的操刀一把機會還是難得，所以非常有必要做個總結。
由于分庫分表包含的技術選型和方式方法多種多樣，這篇文章不是羅列和匯總介紹各種方法，而是總結我們在實施分庫分表過程中的一些經驗。
根據業務場景判斷，我們主要是做水平拆分，做邏輯 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:12sharding 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 20node 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 后的值保存在表里，將來遷移直接查詢出來快速導入。
在我們熟悉的 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架構師）免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
