[[422085]]

一 背景

訂單系統(tǒng)存在于各行各業(yè)，如電商訂單、銀行流水、運(yùn)營商話費(fèi)賬單等，是一個(gè)非常廣泛、通用的系統(tǒng)。對(duì)于這類系統(tǒng)，在過去十幾年發(fā)展中已經(jīng)形成了經(jīng)典的做法。但是隨著互聯(lián)網(wǎng)的發(fā)展，以及各企業(yè)對(duì)數(shù)據(jù)的重視，需要存儲(chǔ)和持久化的訂單量越來越大，數(shù)據(jù)的重視程度與數(shù)據(jù)規(guī)模的膨脹帶來了新的挑戰(zhàn)。首先，訂單量對(duì)于數(shù)據(jù)的存儲(chǔ)、持久化、訪問帶來了挑戰(zhàn)，這不僅增加了開發(fā)面對(duì)的困難，也為系統(tǒng)的運(yùn)維帶來了挑戰(zhàn)。其次，隨著大數(shù)據(jù)技術(shù)的發(fā)展以及運(yùn)營水平的不斷提高，訂單數(shù)據(jù)的后續(xù)數(shù)據(jù)分析工作，如流批處理、ETL，也越來越重要，這也對(duì)數(shù)據(jù)的存儲(chǔ)系統(tǒng)提出了更高的要求。

本文提出了一種基于MySQL + Tablestore 的大規(guī)模訂單系統(tǒng)設(shè)計(jì)方案。這種方案基于分層存儲(chǔ)的思想，使用 Tablestore 輔助 MySQL 共同完成訂單系統(tǒng)支持。在系統(tǒng)中，利用 MySQL 的事務(wù)能力來處理對(duì)事務(wù)強(qiáng)需求的寫操作與部分讀操作;利用 Tablestore 的檢索能力、大數(shù)據(jù)存儲(chǔ)能力等彌補(bǔ) MySQL 在功能上的短板。詳細(xì)可見文章：云上應(yīng)用系統(tǒng)數(shù)據(jù)存儲(chǔ)架構(gòu)演進(jìn)。

本文作為 MySQL + Tablestore 分層存儲(chǔ)架構(gòu)的大規(guī)模訂單系統(tǒng)的架構(gòu)篇。

首先詳細(xì)闡述，在大規(guī)模訂單系統(tǒng)中，存在哪些需求，存在哪些痛點(diǎn)。

進(jìn)而比較傳統(tǒng)的架構(gòu)，其現(xiàn)狀如何，各存在什么樣的劣勢(shì)，無法滿足哪些需求。

然后講述 MySQL + Tablestore 架構(gòu)，闡述這種架構(gòu)是如何滿足大規(guī)模訂單系統(tǒng)的需求的。

二 需求場(chǎng)景

訂單系統(tǒng)，面向 C 端，除了在系統(tǒng)性能要求高外，對(duì)于數(shù)據(jù)的存儲(chǔ)、后續(xù)數(shù)據(jù)的計(jì)算、數(shù)據(jù)實(shí)時(shí)處理、數(shù)據(jù)批處理都有一定的要求。而對(duì)于 C 端客戶、產(chǎn)品運(yùn)營、系統(tǒng)運(yùn)維等不同的角色，他們對(duì)系統(tǒng)的需求也有所不同。

1 C 端需求

對(duì)于 C 端客戶以及面向 C 端的開發(fā)而言，系統(tǒng)首先需要支持高并發(fā)、高穩(wěn)定性。其次，系統(tǒng)需要能夠支持基于用戶 id 的搜索以及搜索用戶 id 下包含特定關(guān)鍵詞的記錄。具體的需求有：

基于用戶 id 查找用戶近一月的訂單。

基于訂單號(hào)查詢訂單詳情。

搜索用戶購買過的包含某關(guān)鍵字的商品。

這對(duì)于系統(tǒng)的索引能力以及搜索能力有較高的要求。

2 運(yùn)營需求

運(yùn)營同學(xué)需要能夠在不影響線上的情況下使用 SQL 對(duì)實(shí)時(shí)數(shù)據(jù)進(jìn)行分析，能夠根據(jù)非主鍵字段進(jìn)行檢索;他們還需要系統(tǒng)對(duì)流批計(jì)算的支持，需要流式數(shù)據(jù)處理來進(jìn)行實(shí)時(shí)數(shù)據(jù)統(tǒng)計(jì)，需要批處理來進(jìn)行歷史數(shù)據(jù)統(tǒng)計(jì)。運(yùn)營同學(xué)常見的需求場(chǎng)景有：

• 統(tǒng)計(jì)在某旗艦店消費(fèi)過的用戶有哪些。
• 統(tǒng)計(jì)消費(fèi)過某一件產(chǎn)品的客戶有哪些并且他們還購買了什么產(chǎn)品，進(jìn)而向客戶推薦商品。
• 實(shí)時(shí)統(tǒng)計(jì)雙十一開始后的實(shí)時(shí)成交額，用于宣傳時(shí)的實(shí)時(shí)數(shù)據(jù)展示。
• 統(tǒng)計(jì)某店鋪過去 10 年的成交額。
• 依賴訂單數(shù)據(jù)對(duì)客戶做實(shí)時(shí)更新的畫像分析，以支持商品的推薦。

3 運(yùn)維需求

運(yùn)維同學(xué)更關(guān)注系統(tǒng)的穩(wěn)定性、復(fù)雜度并期待低運(yùn)維成本。而基于 MySQL + Tablestore 的訂單系統(tǒng)可以將運(yùn)維同學(xué)從繁瑣的運(yùn)維工作中解放出來，大大降低運(yùn)維成本。它能夠做到：

系統(tǒng)高可用，并發(fā)能力強(qiáng)。

系統(tǒng)復(fù)雜度低，不需要維護(hù)多個(gè)集群，也不需要關(guān)注各集群間的數(shù)據(jù)同步過程，運(yùn)維工作簡單易上手。

三 傳統(tǒng)訂單系統(tǒng)

1 訂單系統(tǒng)架構(gòu)演進(jìn)

最簡單的訂單系統(tǒng)就是單點(diǎn)的 MySQL 架構(gòu)，但隨著訂單規(guī)模的增長，用戶采用分庫分表的 MySQL 替代單點(diǎn) MySQL 方案。但這種方案下，當(dāng)數(shù)據(jù)量達(dá)到當(dāng)前 MySQL 集群瓶頸，集群擴(kuò)容仍然會(huì)相當(dāng)具有難度，需要更大的集群以及大量數(shù)據(jù)的遷移工作。數(shù)據(jù)迭代、膨脹帶來的困擾，是分庫分表 MySQL 方案難于逾越的。

NoSQL 被引入，MySQL + HBase 的方案應(yīng)運(yùn)而生。這種方案將實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)分層存儲(chǔ)，MySQL 中只存儲(chǔ)實(shí)時(shí)數(shù)據(jù)，歷史數(shù)據(jù)歸檔進(jìn)入 HBase 存儲(chǔ)。這種方案解決了數(shù)據(jù)擴(kuò)容帶來的存儲(chǔ)和運(yùn)維難題，但它的缺點(diǎn)在于，存儲(chǔ)于HBase的數(shù)據(jù)很難被合理利用，并且方案整體也不支持檢索功能。

因此，架構(gòu)中引入了 Elasticsearch，形成了 MySQL + HBase + Elasticsearch 的方案。這種方案利用了 Elasticsearch 提供的數(shù)據(jù)檢索能力，解決了訂單數(shù)據(jù)的搜索問題。但在這種架構(gòu)下，用戶要維護(hù) HBase、Elasticsearch 兩個(gè)集群，還需要關(guān)注向HBase、Elasticsearch 同步數(shù)據(jù)的任務(wù)，維護(hù)成本很高。并且這種架構(gòu)仍無法支持流批處理、ETL等數(shù)據(jù)分析、加工工作。

MySQL 分庫分表方案

MySQL 自身擁有強(qiáng)大的數(shù)據(jù)查詢、分析功能，基于 MySQL 創(chuàng)建訂單系統(tǒng)，可以應(yīng)對(duì)訂單數(shù)據(jù)多維查詢、統(tǒng)計(jì)場(chǎng)景。伴隨著訂單數(shù)據(jù)量的增加，用戶會(huì)采取分庫、分表方案應(yīng)對(duì)，通過這種偽分布式方案，解決數(shù)據(jù)膨脹帶來的問題。但數(shù)據(jù)一旦達(dá)到瓶頸，便需要重新創(chuàng)建更大規(guī)模的分庫 + 數(shù)據(jù)的全量遷移，麻煩就會(huì)不斷出現(xiàn)。數(shù)據(jù)迭代、膨脹帶來的困擾，是MySQL 方案難于逾越的。僅僅依靠 MySQL 的傳統(tǒng)訂單方案短板凸顯。

1、數(shù)據(jù)縱向(數(shù)據(jù)規(guī)模)膨脹：采用分庫分表方案，MySQL 在部署時(shí)需要預(yù)估分庫規(guī)模，數(shù)據(jù)量一旦達(dá)到上限后，重新部署并做數(shù)據(jù)全量遷移;

2、數(shù)據(jù)橫向(字段維度)膨脹：schema 需預(yù)定義，迭代新增新字段變更復(fù)雜。而維度到達(dá)一定量后影響數(shù)據(jù)庫性能;數(shù)據(jù)膨脹還會(huì)提高系統(tǒng)運(yùn)維難度和成本。且 MySQL 集群一般采用雙倍策略擴(kuò)容，在重儲(chǔ)存低計(jì)算的訂單場(chǎng)景下，CPU的浪費(fèi)情況也會(huì)比較嚴(yán)重。

MySQL + HBase 方案

引入雙數(shù)據(jù)的方案應(yīng)運(yùn)而生，通過實(shí)時(shí)數(shù)據(jù)、歷史數(shù)據(jù)分存的方案，可以一定程度解決數(shù)據(jù)量膨脹問題。該方案將數(shù)據(jù)歸類成兩部分存儲(chǔ)：實(shí)時(shí)數(shù)據(jù)、歷史數(shù)據(jù)。同時(shí)通過數(shù)據(jù)同步服務(wù)，將過期數(shù)據(jù)同步至歷史數(shù)據(jù)。

1、實(shí)時(shí)訂單數(shù)據(jù)(例如：近 3 個(gè)月的訂單)：將實(shí)時(shí)訂單存入 MySQL 數(shù)據(jù)庫。實(shí)時(shí)訂單的總量膨脹的速度得到了限制，同時(shí)保證了實(shí)時(shí)數(shù)據(jù)的多維查詢、分析能力;

2、歷史訂單數(shù)據(jù)(例如：3 個(gè)月以前的訂單)：將歷史訂單數(shù)據(jù)存入 HBase，借助于 HBase 這一分布式 NoSQL 數(shù)據(jù)庫，有效應(yīng)對(duì)了訂單數(shù)據(jù)膨脹困擾。也保證了歷史訂單數(shù)據(jù)的持久化;

但是，該方案犧牲了歷史訂單數(shù)據(jù)對(duì)用戶、商家、平臺(tái)的使用價(jià)值，假設(shè)了歷史數(shù)據(jù)的需求頻率極低。但是一旦有需求，便需要全表掃描，查詢速度慢、IO 成本很高。而維護(hù)數(shù)據(jù)同步又帶來了數(shù)據(jù)一致性、同步運(yùn)維成本飆升等難題;

MySQL + HBase + Elasticsearch 方案

MySQL + HBase + Elasticsearch 方案通過引入 Elasticsearch 集群，解決了其他方案無法應(yīng)對(duì)的數(shù)據(jù)檢索問題。

1、實(shí)時(shí)訂單數(shù)據(jù)(例如：近 3 個(gè)月的訂單)：將實(shí)時(shí)訂單存入 MySQL 數(shù)據(jù)庫。實(shí)時(shí)訂單的總量膨脹的速度得到了限制，同時(shí)保證了實(shí)時(shí)數(shù)據(jù)的多維查詢、分析能力;

2、歷史訂單數(shù)據(jù)(例如：3 個(gè)月以前的訂單)：將歷史訂單數(shù)據(jù)存入 HBase，借助于 HBase 這一分布式 NoSQL 數(shù)據(jù)庫，有效應(yīng)對(duì)了訂單數(shù)據(jù)膨脹困擾。也保證了歷史訂單數(shù)據(jù)的持久化;

3、數(shù)據(jù)檢索：數(shù)據(jù)同步任務(wù)將需要檢索的字段從 HBase 同步至 Elasticsearch，借助于 Elasticsearch 的索引能力，為系統(tǒng)提供數(shù)據(jù)檢索能力。然后必要時(shí)反查 MySQL 獲取訂單完整信息;

該方案雖然解決了數(shù)據(jù)膨脹帶來的擴(kuò)容問題，也能夠支持?jǐn)?shù)據(jù)檢索。但可以看到的是，客戶要維護(hù)至少兩套集群，關(guān)注兩處數(shù)據(jù)同步任務(wù)，該方案的系統(tǒng)復(fù)雜度很高，運(yùn)維成本也會(huì)很高。此外，這個(gè)方案依然不能對(duì)數(shù)據(jù)的流批處理、數(shù)據(jù) ETL 再加工提供支持。

2 傳統(tǒng)訂單架構(gòu)總結(jié)

總之，MySQL 分庫分表方案無法解決數(shù)據(jù)膨脹帶來的擴(kuò)容問題。基于 MySQL + HBase 的架構(gòu)在數(shù)據(jù)檢索上面存在明顯短板。而 MySQL + HBase + Elasticsearch 的方案，雖然能夠解決擴(kuò)容和數(shù)據(jù)檢索問題，但其系統(tǒng)復(fù)雜，維護(hù)成本高;另外，這種方案無法對(duì)數(shù)據(jù)分析工作、數(shù)據(jù)再加工 ETL 工作提供有效支持。而 MySQL + Tablestore 不僅解決了擴(kuò)容問題、檢索問題，還支持?jǐn)?shù)據(jù)流批處理以及 ETL 再加工工作，且系統(tǒng)復(fù)雜度低，運(yùn)維成本低，能夠滿足大規(guī)模訂單系統(tǒng)的各項(xiàng)需求。

四 MySQL + Tablestore 方案

表格存儲(chǔ)(Tablestore)是阿里云自研的多模型結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)，提供海量結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)以及快速的查詢和分析服務(wù)。

MySQL + Tablestore 后，可以很好的滿足大規(guī)模訂單場(chǎng)景下遇到的各種需求。其整體架構(gòu)圖如圖。

MySQL 處理訂單的寫入和近期數(shù)據(jù)的基本讀取，并且利用數(shù)據(jù)同步工具如 DTS 將數(shù)據(jù)實(shí)時(shí)同步給 Tablestore。在 Tablestore 中，利用其二級(jí)索引和多元索引，可以處理檢索需求。通過 DLA，可以實(shí)現(xiàn)使用 SQL 直接查詢 Tablestore。Tablestore 的通道服務(wù)可以對(duì)接 Spark streaming 以及 Flink，可以實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)分析。將 Tablestore 和 ODPS 對(duì)接，可以很便捷的實(shí)現(xiàn)對(duì)訂單數(shù)據(jù)的 ETL 作業(yè)。而結(jié)合 OSS 和 Tablestore，可以實(shí)現(xiàn)訂單數(shù)據(jù)的歸檔，并且可以在 OSS 中實(shí)現(xiàn)全量歷史數(shù)據(jù)的分析工作。

1 數(shù)據(jù)同步

傳統(tǒng)的訂單架構(gòu)中，開發(fā)者不可避免需要處理數(shù)據(jù)同步進(jìn)入 HBase 或者 Elasticsearch 之類的工作。這不僅加重了開發(fā)者的開發(fā)工作，也提高了運(yùn)維難度。在 Tablestore 中，阿里云提供 DataX、Data Transmission Service(DTS)、Canal 多種數(shù)據(jù)同步工具完成數(shù)據(jù)從 MySQL 到 Tablestore 的同步工作。用戶只需要進(jìn)行少量的開發(fā)和配置工作就可以完成數(shù)據(jù)實(shí)時(shí)同步。操作方便簡單，實(shí)時(shí)性高，大大降低了維護(hù)成本。

2 數(shù)據(jù)檢索

Tablestore 提供了二級(jí)索引和多元索引來支持?jǐn)?shù)據(jù)的檢索。二級(jí)索引可以完成基于主鍵列和預(yù)定義列的數(shù)據(jù)查詢，例如查詢用戶過去一個(gè)月成交的訂單情況。而多元索引，基于倒排索引和列式存儲(chǔ)，對(duì)外提供了更加強(qiáng)大的數(shù)據(jù)檢索功能，他解決大數(shù)據(jù)的復(fù)雜查詢難題。它可以實(shí)現(xiàn)如搜索購買過某產(chǎn)品的用戶這樣的需求。

Tablestore 的多元索引補(bǔ)齊了 MySQL、HBase 等在搜索上面的短板。而相對(duì)于 Elasticsearch，多元索引不再需要使用者專門維護(hù)集群、維護(hù)數(shù)據(jù)同步任務(wù)，成本更低。

3 基于SQL的數(shù)據(jù)分析

Tablestore 以多種方式支持 SQL 對(duì) Tablestore 中數(shù)據(jù)的讀寫。若想直接讀取 Tablestore 中的數(shù)據(jù)，建議直接使用 Tablestore 的 SQL 支持能力進(jìn)行操作;而若希望進(jìn)行多數(shù)據(jù)存儲(chǔ)的聯(lián)邦查詢，推薦使用 DLA 所支持的 SQL。對(duì)于兩種形式的SQL，Tablestore 都利用多元索引對(duì)其進(jìn)行了充分的優(yōu)化。擁有 SQL 處理能力，開發(fā)者可以更加高效率的進(jìn)行代碼開發(fā)、代碼遷移工作。直接使用 SQL 查詢 Tablestore 也會(huì)為 MySQL 主庫卸載流量。

4 實(shí)時(shí)數(shù)據(jù)分析

Tablestore 的通道服務(wù)，可以將 Tablestore 庫中數(shù)據(jù)的變化傳入通道。使用 Spark streaming或者 Flink 等流式數(shù)據(jù)處理工具對(duì)接通道，可以實(shí)現(xiàn)例如統(tǒng)計(jì)實(shí)時(shí)成交額這一類的實(shí)時(shí)數(shù)據(jù)分析需求。

5 歷史數(shù)據(jù)分析

Tablestore 可以將數(shù)據(jù)投遞到 OSS 系統(tǒng)，這樣可以完成訂單的歸檔需求，并且利用 OSS 系統(tǒng)對(duì)接 Spark ，可以完成對(duì)全量歷史數(shù)據(jù)的分析工作。這樣，在 Tablestore 中存儲(chǔ)近期數(shù)據(jù)，在 OSS 中存儲(chǔ)全量歷史數(shù)據(jù)，以 OSS 來支持涉及全量歷史數(shù)據(jù)的分析工作。

6 ETL數(shù)據(jù)再加工

通過將 Tablestore 數(shù)據(jù)接入 ODPS ，可以利用 ODPS 強(qiáng)大的數(shù)據(jù)處理能力，更便捷的對(duì)數(shù)據(jù)做 ETL 作業(yè)，進(jìn)行數(shù)據(jù)的再次加工。

五 總結(jié)

本文簡要介紹了基于 MySQL 結(jié)合 Tablestore 的大規(guī)模訂單系統(tǒng)方案。這種方案支持大數(shù)據(jù)存儲(chǔ)、高性能數(shù)據(jù)檢索、SQL搜索、實(shí)時(shí)與全量數(shù)據(jù)分析，且部署簡單、運(yùn)維成本低。