MySQL 分庫分表及其平滑擴容方案 MySQL 分庫分表及其平滑擴容方案
MySQL 分庫分表及其平滑擴容方案
<a class="follow-nickName" href="https://me.csdn.net/kefengwang" target="_blank">kefeng-wang</a> <span class="read-count">閱讀數：1076</span><span class="article_info_click" style="position: static;">更多</span> <div class="tags-box space"> <span class="label">所屬專欄：</span> <a class="tag-link" href="https://blog.csdn.net/column/details/25370.html" target="_blank">Java儲存相關中介軟體</a> </div> </div> <div class="operating"> </div> </div> </div> </div> <article class="baidu_pl"> <div id="article_content" class="article_content clearfix csdn-tracking-statistics" data-pid="blog" data-mod="popu_307" data-dsm="post"> <div class="article-copyright"> 版權宣告：【自由轉載-非商用-非衍生-保持署名】－轉載請標明作者和出處。 https://blog.csdn.net/kefengwang/article/details/81213050 </div> <div id="content_views" class="markdown_views"> <!-- flowchart 箭頭圖示 勿刪 --> <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"><path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);"></path></svg> <p>眾所周知，資料庫很容易成為應用系統的瓶頸。單機資料庫的資源和處理能力有限，在高併發的分散式系統中，可採用分庫分表突破單機侷限。本文總結了分庫分表的相關概念、全域性ID的生成策略、分片策略、平滑擴容方案、以及流行的方案。 <br>
作者：王克鋒
出處：https://kefeng.wang/2018/07/22/mysql-sharding/
版權：自由轉載-非商用-非衍生-保持署名，轉載請標明作者和出處。
1 分庫分表概述
在業務量不大時，單庫單表即可支撐。
當資料量過大儲存不下、或者併發量過大負荷不起時，就要考慮分庫分表。
1.1 分庫分表相關術語
- 讀寫分離: 不同的資料庫，同步相同的資料，分別只負責資料的讀和寫；
- 分割槽: 指定分割槽列表達式，把記錄拆分到不同的區域中(必須是同一伺服器，可以是不同硬碟)，應用看來還是同一張表，沒有變化；
- 分庫：一個系統的多張資料表，儲存到多個數據庫例項中；
- 分表: 對於一張多行(記錄)多列(欄位)的二維資料表，又分兩種情形：
(1) 垂直分表: 豎向切分，不同分表儲存不同的欄位，可以把不常用或者大容量、或者不同業務的欄位拆分出去；
(2) 水平分表(最複雜): 橫向切分，按照特定分片演算法，不同分表儲存不同的記錄。
1.2 真的要採用分庫分表？
需要注意的是，分庫分表會為資料庫維護和業務邏輯帶來一系列複雜性和效能損耗，除非預估的業務量大到萬不得已，切莫過度設計、過早優化。
規劃期內的資料量和效能問題，嘗試能否用下列方式解決：
- 當前資料量：如果沒有達到幾百萬，通常無需分庫分表；
- 資料量問題：增加磁碟、增加分庫(不同的業務功能表，整表拆分至不同的資料庫)；
- 效能問題：升級CPU/記憶體、讀寫分離、優化資料庫系統配置、優化資料表/索引、優化 SQL、分割槽、資料表的垂直切分；
- 如果仍未能奏效，才考慮最複雜的方案：資料表的水平切分。
2 全域性ID生成策略
2.1 自動增長列
優點：資料庫自帶功能，有序，效能佳。
缺點：單庫單表無妨，分庫分表時如果沒有規劃，ID可能重複。解決方案：
2.1.1 設定自增偏移和步長
## 假設總共有 10 個分表
## 級別可選: SESSION(會話級), GLOBAL(全域性)
SET @@SESSION.auto_increment_offset = 1; ## 起始值, 分別取值為 1~10
SET @@SESSION.auto_increment_increment = 10; ## 步長增量
- 1
- 2
- 3
- 4
如果採用該方案，在擴容時需要遷移已有資料至新的所屬分片。
2.1.2 全域性ID對映表
在全域性 Redis 中為每張資料表建立一個 ID 的鍵，記錄該表當前最大 ID；
每次申請 ID 時，都自增 1 並返回給應用；
Redis 要定期持久至全域性資料庫。
2.2 UUID(128位)
在一臺機器上生成的數字，它保證對在同一時空中的所有機器都是唯一的。通常平臺會提供生成UUID的API。
UUID 由4個連字號(-)將32個位元組長的字串分隔後生成的字串，總共36個位元組長。形如：550e8400-e29b-41d4-a716-446655440000。
UUID 的計算因子包括：乙太網卡地址、納秒級時間、晶片ID碼和許多可能的數字。
UUID 是個標準，其實現有幾種，最常用的是微軟的 GUID(Globals Unique Identifiers)。
優點：簡單，全球唯一；
缺點：儲存和傳輸空間大，無序，效能欠佳。
2.3 COMB(組合)
參考資料：The Cost of GUIDs as Primary Keys
組合 GUID(10位元組) 和時間(6位元組)，達到有序的效果，提高索引效能。
2.4 Snowflake(雪花) 演算法
參考資料：twitter/snowflake，Snowflake 演算法詳解
Snowflake 是 Twitter 開源的分散式 ID 生成演算法，其結果為 long(64bit) 的數值。
其特性是各節點無需協調、按時間大致有序、且整個叢集各節點單不重複。
該數值的預設組成如下(符號位之外的三部分允許個性化調整)：
- 1bit: 符號位，總是 0(為了保證數值是正數)。
- 41bit: 毫秒數(可用 69 年)；
- 10bit: 節點ID(5bit資料中心 + 5bit節點ID，支援 32 * 32 = 1024 個節點)
- 12bit: 流水號(每個節點每毫秒內支援 4096 個 ID，相當於 409萬的 QPS，相同時間內如 ID 遇翻轉，則等待至下一毫秒)
3 分片策略
3.1 連續分片
根據特定欄位(比如使用者ID、訂單時間)的範圍，值在該區間的，劃分到特定節點。
優點：叢集擴容後，指定新的範圍落在新節點即可，無需進行資料遷移。
缺點：如果按時間劃分，資料熱點分佈不均(歷史數冷當前資料熱)，導致節點負荷不均。
3.3 ID取模分片
缺點：擴容後需要遷移資料。
3.2 一致性Hash演算法
優點：擴容後無需遷移資料。
3.4 Snowflake 分片
優點：擴容後無需遷移資料。
4 分庫分表引入的問題
4.1 分散式事務
參見 分散式事務的解決方案
由於兩階段/三階段提交對效能損耗大，可改用事務補償機制。
4.2 跨節點 JOIN
對於單庫 JOIN，MySQL 原生就支援；
對於多庫，出於效能考慮，不建議使用 MySQL 自帶的 JOIN，可以用以下方案避免跨節點 JOIN：
- 全域性表: 一些穩定的共用資料表，在各個資料庫中都儲存一份；
- 欄位冗餘: 一些常用的共用欄位，在各個資料表中都儲存一份；
- 應用組裝：應用獲取資料後再組裝。
另外，某個 ID 的使用者資訊在哪個節點，他的關聯資料(比如訂單)也在哪個節點，可以避免分散式查詢。
4.3 跨節點聚合
只能在應用程式端完成。
但對於分頁查詢，每次大量聚合後再分頁，效能欠佳。
4.4 節點擴容
節點擴容後，新的分片規則導致資料所屬分片有變，因而需要遷移資料。
5 節點擴容方案
相關資料: 資料庫秒級平滑擴容架構方案
5.1 常規方案
如果增加的節點數和擴容操作沒有規劃，那麼絕大部分資料所屬的分片都有變化，需要在分片間遷移：
- 預估遷移耗時，釋出停服公告；
- 停服(使用者無法使用服務)，使用事先準備的遷移指令碼，進行資料遷移；
- 修改為新的分片規則；
- 啟動伺服器。
5.2 免遷移擴容
採用雙倍擴容策略，避免資料遷移。擴容前每個節點的資料，有一半要遷移至一個新增節點中，對應關係比較簡單。
具體操作如下(假設已有 2 個節點 A/B，要雙倍擴容至 A/A2/B/B2 這 4 個節點)：
- 無需停止應用伺服器；
- 新增兩個資料庫 A2/B2 作為從庫，設定主從同步關係為：A=>A2、B=>B2，直至主從資料同步完畢(早期資料可手工同步)；
- 調整分片規則並使之生效：
原ID%2=0 => A改為ID%4=0 => A, ID%4=2 => A2；
原ID%2=1 => B改為ID%4=1 => B, ID%4=3 => B2。 - 解除資料庫例項的主從同步關係，並使之生效；
- 此時，四個節點的資料都已完整，只是有冗餘(多存了和自己配對的節點的那部分資料)，擇機清除即可(過後隨時進行，不影響業務)。
6 分庫分表方案
6.1 代理層方式
部署一臺代理伺服器偽裝成 MySQL 伺服器，代理伺服器負責與真實 MySQL 節點的對接，應用程式只和代理伺服器對接。對應用程式是透明的。
比如 MyCAT，官網，原始碼，參考文件：MyCAT+MySQL 讀寫分離部署
MyCAT 後端可以支援 MySQL, SQL Server, Oracle, DB2, PostgreSQL等主流資料庫，也支援MongoDB這種新型NoSQL方式的儲存，未來還會支援更多型別的儲存。
MyCAT 不僅僅可以用作讀寫分離，以及分表分庫、容災管理，而且可以用於多租戶應用開發、雲平臺基礎設施，讓你的架構具備很強的適應性和靈活性。
6.2 應用層方式
處於業務層和 JDBC 層中間，是以 JAR 包方式提供給應用呼叫，對程式碼有侵入性。主要方案有：
(1)淘寶網的 TDDL: 已於 2012 年關閉了維護通道，建議不要使用。
(2)噹噹網的 Sharding-JDBC: 仍在活躍維護中：
是噹噹應用框架 ddframe 中，從關係型資料庫模組 dd-rdb 中分離出來的資料庫水平分片框架，實現透明化資料庫分庫分表訪問，實現了 Snowflake 分片演算法；
Sharding-JDBC定位為輕量Java框架，使用客戶端直連資料庫，無需額外部署，無其他依賴，DBA也無需改變原有的運維方式。
Sharding-JDBC分片策略靈活，可支援等號、between、in等多維度分片，也可支援多分片鍵。
SQL解析功能完善，支援聚合、分組、排序、limit、or等查詢，並支援Binding Table以及笛卡爾積表查詢。
Sharding-JDBC直接封裝JDBC API，可以理解為增強版的JDBC驅動，舊程式碼遷移成本幾乎為零：
- 可適用於任何基於Java的ORM框架，如JPA、Hibernate、Mybatis、Spring JDBC Template或直接使用JDBC。
- 可基於任何第三方的資料庫連線池，如DBCP、C3P0、 BoneCP、Druid等。
- 理論上可支援任意實現JDBC規範的資料庫。雖然目前僅支援MySQL，但已有支援Oracle、SQLServer等資料庫的計劃。
<script>
(function(){
function setArticleH(btnReadmore,posi){
var winH = $(window).height();
var articleBox = $("div.article_content");
var artH = articleBox.height();
if(artH > winH*posi){
articleBox.css({
'height':winH*posi+'px',
'overflow':'hidden'
})
btnReadmore.click(function(){
if(typeof window.localStorage === "object" && typeof window.csdn.anonymousUserLimit === "object"){
if(!window.csdn.anonymousUserLimit.judgment()){
window.csdn.anonymousUserLimit.Jumplogin();
return false;
}else if(!currentUserName){
window.csdn.anonymousUserLimit.updata();
}
}
articleBox.removeAttr("style");
$(this).parent().remove();
})
}else{
btnReadmore.parent().remove();
}
}
var btnReadmore = $("#btn-readmore");
if(btnReadmore.length>0){
if(currentUserName){
setArticleH(btnReadmore,3);
}else{
setArticleH(btnReadmore,1.2);
}
}
})()
</script>
</article>