多圖詳解：如何不停服分庫分表
JAVA前線
歡迎大家關(guān)注公眾號「JAVA前線」查看更多精彩分享，主要內(nèi)容包括源碼分析、實際應(yīng)用、架構(gòu)思維、職場分享、產(chǎn)品思考等等，同時也非常歡迎大家加我微信「java_front」一起交流學(xué)習(xí)
1 理論知識
1.1 分庫分表是否必要
分庫分表確實可以解決單表數(shù)據(jù)量大這個問題，但是并非首選。因為分庫分表至少引入了三個必須解決的突出問題。
第一是分庫分表方案本身具有的復(fù)雜性。第二是本地事務(wù)失效問題，原本在同一個數(shù)據(jù)庫中可以保證強一致性業(yè)務(wù)邏輯，分庫之后事務(wù)失效。第三是難以聚合查詢問題，因為分庫分表后查詢條件中必須帶有shardingKey，所以限制了很多查詢場景。
在之前文章《面試官問單表數(shù)據(jù)量大是否必須分庫分表》介紹過解決單表數(shù)據(jù)量過大問題，可以按照刪、換、分、拆、異、熱這六個字順序進行處理，而不是首選分庫分表。
刪是指刪除歷史數(shù)據(jù)并進行歸檔。換是指不要只使用數(shù)據(jù)庫資源，有些數(shù)據(jù)可以存儲至其它替代資源。分是指讀寫分離，增加多個讀實例應(yīng)對讀多寫少的互聯(lián)網(wǎng)場景。拆是指分庫分表，將數(shù)據(jù)分散至不同的庫表中減輕壓力。異指數(shù)據(jù)異構(gòu)，將一份數(shù)據(jù)根據(jù)不同業(yè)務(wù)需求保存多份。熱是指熱點數(shù)據(jù)，這是一個非常值得注意的問題。
1.2 分庫分表兩大維度
假設(shè)有一個電商數(shù)據(jù)庫存放訂單、商品、支付三張業(yè)務(wù)表。隨著業(yè)務(wù)量越來越大，這三張業(yè)務(wù)數(shù)據(jù)表也越來越大，查詢性能顯著降低，數(shù)據(jù)拆分勢在必行，那么數(shù)據(jù)拆分可以從縱向和橫向兩個維度進行。
1.2.1 縱向拆分
縱向拆分就是按照業(yè)務(wù)拆分，我們將電商數(shù)據(jù)庫拆分成三個庫，訂單庫、商品庫。支付庫，訂單表在訂單庫，商品表在商品庫，支付表在支付庫。這樣每個庫只需要存儲本業(yè)務(wù)數(shù)據(jù)，物理隔離不會互相影響。
1.2.2 橫向拆分
按照縱向拆分方案，現(xiàn)在我們已經(jīng)有三個庫了，平穩(wěn)運行了一段時間。但是隨著業(yè)務(wù)增長，每個單庫單表的數(shù)據(jù)量也越來越大，逐漸到達瓶頸。
這時我們就要對數(shù)據(jù)表進行橫向拆分，所謂橫向拆分就是根據(jù)某種規(guī)則將單庫單表數(shù)據(jù)分散到多庫多表，從而減小單庫單表的壓力。
橫向拆分策略有很多方案，最重要的一點是選好ShardingKey，也就是按照哪一列進行拆分，怎么分取決于我們訪問數(shù)據(jù)的方式。
(1) 范圍分片
如果選擇的ShardingKey是訂單創(chuàng)建時間，那么分片策略是拆分四個數(shù)據(jù)庫，分別存儲每季度數(shù)據(jù)，每個庫包含三張表，分別存儲每個月數(shù)據(jù)：
這個方案的優(yōu)點是對范圍查詢比較友好，例如我們需要統(tǒng)計第一季度的相關(guān)數(shù)據(jù)，查詢條件直接輸入時間范圍即可。這個方案的問題是容易產(chǎn)生熱點數(shù)據(jù)。例如雙11當(dāng)天下單量特別大，就會導(dǎo)致11月這張表數(shù)據(jù)量特別大從而造成訪問壓力。
(2) 查表分片
查表法是根據(jù)一張路由表決定ShardingKey路由到哪一張表，每次路由時首先到路由表里查到分片信息，再到這個分片去取數(shù)據(jù)。我們分析一個查表法思想應(yīng)用實際案例。
Redis官方在3.0版本之后提供了集群方案RedisCluster，其中引入了哈希槽（slot）這個概念。一個集群固定有16384個槽，在集群初始化時這些槽會平均分配到Redis集群節(jié)點上。每個key請求最終落到哪個槽計算公式是固定的：
SLOT = CRC16(key) mod 16384
一個key請求過來怎么知道去哪臺Redis節(jié)點獲取數(shù)據(jù)？這就要用到查表法思想：
(1) 客戶端連接任意一臺Redis節(jié)點，假設(shè)隨機訪問到節(jié)點A
(2) 節(jié)點A根據(jù)key計算出slot值
(3) 每個節(jié)點都維護著slot和節(jié)點映射關(guān)系表
(4) 如果節(jié)點A查表發(fā)現(xiàn)該slot在本節(jié)點，直接返回數(shù)據(jù)給客戶端
(5) 如果節(jié)點A查表發(fā)現(xiàn)該slot不在本節(jié)點，返回給客戶端一個重定向命令，告訴客戶端應(yīng)該去哪個節(jié)點請求這個key的數(shù)據(jù)
(6) 客戶端向正確節(jié)點發(fā)起連接請求
查表法方案優(yōu)點是可以靈活制定路由策略，如果我們發(fā)現(xiàn)有的分片已經(jīng)成為熱點則修改路由策略。缺點是多一次查詢路由表操作增加耗時，而且路由表如果是單點也可能會有單點問題。
(3) 哈希分片
相較于范圍分片，哈希分片可以較為均勻?qū)?shù)據(jù)分散在數(shù)據(jù)庫中。我們現(xiàn)在將訂單庫拆分為4個庫編號為[0,3]，每個庫包含3張表編號為[0,2]，如下圖如所示：
我們選擇使用orderId作為ShardingKey，那么orderId=100這個訂單會保存在哪張表？因為是分庫分表，第一步確定路由到哪一個庫，取模計算結(jié)果表示庫表序號：
db_index = 100 % 4 = 0
第二步確定路由到哪一張表：
table_index = 100 % 3 = 1
第三步數(shù)據(jù)路由到0號庫1號表：
在實際開發(fā)中路由邏輯并不需要我們手動實現(xiàn)，因為有許多開源框架通過配置就可以實現(xiàn)路由功能，例如ShardingSphere、TDDL框架等等。
2 分庫分表準(zhǔn)備工作
2.1 計算庫表數(shù)量
分幾個庫和幾張表是在分庫分表工作開始前必須要回答的問題，我們首先看看阿里巴巴開發(fā)手冊的建議：單表行數(shù)超過500萬行或者單表容量超過2GB才推薦進行分庫分表，如果預(yù)計3年后數(shù)據(jù)量根本達不到這個級別，請不要在創(chuàng)建表時就分庫分表。我們提取出這個建議的兩個關(guān)鍵詞：500萬、3年，作為預(yù)估庫表數(shù)的基線。假設(shè)業(yè)務(wù)數(shù)據(jù)日增量60萬，那么應(yīng)該如何預(yù)估需要分多少個庫和多少張表呢？
日增量60萬計算3年后數(shù)據(jù)總量：
三年數(shù)據(jù)總量 = 60 * 365 * 3 = 65700
隨著后續(xù)業(yè)務(wù)發(fā)展日增量會超過60萬，所以我們要對數(shù)據(jù)總量進行冗余，冗余指數(shù)是多少根據(jù)業(yè)務(wù)情況而定，本文按照3倍冗余：
三年數(shù)據(jù)總量三倍冗余 = 65700 * 3 = 197100
單表500萬并向上取整至2的冪次計算表數(shù)量：
表數(shù)量 = 197100 / 500 = 394.2 向上取整 = 512
所有表放在一個庫并不合適，因為隨著數(shù)據(jù)量增大，訪問并發(fā)量也會呈正相關(guān)增大，一個數(shù)據(jù)庫實例是難以支撐的。本文按照一個數(shù)據(jù)庫實例包含32張表計算庫數(shù)量：
庫數(shù)量 = 512 / 32 = 16
2.2 shardingKey
確定shardingKey非常關(guān)鍵，因為作為分片指標(biāo)，當(dāng)數(shù)據(jù)拆分至多個庫表之后，代理層只能根據(jù)shardingKey進行表路由。
假設(shè)我們設(shè)置了userId作為shardingKey，那么后續(xù)DML操作都必須包含userId字段。但是現(xiàn)在有一種場景只有orderId作為查詢條件，那么我們應(yīng)該如何處理這種場景呢？
第一種方案是設(shè)計orderId包含userId相關(guān)特征，這樣即使只有訂單號作為查詢條件，也可以截取userId特征進行分片：
訂單號 = 毫秒數(shù) + 版本號 + userId后六位 + 全局序列號
第二種方案是數(shù)據(jù)異構(gòu)，核心思想是以空間換時間，一份數(shù)據(jù)根據(jù)不同維度存儲到多個數(shù)據(jù)介質(zhì)，數(shù)據(jù)異構(gòu)一般分為如下類型。
數(shù)據(jù)異構(gòu)至MySQL：我們可以選擇orderId作為shardingKey存儲至另一個數(shù)據(jù)庫實例，那么orderId就可以作為條件進行查詢。
數(shù)據(jù)異構(gòu)至ES：如果每一個維度都新建一個數(shù)據(jù)庫實例也是不現(xiàn)實的，所以我們可以將數(shù)據(jù)同步至ES滿足多維度查詢需求。
數(shù)據(jù)異構(gòu)至Hive：MySQL和ES可以滿足實時查詢需求，Hive可以滿足離線分析需求，數(shù)據(jù)分析工作無需通過主庫，而是可以通過Hive進行。
現(xiàn)在又引出一個新問題，業(yè)務(wù)不可能每次都將數(shù)據(jù)寫入多個數(shù)據(jù)源，這樣會帶來性能和數(shù)據(jù)一致性問題，所以需要一個管道進行各數(shù)據(jù)源之間同步，阿里開源canal組件可以解決這個問題。
3 分庫分表實例
在完成準(zhǔn)備工作之后，我們可以開始分庫分表工作了。分庫分表方法有很多種，但是說到底都是在處理兩類數(shù)據(jù)：存量和增量。存量表示舊數(shù)據(jù)庫已經(jīng)存在的數(shù)據(jù)，增量表示不存在于舊數(shù)據(jù)庫待新增或者變更的數(shù)據(jù)。根據(jù)存量和增量這兩種類型，我們可以將分庫分表方法分為停服拆分和不停服拆分。
3.1 停服拆分
停服是指停止服務(wù)，系統(tǒng)不再接收新業(yè)務(wù)數(shù)據(jù)，那么舊數(shù)據(jù)在分庫分表這個時間段內(nèi)是靜止不變的，數(shù)據(jù)全部變?yōu)榱舜媪繑?shù)據(jù)。停服拆分一般分為三個階段。
第一階段首先編寫代理層和新DAO，代理層通過動態(tài)開關(guān)決定訪問舊表還是新表，此時流量還是全部訪問舊表：
第二階段停止服務(wù)，整個應(yīng)用都沒有流量，舊表數(shù)據(jù)已經(jīng)處于靜止?fàn)顟B(tài)，通過腳本將存量數(shù)據(jù)分頁從舊表遷移至新表：
第三階段通過代理層訪問新表：
3.2 不停服拆分
停服拆分方案比較簡單，但是在分表這段時間沒有業(yè)務(wù)流量，對業(yè)務(wù)是有損的，所以我們一般采用不停服拆分方案，一邊有流量訪問，一邊進行分庫分表，此時數(shù)據(jù)不僅有存量還有增量，相對而言會復(fù)雜一些。
第一階段首先編寫代理層和新DAO，代理層通過動態(tài)開關(guān)決定訪問舊表還是新表，此時流量還是全部訪問舊表：
第二階段開啟雙寫，增量數(shù)據(jù)不僅在舊表新增和修改，也在新表新增和修改，日志或者臨時表記錄寫入新表ID起始值，舊表中小于這個值的數(shù)據(jù)就是存量數(shù)據(jù)：
第三階段進行存量數(shù)據(jù)同步，通過腳本將存量數(shù)據(jù)分頁寫入新表：
第四階段停讀舊表改讀新表，此時新表已經(jīng)承載了所有讀寫業(yè)務(wù)，但是不要立刻停寫舊表，需要保持雙寫一段時間。
不停寫舊表有兩個原因：第一是因為如果讀新表出現(xiàn)問題，還可以將讀流量切回舊表。第二是因為可以進行數(shù)據(jù)校對，例如新表和舊表數(shù)據(jù)都同步至Hive，選取幾天的數(shù)據(jù)進行校對，從而驗證數(shù)據(jù)同步準(zhǔn)確性。
第五階段當(dāng)讀寫新表一段時間之后，沒有發(fā)生業(yè)務(wù)問題則可以停寫舊表：
3.3 代理層實現(xiàn)
代理層實現(xiàn)了新舊數(shù)據(jù)源切換，需要盡量減少業(yè)務(wù)層代碼的侵入性，而適配器模式可以有效減少對業(yè)務(wù)層的侵入性。我們首先看看舊數(shù)據(jù)訪問對象和業(yè)務(wù)服務(wù)：
// 訂單數(shù)據(jù)對象
public class OrderDO {
private String orderId;
private Long price;
public String getOrderId() {
return orderId;
}
public void setOrderId(String orderId) {
this.orderId = orderId;
}
public Long getPrice() {
return price;
}
public void setPrice(Long price) {
this.price = price;
}
}
// 舊DAO
public interface OrderDAO {
public void insert(OrderDO orderDO);
}
// 業(yè)務(wù)服務(wù)
public class OrderServiceImpl implements OrderService {
@Resource
private OrderDAO orderDAO;
@Override
public String createOrder(Long price) {
String orderId = "orderId_123";
OrderDO orderDO = new OrderDO();
orderDO.setOrderId(orderId);
orderDO.setPrice(price);
orderDAO.insert(orderDO);
return orderId;
}
}
引入新數(shù)據(jù)源訪問對象：
// 新數(shù)據(jù)對象
public class OrderNewDO {
private String orderId;
private Long price;
}
// 新DAO
public interface OrderNewDAO {
public void insert(OrderNewDO orderNewDO);
}
適配器模式減少業(yè)務(wù)代碼侵入性：
// 代理層
public class OrderDAOProxy implements OrderDAO {
private OrderDAO orderDAO;
private OrderNewDAO orderNewDAO;
public OrderDAOProxy(OrderDAO orderDAO, OrderNewDAO orderNewDAO) {
this.orderDAO = orderDAO;
this.orderNewDAO = orderNewDAO;
}
@Override
public void insert(OrderDO orderDO) {
if(ApolloConfig.routeNewDB) {
OrderNewDO orderNewDO = new OrderNewDO();
orderNewDO.setPrice(orderDO.getPrice());
orderNewDO.setOrderId(orderDO.getOrderId());
orderNewDAO.insert(orderNewDO);
} else {
orderDAO.insert(orderDO);
}
}
}
// 業(yè)務(wù)服務(wù)
public class OrderServiceImpl implements OrderService {
@Resource
private OrderDAO orderDAO;
@Resource
private OrderNewDAO orderNewDAO;
@Override
public String createOrder(Long price) {
String orderId = "orderId_123";
OrderDO orderDO = new OrderDO();
orderDO.setOrderId(orderId);
orderDO.setPrice(price);
new OrderDAOProxy(orderDAO, orderNewDAO).insert(orderDO);
return orderId;
}
}
4 文章總結(jié)
分庫分表具有三個必須面對的突出問題：方案本身復(fù)雜性、本地事務(wù)失效問題、難以聚合查詢問題，所以分庫分表方案并非解決海量數(shù)據(jù)問題的首選方案，這一點非常值得注意。
如果必須分庫分表，我們首先進行容量預(yù)估并選擇合適的shardingKey，其次根據(jù)實際業(yè)務(wù)選擇停服或者不停服方案，如果選擇不停服方案，注意保持新表和舊表雙寫一段時間，從而驗證數(shù)據(jù)準(zhǔn)確性，希望本文對大家有所幫助。
5 延伸閱讀
JAVA前線
歡迎大家關(guān)注公眾號「JAVA前線」查看更多精彩分享，主要內(nèi)容包括源碼分析、實際應(yīng)用、架構(gòu)思維、職場分享、產(chǎn)品思考等等，同時也非常歡迎大家加我微信「java_front」一起交流學(xué)習(xí)