眾所周知,數據庫很容易成為應用系統的瓶頸。單機數據庫的資源和處理能力有限,在高并發的分布式系統中,可采用分庫分表突破單機局限。本文總結了分庫分表的相關概念、全局ID的生成策略、分片策略、平滑...
眾所周知,數據庫很容易成為應用系統的瓶頸。單機數據庫的資源和處理能力有限,在高并發的分布式系統中,可采用分庫分表突破單機局限。本文總結了分庫分表的相關概念、全局ID的生成策略、分片策略、平滑擴容方案、以及流行的方案。
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; ## 步長增量
如果采用該方案,在擴容時需要遷移已有數據至新的所屬分片。
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等數據庫的計劃。
作者:王克鋒
出處:https://kefeng.wang/2018/07/22/mysql-sharding/
來源:本文內容搜集或轉自各大網絡平臺,并已注明來源、出處,如果轉載侵犯您的版權或非授權發布,請聯系小編,我們會及時審核處理。
聲明:江蘇教育黃頁對文中觀點保持中立,對所包含內容的準確性、可靠性或者完整性不提供任何明示或暗示的保證,不對文章觀點負責,僅作分享之用,文章版權及插圖屬于原作者。
Copyright?2013-2024 JSedu114 All Rights Reserved. 江蘇教育信息綜合發布查詢平臺保留所有權利
蘇公網安備32010402000125
蘇ICP備14051488號-3技術支持:南京博盛藍睿網絡科技有限公司
南京思必達教育科技有限公司版權所有 百度統計