JAVA前線

歡迎大家關(guān)注公眾號(hào)「JAVA前線」查看更多精彩分享，主要內(nèi)容包括源碼分析、實(shí)際應(yīng)用、架構(gòu)思維、職場(chǎng)分享、產(chǎn)品思考等等，同時(shí)也非常歡迎大家加我微信「java_front」一起交流學(xué)習(xí)

1 理論知識(shí)

1.1 分庫(kù)分表是否必要

分庫(kù)分表確實(shí)可以解決單表數(shù)據(jù)量大這個(gè)問(wèn)題，但是并非首選。因?yàn)榉謳?kù)分表至少引入了三個(gè)必須解決的突出問(wèn)題。

第一是分庫(kù)分表方案本身具有的復(fù)雜性。第二是本地事務(wù)失效問(wèn)題，原本在同一個(gè)數(shù)據(jù)庫(kù)中可以保證強(qiáng)一致性業(yè)務(wù)邏輯，分庫(kù)之后事務(wù)失效。第三是難以聚合查詢問(wèn)題，因?yàn)榉謳?kù)分表后查詢條件中必須帶有shardingKey，所以限制了很多查詢場(chǎng)景。

在之前文章《面試官問(wèn)單表數(shù)據(jù)量大是否必須分庫(kù)分表》介紹過(guò)解決單表數(shù)據(jù)量過(guò)大問(wèn)題，可以按照刪、換、分、拆、異、熱這六個(gè)字順序進(jìn)行處理，而不是首選分庫(kù)分表。

刪是指刪除歷史數(shù)據(jù)并進(jìn)行歸檔。換是指不要只使用數(shù)據(jù)庫(kù)資源，有些數(shù)據(jù)可以存儲(chǔ)至其它替代資源。分是指讀寫(xiě)分離，增加多個(gè)讀實(shí)例應(yīng)對(duì)讀多寫(xiě)少的互聯(lián)網(wǎng)場(chǎng)景。拆是指分庫(kù)分表，將數(shù)據(jù)分散至不同的庫(kù)表中減輕壓力。異指數(shù)據(jù)異構(gòu)，將一份數(shù)據(jù)根據(jù)不同業(yè)務(wù)需求保存多份。熱是指熱點(diǎn)數(shù)據(jù)，這是一個(gè)非常值得注意的問(wèn)題。

1.2 分庫(kù)分表兩大維度

假設(shè)有一個(gè)電商數(shù)據(jù)庫(kù)存放訂單、商品、支付三張業(yè)務(wù)表。隨著業(yè)務(wù)量越來(lái)越大，這三張業(yè)務(wù)數(shù)據(jù)表也越來(lái)越大，查詢性能顯著降低，數(shù)據(jù)拆分勢(shì)在必行，那么數(shù)據(jù)拆分可以從縱向和橫向兩個(gè)維度進(jìn)行。

1.2.1 縱向拆分

縱向拆分就是按照業(yè)務(wù)拆分，我們將電商數(shù)據(jù)庫(kù)拆分成三個(gè)庫(kù)，訂單庫(kù)、商品庫(kù)。支付庫(kù)，訂單表在訂單庫(kù)，商品表在商品庫(kù)，支付表在支付庫(kù)。這樣每個(gè)庫(kù)只需要存儲(chǔ)本業(yè)務(wù)數(shù)據(jù)，物理隔離不會(huì)互相影響。

1.2.2 橫向拆分

按照縱向拆分方案，現(xiàn)在我們已經(jīng)有三個(gè)庫(kù)了，平穩(wěn)運(yùn)行了一段時(shí)間。但是隨著業(yè)務(wù)增長(zhǎng)，每個(gè)單庫(kù)單表的數(shù)據(jù)量也越來(lái)越大，逐漸到達(dá)瓶頸。

這時(shí)我們就要對(duì)數(shù)據(jù)表進(jìn)行橫向拆分，所謂橫向拆分就是根據(jù)某種規(guī)則將單庫(kù)單表數(shù)據(jù)分散到多庫(kù)多表，從而減小單庫(kù)單表的壓力。

橫向拆分策略有很多方案，最重要的一點(diǎn)是選好ShardingKey，也就是按照哪一列進(jìn)行拆分，怎么分取決于我們?cè)L問(wèn)數(shù)據(jù)的方式。

(1) 范圍分片

如果選擇的ShardingKey是訂單創(chuàng)建時(shí)間，那么分片策略是拆分四個(gè)數(shù)據(jù)庫(kù)，分別存儲(chǔ)每季度數(shù)據(jù)，每個(gè)庫(kù)包含三張表，分別存儲(chǔ)每個(gè)月數(shù)據(jù)：

這個(gè)方案的優(yōu)點(diǎn)是對(duì)范圍查詢比較友好，例如我們需要統(tǒng)計(jì)第一季度的相關(guān)數(shù)據(jù)，查詢條件直接輸入時(shí)間范圍即可。這個(gè)方案的問(wèn)題是容易產(chǎn)生熱點(diǎn)數(shù)據(jù)。例如雙11當(dāng)天下單量特別大，就會(huì)導(dǎo)致11月這張表數(shù)據(jù)量特別大從而造成訪問(wèn)壓力。

(2) 查表分片

查表法是根據(jù)一張路由表決定ShardingKey路由到哪一張表，每次路由時(shí)首先到路由表里查到分片信息，再到這個(gè)分片去取數(shù)據(jù)。我們分析一個(gè)查表法思想應(yīng)用實(shí)際案例。

Redis官方在3.0版本之后提供了集群方案RedisCluster，其中引入了哈希槽（slot）這個(gè)概念。一個(gè)集群固定有16384個(gè)槽，在集群初始化時(shí)這些槽會(huì)平均分配到Redis集群節(jié)點(diǎn)上。每個(gè)key請(qǐng)求最終落到哪個(gè)槽計(jì)算公式是固定的：

SLOT = CRC16(key) mod 16384

一個(gè)key請(qǐng)求過(guò)來(lái)怎么知道去哪臺(tái)Redis節(jié)點(diǎn)獲取數(shù)據(jù)？這就要用到查表法思想：

(1) 客戶端連接任意一臺(tái)Redis節(jié)點(diǎn)，假設(shè)隨機(jī)訪問(wèn)到節(jié)點(diǎn)A
(2) 節(jié)點(diǎn)A根據(jù)key計(jì)算出slot值
(3) 每個(gè)節(jié)點(diǎn)都維護(hù)著slot和節(jié)點(diǎn)映射關(guān)系表
(4) 如果節(jié)點(diǎn)A查表發(fā)現(xiàn)該slot在本節(jié)點(diǎn)，直接返回?cái)?shù)據(jù)給客戶端
(5) 如果節(jié)點(diǎn)A查表發(fā)現(xiàn)該slot不在本節(jié)點(diǎn)，返回給客戶端一個(gè)重定向命令，告訴客戶端應(yīng)該去哪個(gè)節(jié)點(diǎn)請(qǐng)求這個(gè)key的數(shù)據(jù)
(6) 客戶端向正確節(jié)點(diǎn)發(fā)起連接請(qǐng)求

查表法方案優(yōu)點(diǎn)是可以靈活制定路由策略，如果我們發(fā)現(xiàn)有的分片已經(jīng)成為熱點(diǎn)則修改路由策略。缺點(diǎn)是多一次查詢路由表操作增加耗時(shí)，而且路由表如果是單點(diǎn)也可能會(huì)有單點(diǎn)問(wèn)題。

(3) 哈希分片

相較于范圍分片，哈希分片可以較為均勻?qū)?shù)據(jù)分散在數(shù)據(jù)庫(kù)中。我們現(xiàn)在將訂單庫(kù)拆分為4個(gè)庫(kù)編號(hào)為[0,3]，每個(gè)庫(kù)包含3張表編號(hào)為[0,2]，如下圖如所示：

我們選擇使用orderId作為ShardingKey，那么orderId=100這個(gè)訂單會(huì)保存在哪張表？因?yàn)槭欠謳?kù)分表，第一步確定路由到哪一個(gè)庫(kù)，取模計(jì)算結(jié)果表示庫(kù)表序號(hào)：

db_index = 100 % 4 = 0

第二步確定路由到哪一張表：

table_index = 100 % 3 = 1

第三步數(shù)據(jù)路由到0號(hào)庫(kù)1號(hào)表：

在實(shí)際開(kāi)發(fā)中路由邏輯并不需要我們手動(dòng)實(shí)現(xiàn)，因?yàn)橛性S多開(kāi)源框架通過(guò)配置就可以實(shí)現(xiàn)路由功能，例如ShardingSphere、TDDL框架等等。

2 分庫(kù)分表準(zhǔn)備工作

2.1 計(jì)算庫(kù)表數(shù)量

分幾個(gè)庫(kù)和幾張表是在分庫(kù)分表工作開(kāi)始前必須要回答的問(wèn)題，我們首先看看阿里巴巴開(kāi)發(fā)手冊(cè)的建議：?jiǎn)伪硇袛?shù)超過(guò)500萬(wàn)行或者單表容量超過(guò)2GB才推薦進(jìn)行分庫(kù)分表，如果預(yù)計(jì)3年后數(shù)據(jù)量根本達(dá)不到這個(gè)級(jí)別，請(qǐng)不要在創(chuàng)建表時(shí)就分庫(kù)分表。我們提取出這個(gè)建議的兩個(gè)關(guān)鍵詞：500萬(wàn)、3年，作為預(yù)估庫(kù)表數(shù)的基線。假設(shè)業(yè)務(wù)數(shù)據(jù)日增量60萬(wàn)，那么應(yīng)該如何預(yù)估需要分多少個(gè)庫(kù)和多少?gòu)埍砟兀?/span>

日增量60萬(wàn)計(jì)算3年后數(shù)據(jù)總量：

三年數(shù)據(jù)總量 = 60 * 365 * 3 = 65700

隨著后續(xù)業(yè)務(wù)發(fā)展日增量會(huì)超過(guò)60萬(wàn)，所以我們要對(duì)數(shù)據(jù)總量進(jìn)行冗余，冗余指數(shù)是多少根據(jù)業(yè)務(wù)情況而定，本文按照3倍冗余：

三年數(shù)據(jù)總量三倍冗余 = 65700 * 3 = 197100

單表500萬(wàn)并向上取整至2的冪次計(jì)算表數(shù)量：

表數(shù)量 = 197100 / 500 = 394.2 向上取整 = 512

所有表放在一個(gè)庫(kù)并不合適，因?yàn)殡S著數(shù)據(jù)量增大，訪問(wèn)并發(fā)量也會(huì)呈正相關(guān)增大，一個(gè)數(shù)據(jù)庫(kù)實(shí)例是難以支撐的。本文按照一個(gè)數(shù)據(jù)庫(kù)實(shí)例包含32張表計(jì)算庫(kù)數(shù)量：

庫(kù)數(shù)量 = 512 / 32 = 16

2.2 shardingKey

確定shardingKey非常關(guān)鍵，因?yàn)樽鳛榉制笜?biāo)，當(dāng)數(shù)據(jù)拆分至多個(gè)庫(kù)表之后，代理層只能根據(jù)shardingKey進(jìn)行表路由。

假設(shè)我們?cè)O(shè)置了userId作為shardingKey，那么后續(xù)DML操作都必須包含userId字段。但是現(xiàn)在有一種場(chǎng)景只有orderId作為查詢條件，那么我們應(yīng)該如何處理這種場(chǎng)景呢？

第一種方案是設(shè)計(jì)orderId包含userId相關(guān)特征，這樣即使只有訂單號(hào)作為查詢條件，也可以截取userId特征進(jìn)行分片：

訂單號(hào) = 毫秒數(shù) + 版本號(hào) + userId后六位 + 全局序列號(hào)

第二種方案是數(shù)據(jù)異構(gòu)，核心思想是以空間換時(shí)間，一份數(shù)據(jù)根據(jù)不同維度存儲(chǔ)到多個(gè)數(shù)據(jù)介質(zhì)，數(shù)據(jù)異構(gòu)一般分為如下類型。

數(shù)據(jù)異構(gòu)至MySQL：我們可以選擇orderId作為shardingKey存儲(chǔ)至另一個(gè)數(shù)據(jù)庫(kù)實(shí)例，那么orderId就可以作為條件進(jìn)行查詢。

數(shù)據(jù)異構(gòu)至ES：如果每一個(gè)維度都新建一個(gè)數(shù)據(jù)庫(kù)實(shí)例也是不現(xiàn)實(shí)的，所以我們可以將數(shù)據(jù)同步至ES滿足多維度查詢需求。

數(shù)據(jù)異構(gòu)至Hive：MySQL和ES可以滿足實(shí)時(shí)查詢需求，Hive可以滿足離線分析需求，數(shù)據(jù)分析工作無(wú)需通過(guò)主庫(kù)，而是可以通過(guò)Hive進(jìn)行。

現(xiàn)在又引出一個(gè)新問(wèn)題，業(yè)務(wù)不可能每次都將數(shù)據(jù)寫(xiě)入多個(gè)數(shù)據(jù)源，這樣會(huì)帶來(lái)性能和數(shù)據(jù)一致性問(wèn)題，所以需要一個(gè)管道進(jìn)行各數(shù)據(jù)源之間同步，阿里開(kāi)源canal組件可以解決這個(gè)問(wèn)題。

3 分庫(kù)分表實(shí)例

在完成準(zhǔn)備工作之后，我們可以開(kāi)始分庫(kù)分表工作了。分庫(kù)分表方法有很多種，但是說(shuō)到底都是在處理兩類數(shù)據(jù)：存量和增量。存量表示舊數(shù)據(jù)庫(kù)已經(jīng)存在的數(shù)據(jù)，增量表示不存在于舊數(shù)據(jù)庫(kù)待新增或者變更的數(shù)據(jù)。根據(jù)存量和增量這兩種類型，我們可以將分庫(kù)分表方法分為停服拆分和不停服拆分。

3.1 停服拆分

停服是指停止服務(wù)，系統(tǒng)不再接收新業(yè)務(wù)數(shù)據(jù)，那么舊數(shù)據(jù)在分庫(kù)分表這個(gè)時(shí)間段內(nèi)是靜止不變的，數(shù)據(jù)全部變?yōu)榱舜媪繑?shù)據(jù)。停服拆分一般分為三個(gè)階段。

第一階段首先編寫(xiě)代理層和新DAO，代理層通過(guò)動(dòng)態(tài)開(kāi)關(guān)決定訪問(wèn)舊表還是新表，此時(shí)流量還是全部訪問(wèn)舊表：

第二階段停止服務(wù)，整個(gè)應(yīng)用都沒(méi)有流量，舊表數(shù)據(jù)已經(jīng)處于靜止?fàn)顟B(tài)，通過(guò)腳本將存量數(shù)據(jù)分頁(yè)從舊表遷移至新表：

第三階段通過(guò)代理層訪問(wèn)新表：

3.2 不停服拆分

停服拆分方案比較簡(jiǎn)單，但是在分表這段時(shí)間沒(méi)有業(yè)務(wù)流量，對(duì)業(yè)務(wù)是有損的，所以我們一般采用不停服拆分方案，一邊有流量訪問(wèn)，一邊進(jìn)行分庫(kù)分表，此時(shí)數(shù)據(jù)不僅有存量還有增量，相對(duì)而言會(huì)復(fù)雜一些。

第一階段首先編寫(xiě)代理層和新DAO，代理層通過(guò)動(dòng)態(tài)開(kāi)關(guān)決定訪問(wèn)舊表還是新表，此時(shí)流量還是全部訪問(wèn)舊表：

第二階段開(kāi)啟雙寫(xiě)，增量數(shù)據(jù)不僅在舊表新增和修改，也在新表新增和修改，日志或者臨時(shí)表記錄寫(xiě)入新表ID起始值，舊表中小于這個(gè)值的數(shù)據(jù)就是存量數(shù)據(jù)：

第三階段進(jìn)行存量數(shù)據(jù)同步，通過(guò)腳本將存量數(shù)據(jù)分頁(yè)寫(xiě)入新表：

第四階段停讀舊表改讀新表，此時(shí)新表已經(jīng)承載了所有讀寫(xiě)業(yè)務(wù)，但是不要立刻停寫(xiě)舊表，需要保持雙寫(xiě)一段時(shí)間。

不停寫(xiě)舊表有兩個(gè)原因：第一是因?yàn)槿绻x新表出現(xiàn)問(wèn)題，還可以將讀流量切回舊表。第二是因?yàn)榭梢赃M(jìn)行數(shù)據(jù)校對(duì)，例如新表和舊表數(shù)據(jù)都同步至Hive，選取幾天的數(shù)據(jù)進(jìn)行校對(duì)，從而驗(yàn)證數(shù)據(jù)同步準(zhǔn)確性。

第五階段當(dāng)讀寫(xiě)新表一段時(shí)間之后，沒(méi)有發(fā)生業(yè)務(wù)問(wèn)題則可以停寫(xiě)舊表：

3.3 代理層實(shí)現(xiàn)

代理層實(shí)現(xiàn)了新舊數(shù)據(jù)源切換，需要盡量減少業(yè)務(wù)層代碼的侵入性，而適配器模式可以有效減少對(duì)業(yè)務(wù)層的侵入性。我們首先看看舊數(shù)據(jù)訪問(wèn)對(duì)象和業(yè)務(wù)服務(wù)：

// 訂單數(shù)據(jù)對(duì)象
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ù)源訪問(wèn)對(duì)象：

// 新數(shù)據(jù)對(duì)象
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é)

分庫(kù)分表具有三個(gè)必須面對(duì)的突出問(wèn)題：方案本身復(fù)雜性、本地事務(wù)失效問(wèn)題、難以聚合查詢問(wèn)題，所以分庫(kù)分表方案并非解決海量數(shù)據(jù)問(wèn)題的首選方案，這一點(diǎn)非常值得注意。

如果必須分庫(kù)分表，我們首先進(jìn)行容量預(yù)估并選擇合適的shardingKey，其次根據(jù)實(shí)際業(yè)務(wù)選擇停服或者不停服方案，如果選擇不停服方案，注意保持新表和舊表雙寫(xiě)一段時(shí)間，從而驗(yàn)證數(shù)據(jù)準(zhǔn)確性，希望本文對(duì)大家有所幫助。

5 延伸閱讀

一種簡(jiǎn)單可落地的分布式事務(wù)方案

面試官問(wèn)單表數(shù)據(jù)量大是否必須分庫(kù)分表