微服務-分庫分表思路

學習思路

1. 業務初期單庫優缺點
2. 什麼時候開始選擇分庫分表，具體實現方案
3. sharding-jdbc原理講解
4. sharding-jdbc實現方案

一、業務初期單庫優缺點

業界傳爛的一句話：能不分庫分表就不分庫分表；帶着句話我們來分析一下單庫

優點：

1. 實現簡單，只需要簡單配置數據源
2. 事物控制簡單，可以保證強一致性
3. 數據查詢簡單，不需要依賴第三方聚合工具

缺點：

1. 初期無缺點
2. 如果達到一定數據量，單庫可能存在瓶頸

回到第一句話，業務初期快速試錯的階段，數據量肯定不大，架構設計一定要簡單快速，所以單庫對於初期既簡單快速又安全，無缺點，無需過度設計

二、什麼時候開始選擇分庫分表，具體實現方案-mysql

初期數據庫配置一般是一主一從，甚至沒有讀寫分離從庫只是簡單的備份和故障轉移

如果單表數據量在1000W一下時可以通過索引優化，sql優化，添加從庫等途徑進行提高，但到達1000W以上我們就要考慮分庫分表了，那麼我們是考慮分庫呢還是分表呢？帶着問題我們來看

適合分表：

         當單表數據量到達1000W但，併發訪問量並不是很高（沒有觸發系統瓶頸）那麼可以選擇分表

題外話：這種情況一般不存在，數據量和訪問量一般稱正比

適合分庫：

        當單表數據量達到1000W，並且併發量已觸發系統瓶頸

題外話：在不考慮服務資源的前提下，分表能分擔之前單表的訪問壓力，提高效率，如果服務器資源成爲瓶頸那麼分再多的表也解決不了任何問題，只能考慮分庫

我們知道了什麼時候該分表，什麼時候分庫，接下來我們該按什麼策略進行分庫分表呢（橫向拆分、縱向拆分）

1、分表策略

縱向拆分：

       當單表字段量太大，並且明顯能區分出使用頻率和是否重要，那麼需要考慮縱向拆分，將一個表拆分爲多個，也就是俗稱的按業務拆分，

缺點：這種操作一旦上線很難操作，數據初期設計缺陷，應在評審階段屏蔽，實際單表數據量還是沒變，並不能減少單表訪問量

優點：減少查詢的單表字段，業務數據更清晰，查詢數據較多時可防止多頁存儲

橫向拆分：

     該拆分方式就是將所有數據拆成多份，分開存儲，真正解決了單表的訪問壓力（例如1000W分爲10個表一個表100W）

優點：將之前的單表壓力分散到多個表，操作無壓力

缺點：

1. 一次查詢操作數據存在多個表怎麼查詢
2. 併發量大了之後，雖然單表無壓力，但數據庫資源將成爲瓶頸，仍然無法解決問題
3. 技術難度-是否可以無數據遷移增加新表

2、分庫策略

縱向拆分：

業務初期受各種資源限制一般只有一個庫，所有的業務相對耦合，業務試錯成功後快速發展迭代、、、很多原因，我們應該考慮業務拆分，業務拆分的同時數據也會同步拆分（每個業務有自己獨立的庫表）

優點：

1、業務解耦，數據解耦（一般都是整表拆出來）

2、分散了單庫的壓力

缺點：

1、多個系統多個庫，出現分佈式事物難以控制

2、系統複雜度增加，一次查詢可能跨庫

3、並沒有解決單表壓力

總結：

1. 雖然初期使用一個庫，但表結構一定要設計好，按業務隔離好，否則後面業務沒法拆
2. 縱向拆分雖然不能解決單表壓力，但很有必要，一般在業務試錯成功後隨業務一起拆分
3. 後面說的橫向拆分一般在縱向拆分的基礎上去做
4. 縱向拆分的階段單表數據量應該還沒有成爲瓶頸

橫向拆分：

當縱向拆完之後，數據量暴增，單表成爲瓶頸（雖然上面已經分析了分表，具體該分表還是分庫我們後面總結，這裏只講分庫），我們現在考慮將一個庫的數據拆解到多個庫進行分散壓力

缺點：

1、一次操作跨多個庫的問題

2、跨庫事物的問題

3、代碼複雜度的問題：主鍵生成，分庫策略，水平擴展等都需要考慮

優點：

1、徹底解決了庫表的操作壓力

3、到底該用什麼方式

我們來按階段對標一下適應方式

1. 試錯期間：單系統-單庫-主從讀寫分離
2. 試錯成功：多系統-多庫（縱向拆分）-主從讀寫分離
3. 單表1000W：多系統-多庫-主從分離
   1. 歷史表：比如只支持查詢3個月的數據，3個月以後的數據可移入歷史表備份，當然還可以給歷史表按時間做分區
   2. 庫橫向拆分：可以將數據量比較大的表按一定分片規則進行拆分，其它數據量比較固定的表置爲全局表，分片規則後面講
   3. 表橫向拆分：暫時沒有實踐過可補充：猜想：在庫橫向分片後如果其中一張表數據量遠遠大於其它表可進行單獨分表

4、分片算法

我們知道了橫向分庫分表時將一個變爲多個，所以實際操作哪個庫表時需要有一定的分片鍵，根據一定的分片算法選擇相應的庫表下面我們介紹常用的集中算法

1. 分片鍵取模算法
   1. 比如用戶表按用戶id對10取模，用戶就會平均分配到不同的10個表
   2. 適用場景，能相對預估數據量，比如用戶表分表10*1000W這個用戶量很牛了
   3. 缺點：表數量固定，如果將來想新增表，需要按照分片鍵、分片規則重新洗數據
2. 數據分段-分片字段用戶id
   1. 比如1-1000W放入A庫；1000W-2000W放入B庫依次類推(當然數據量可適當減小比如500W一個庫)
   2. 好處是隻需要根據用戶量不斷新增分片即可
   3. 缺點：數據訪問熱度不一樣，可能B庫活躍用戶多訪問頻繁
3. 時間分段-分片字段用時間生成的用戶id（Twitter-Snowflake：俗稱雪花算法）
   1. 可解析用戶id生成時間，可按半年分一個庫（這裏的半年可根據業務量和增長預估自定義）
   2. 好處：擴容簡單，後面擴容只需要按時間段不斷新建庫即可，分片算法簡單
   3. 缺點：數據分佈不均勻、訪問熱度問題
4. 一致性哈希算法（Consistent Hashing）：一致性hash算法

下篇更新sharding-jdbc

 

公衆號主要記錄各種源碼、面試題、微服務技術棧，幫忙關注一波，非常感謝