**大家好，我是小富~** 之前有不少剛入坑 `Java` 的粉絲留言，想系統的學習一下分庫分表相關技術，可我一直沒下定決心搞，眼下趕上公司專案在使用 `sharding-jdbc` 對現有 `MySQL` 架構做分庫分表的改造，所以藉此機會出一系分庫分表落地實踐的文章，也算是自己對架構學習的一個總結。 我在網上陸陸續續的也看了一些有關於分庫分表的文章，可發現網上同質化的資料有點多，而且知識點又都比較零碎，還沒有詳細的實戰案例。為了更深入的學習下，我在某些平臺買了點付費課程，看了幾節課發現有點經驗的人看還可以，但對於新手入門來說，其實學習難度還是蠻大的。 為了讓新手也能看得懂，有些知識點我可能會用更多的篇幅加以描述，希望大家不要嫌我囉嗦，等這分庫分表系列文章完結後，我會把它做成 `PDF` 文件開源出去，能幫一個算一個吧！如果發現文中有哪些錯誤或不嚴謹之處，歡迎大家交流指正。 具體實踐分庫分表之前在囉嗦幾句，回頭複習下分庫分表的基礎概念。 ## 什麼是分庫分表 其實 `分庫` 和 `分表` 是兩個概念，只不過通常分庫與分表的操作會同時進行，以至於我們習慣性的將它們合在一起叫做分庫分表。 分庫分表是為了解決由於庫、表資料量過大，而導致資料庫效能持續下降的問題。按照一定的規則，將原本資料量大的資料庫拆分成多個單獨的資料庫，將原本資料量大的表拆分成若干個資料表，使得單一的庫、表效能達到最優的效果（響應速度快），以此提升整體資料庫效能。 ## 如何分庫分表 分庫分表的核心理念就是對資料進行切分（`Sharding`），以及切分後如何對資料的快速定位與查詢結果整合。而分庫與分表都可以從：`垂直`（縱向）和 `水平`（橫向）兩種緯度進行切分。  --- 下邊我們就以訂單相關的業務舉例，看看如何做庫、表的 `垂直` 和 `水平` 切分。 ### 垂直切分 垂直切分有 `垂直` 分庫 和 `垂直`分表。 ### 1、垂直分庫 垂直分庫相對來說是比較好理解的，核心理念就四個字：`專庫專用`。 按業務型別對錶進行分類，像訂單、支付、優惠券、積分等相應的表放在對應的資料庫中。開發者不可以跨庫直連別的業務資料庫，想要其他業務資料，對應業務方可以提供 `API` 介面，這就是微服務的初始形態。 垂直分庫很大程度上取決於業務的劃分，但有時候業務間的劃分並不是那麼清晰，比如：訂單資料的拆分要考慮到與其他業務間的關聯關係，並不是說直接把訂單相關的表放在一個庫裡這麼簡單。 在一定程度上，垂直分庫似乎提升了一些資料庫效能，可實際上並沒有解決由於單表資料量過大導致的效能問題，所以就需要配合水平切分方式來解決。  ### 2、垂直分表 `垂直分表`是基於資料表的列（欄位）為依據切分的，是一種大表拆小表的模式。 例如：一張 `order` 訂單表，將訂單金額、訂單編號等訪問頻繁的欄位，單獨拆成一張表，把 `blob` 型別這樣的大欄位或訪問不頻繁的欄位，拆分出來建立一個單獨的擴充套件表 `work_extend` ，這樣每張表只儲存原表的一部分欄位，再將拆分出來的表分散到不同的庫中。  我們知道資料庫是以行為單位將資料載入到記憶體中，這樣拆分以後核心表大多是訪問頻率較高的欄位，而且欄位長度也都較短，因而可以載入更多資料到記憶體中，來增加查詢的命中率，減少磁碟IO，以此來提升資料庫效能。 **垂直切分的優點**： - 業務間資料解耦，不同業務的資料進行獨立的維護、監控、擴充套件。 - 在高併發場景下，一定程度上緩解了資料庫的壓力。 **垂直切分的缺點**： - 提升了開發的複雜度，由於業務的隔離性，很多表無法直接訪問，必須通過介面方式聚合資料。 - 分散式事務管理難度增加。 - 資料庫還是存在單表資料量過大的問題，並未根本上解決，需要配合水平切分。 --- ### 水平切分 前邊說了垂直切分還是會存在單庫、表資料量過大的問題，當我們的應用已經無法在細粒度的垂直切分時， 依舊存在單庫讀寫、儲存效能瓶頸，這時就要配合水平切分一起了，水平切分能大幅提升資料庫效能。 ### 1、水平分庫 水平分庫是把同一個表按一定規則拆分到不同的資料庫中，每個庫可以位於不同的伺服器上，以此實現水平擴充套件，是一種常見的提升資料庫效能的方式。 這種方案往往能解決單庫儲存量及效能瓶頸問題，但由於同一個表被分配在不同的資料庫中，資料的訪問需要額外的路由工作，因此係統的複雜度也被提升了。 例如下圖，`訂單DB_1`、`訂單DB_1`、`訂單DB_3` 三個資料庫內有完全相同的表 `order`，我們在訪問某一筆訂單時可以通過對訂單的訂單編號取模的方式 `訂單編號 mod 3 （資料庫例項數）` ，指定該訂單應該在哪個資料庫中操作。  ### 2、水平分表 水平分表是在**同一個資料庫內**，把一張大資料量的表按一定規則，切分成多個結構完全相同表，而每個表只存原表的一部分資料。 例如：一張 `order` 訂單表有 900萬資料，經過水平拆分出來三個表，`order_1`、`order_2`、`order_3`，每張表存有資料 300萬，以此類推。  水平分表儘管拆分了表，但子表都還是在同一個資料庫例項中，只是解決了單一表資料量過大的問題，並沒有將拆分後的表分散到不同的機器上，還在競爭同一個物理機的CPU、記憶體、網路IO等。要想進一步提升效能，就需要將拆分後的表分散到不同的資料庫中，達到分散式的效果。  **水平切分的優點：** - 解決高併發時單庫資料量過大的問題，提升系統穩定性和負載能力。 - 業務系統改造的工作量不是很大。 **水平切分的缺點：** - 跨分片的事務一致性難以保證。 - 跨庫的join關聯查詢效能較差。 - 擴容的難度和維護量較大，（拆分成幾千張子表想想都恐怖）。 --- ## 一定規則是什麼 我們上邊提到過很多次 `一定規則` ，這個規則其實是一種路由演算法，就是決定一條資料具體應該存在哪個資料庫的哪張表裡。 常見的有 `取模演算法` 和 `範圍限定演算法` ### 1、取模演算法 按欄位取模（對hash結果取餘數 (hash() mod N)，N為資料庫例項數或子表數量）是最為常見的一種切分方式。 還拿 `order` 訂單表舉例，先對資料庫從 0 到 N-1進行編號，對 `order` 訂單表中 `work_no` 訂單編號欄位進行取模，得到餘數 `i`，`i=0`存第一個庫，`i=1`存第二個庫，`i=2`存第三個庫....以此類推。 這樣同一筆訂單的資料都會存在同一個庫、表裡，查詢時用相同的規則，用 `work_no` 訂單編號作為查詢條件，就能快速的定位到資料。 **優點：** - 資料分片相對比較均勻，不易出現請求都打到一個庫上的情況。 **缺點：** - 這種演算法存在一些問題，當某一臺機器宕機，本應該落在該資料庫的請求就無法得到正確的處理，這時宕掉的例項會被踢出叢集，此時演算法變成hash(userId) mod N-1，使用者資訊可能就不再在同一個庫中了。 ### 2、範圍限定演算法 按照 `時間區間` 或 `ID區間` 來切分，比如：我們切分的是使用者表，可以定義每個庫的 `User` 表裡只存10000條資料，第一個庫只存 `userId` 從1 ~ 9999的資料，第二個庫存 `userId` 為10000 ~ 20000，第三個庫存 `userId` 為 20001~ 30000......以此類推，按時間範圍也是同理。 **優點：** - 單表資料量是可控的 - 水平擴充套件簡單隻需增加節點即可，無需對其他分片的資料進行遷移 - 能快速定位要查詢的資料在哪個庫 **缺點：** - 由於連續分片可能存在資料熱點，比如按時間欄位分片，可能某一段時間內訂單驟增，可能會被頻繁的讀寫，而有些分片儲存的歷史資料，則很少被查詢。 ## 分庫分表的難點 ### 1、分散式事務 由於表分佈在不同庫中，不可避免會帶來跨庫事務問題。一般可使用 "`三階段提交` "和 "`兩階段提交`" 處理，但是這種方式效能較差，程式碼開發量也比較大。通常做法是做到最終一致性的方案，如果不苛求系統的實時一致性，只要在允許的時間段內達到最終一致性即可，採用事務補償的方式。 這裡我應用阿里的分散式事務框架`Seata` 來做分散式事務的管理，後邊會結合實際案例。 ### 2、分頁、排序、跨庫聯合查詢 分頁、排序、聯合查詢是開發中使用頻率非常高的功能，但在分庫分表後，這些看似普通的操作卻是讓人非常頭疼的問題。將分散在不同庫中表的資料查詢出來，再將所有結果進行彙總整理後提供給使用者。 ### 3、分散式主鍵 分庫分表後資料庫的自增主鍵意義就不大了，因為我們不能依靠單個數據庫例項上的自增主鍵來實現不同資料庫之間的全域性唯一主鍵，此時一個能夠生成全域性唯一ID的系統是非常必要的，那麼這個全域性唯一ID就叫 `分散式ID`。 ### 4、讀寫分離 不難發現大部分主流的關係型資料庫都提供了主從架構的高可用方案，而我們需要實現 `讀寫分離` + `分庫分表`，讀庫與寫庫都要做分庫分表處理，後邊會有具體實戰案例。 ### 5、資料脫敏 資料脫敏，是指對某些敏感資訊通過脫敏規則進行資料轉換，從而實現敏感隱私資料的可靠保護，如身份證號、手機號、卡號、賬號密碼等個人資訊，一般這些都需要進行做脫敏處理。 ## 分庫分表工具 我還是那句話，儘量不要自己造輪子，因為自己造的輪子可能不那麼圓，業界已經有了很多比較成熟的分庫分表中介軟體，我們根據自身的業務需求挑選，將更多的精力放在業務實現上。 - `sharding-jdbc`（噹噹） - `TSharding`（蘑菇街） - `Atlas`（奇虎360） - `Cobar`（阿里巴巴） - `MyCAT`（基於Cobar） - `Oceanus`（58同城） - `Vitess`（谷歌） ## 為什麼選 sharding-jdbc `sharding-jdbc` 是一款輕量級 `Java` 框架，以 `jar` 包形式提供服務，是屬於客戶端產品不需要額外部署，它相當於是個增強版的 `JDBC` 驅動；相比之下像 `Mycat` 這類需要單獨的部署服務的服務端產品，就稍顯複雜了。況且我想把更多精力放在實現業務，不想做額外的運維工作。 - `sharding-jdbc`的相容性也非常強大，適用於任何基於 `JDBC` 的 `ORM` 框架，如：`JPA`， `Hibernate`，`Mybatis`，`Spring JDBC Template` 或直接使用的 `JDBC`。 - 完美相容任何第三方的資料庫連線池，如：`DBCP`， `C3P0`， `BoneCP`，`Druid`， `HikariCP` 等，幾乎對所有關係型資料庫都支援。 不難發現確實是比較強大的一款工具，而且它對專案的侵入性很小，幾乎不用做任何程式碼層的修改，也無需修改 `SQL` 語句，只需配置待分庫分表的資料表即可。 ## 總結 簡單的回顧一下分庫分表的基礎知識，接下來的文章會配合實戰專案介紹 `sharding-jdbc` 在分庫分表中的各個功能點。 整理了幾百本各類技術電子書，送給小夥伴們。關注公號回覆【666】自行領取。和一些小夥伴們建了一個技術交流群，一起探討技術、分享技術資料，旨在共同學習進步，如果感興趣就加入我們吧！ ![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20200828110008952.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnpoaWZ1MQ==,size_16,color_FFFFFF,t_70#pic_