[[422085]]

一 背景

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

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

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

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

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

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

二 需求場景

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

1 C 端需求

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

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

基于訂單號查詢訂單詳情。

搜索用戶購買過的包含某關鍵字的商品。

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

2 運營需求

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

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

3 運維需求

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

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

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

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

1 訂單系統(tǒng)架構演進

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

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

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

MySQL 分庫分表方案

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

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

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

MySQL + HBase 方案

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

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

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

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

MySQL + HBase + Elasticsearch 方案

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

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

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

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

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

2 傳統(tǒng)訂單架構總結

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

四 MySQL + Tablestore 方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五 總結

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