**簡介：**本文簡要介紹了基于 MySQL 結合 Tablestore 的大規模訂單系統方案。這種方案支持大數據存儲、高性能數據檢索、SQL搜索、實時與全量數據分析，且部署簡單、運維成本低。  作者 | 弘楠 來源 | 阿里技術公眾號 ### 一 背景 訂單系統存在于各行各業，如電商訂單、銀行流水、運營商話費賬單等，是一個非常廣泛、通用的系統。對于這類系統，在過去十幾年發展中已經形成了經典的做法。但是隨著互聯網的發展，以及各企業對數據的重視，需要存儲和持久化的訂單量越來越大，數據的重視程度與數據規模的膨脹帶來了新的挑戰。首先，訂單量對于數據的存儲、持久化、訪問帶來了挑戰，這不僅增加了開發面對的困難，也為系統的運維帶來了挑戰。其次，隨著大數據技術的發展以及運營水平的不斷提高，訂單數據的后續數據分析工作，如流批處理、ETL，也越來越重要，這也對數據的存儲系統提出了更高的要求。 本文提出了一種基于MySQL + Tablestore 的大規模訂單系統設計方案。這種方案基于分層存儲的思想，使用 Tablestore 輔助 MySQL 共同完成訂單系統支持。在系統中，利用 MySQL 的事務能力來處理對事務強需求的寫操作與部分讀操作；利用 Tablestore 的檢索能力、大數據存儲能力等彌補 MySQL 在功能上的短板。詳細可見文章：云上應用系統數據存儲架構演進。 本文作為 MySQL + Tablestore 分層存儲架構的大規模訂單系統的架構篇。 * 首先詳細闡述，在大規模訂單系統中，存在哪些需求，存在哪些痛點。 * 進而比較傳統的架構，其現狀如何，各存在什么樣的劣勢，無法滿足哪些需求。 * 然后講述 MySQL + Tablestore 架構，闡述這種架構是如何滿足大規模訂單系統的需求的。 ### 二 需求場景 訂單系統，面向 C 端，除了在系統性能要求高外，對于數據的存儲、后續數據的計算、數據實時處理、數據批處理都有一定的要求。而對于 C 端客戶、產品運營、系統運維等不同的角色，他們對系統的需求也有所不同。 #### 1 C 端需求 對于 C 端客戶以及面向 C 端的開發而言，系統首先需要支持高并發、高穩定性。其次，系統需要能夠支持基于用戶 id 的搜索以及搜索用戶 id 下包含特定關鍵詞的記錄。具體的需求有： * 基于用戶 id 查找用戶近一月的訂單。 * 基于訂單號查詢訂單詳情。 * 搜索用戶購買過的包含某關鍵字的商品。 這對于系統的索引能力以及搜索能力有較高的要求。 #### 2 運營需求 運營同學需要能夠在不影響線上的情況下使用 SQL 對實時數據進行分析，能夠根據非主鍵字段進行檢索；他們還需要系統對流批計算的支持，需要流式數據處理來進行實時數據統計，需要批處理來進行歷史數據統計。運營同學常見的需求場景有： * 統計在某旗艦店消費過的用戶有哪些。 * 統計消費過某一件產品的客戶有哪些并且他們還購買了什么產品，進而向客戶推薦商品。 * 實時統計雙十一開始后的實時成交額，用于宣傳時的實時數據展示。 * 統計某店鋪過去 10 年的成交額。 * 依賴訂單數據對客戶做實時更新的畫像分析，以支持商品的推薦。 #### 3 運維需求 運維同學更關注系統的穩定性、復雜度并期待低運維成本。而基于 MySQL + Tablestore 的訂單系統可以將運維同學從繁瑣的運維工作中解放出來，大大降低運維成本。它能夠做到： * 系統高可用，并發能力強。 * 系統復雜度低，不需要維護多個集群，也不需要關注各集群間的數據同步過程，運維工作簡單易上手。 ### 三 傳統訂單系統 #### 1 訂單系統架構演進 最簡單的訂單系統就是單點的 MySQL 架構，但隨著訂單規模的增長，用戶采用分庫分表的 MySQL 替代單點 MySQL 方案。但這種方案下，當數據量達到當前 MySQL 集群瓶頸，集群擴容仍然會相當具有難度，需要更大的集群以及大量數據的遷移工作。數據迭代、膨脹帶來的困擾，是分庫分表 MySQL 方案難于逾越的。 NoSQL 被引入，MySQL + HBase 的方案應運而生。這種方案將實時數據和歷史數據分層存儲，MySQL 中只存儲實時數據，歷史數據歸檔進入 HBase 存儲。這種方案解決了數據擴容帶來的存儲和運維難題，但它的缺點在于，存儲于HBase的數據很難被合理利用，并且方案整體也不支持檢索功能。 因此，架構中引入了 Elasticsearch，形成了 MySQL + HBase + Elasticsearch 的方案。這種方案利用了 Elasticsearch 提供的數據檢索能力，解決了訂單數據的搜索問題。但在這種架構下，用戶要維護 HBase、Elasticsearch 兩個集群，還需要關注向HBase、Elasticsearch 同步數據的任務，維護成本很高。并且這種架構仍無法支持流批處理、ETL等數據分析、加工工作。 **MySQL 分庫分表方案** MySQL 自身擁有強大的數據查詢、分析功能，基于 MySQL 創建訂單系統，可以應對訂單數據多維查詢、統計場景。伴隨著訂單數據量的增加，用戶會采取分庫、分表方案應對，通過這種偽分布式方案，解決數據膨脹帶來的問題。但數據一旦達到瓶頸，便需要重新創建更大規模的分庫 + 數據的全量遷移，麻煩就會不斷出現。數據迭代、膨脹帶來的困擾，是MySQL 方案難于逾越的。僅僅依靠 MySQL 的傳統訂單方案短板凸顯。 1、數據縱向（數據規模）膨脹：采用分庫分表方案，MySQL 在部署時需要預估分庫規模，數據量一旦達到上限后，重新部署并做數據全量遷移； 2、數據橫向（字段維度）膨脹：schema 需預定義，迭代新增新字段變更復雜。而維度到達一定量后影響數據庫性能；數據膨脹還會提高系統運維難度和成本。且 MySQL 集群一般采用雙倍策略擴容，在重儲存低計算的訂單場景下，CPU的浪費情況也會比較嚴重。 **MySQL + HBase 方案** 引入雙數據的方案應運而生，通過實時數據、歷史數據分存的方案，可以一定程度解決數據量膨脹問題。該方案將數據歸類成兩部分存儲：實時數據、歷史數據。同時通過數據同步服務，將過期數據同步至歷史數據。 1、實時訂單數據（例如：近 3 個月的訂單）：將實時訂單存入 MySQL 數據庫。實時訂單的總量膨脹的速度得到了限制，同時保證了實時數據的多維查詢、分析能力； 2、歷史訂單數據（例如：3 個月以前的訂單）：將歷史訂單數據存入 HBase，借助于 HBase 這一分布式 NoSQL 數據庫，有效應對了訂單數據膨脹困擾。也保證了歷史訂單數據的持久化； 但是，該方案犧牲了歷史訂單數據對用戶、商家、平臺的使用價值，假設了歷史數據的需求頻率極低。但是一旦有需求，便需要全表掃描，查詢速度慢、IO 成本很高。而維護數據同步又帶來了數據一致性、同步運維成本飆升等難題； **MySQL + HBase + Elasticsearch 方案** MySQL + HBase + Elasticsearch 方案通過引入 Elasticsearch 集群，解決了其他方案無法應對的數據檢索問題。 1、實時訂單數據（例如：近 3 個月的訂單）：將實時訂單存入 MySQL 數據庫。實時訂單的總量膨脹的速度得到了限制，同時保證了實時數據的多維查詢、分析能力； 2、歷史訂單數據（例如：3 個月以前的訂單）：將歷史訂單數據存入 HBase，借助于 HBase 這一分布式 NoSQL 數據庫，有效應對了訂單數據膨脹困擾。也保證了歷史訂單數據的持久化； 3、數據檢索：數據同步任務將需要檢索的字段從 HBase 同步至 Elasticsearch，借助于 Elasticsearch 的索引能力，為系統提供數據檢索能力。然后必要時反查 MySQL 獲取訂單完整信息； 該方案雖然解決了數據膨脹帶來的擴容問題，也能夠支持數據檢索。但可以看到的是，客戶要維護至少兩套集群，關注兩處數據同步任務，該方案的系統復雜度很高，運維成本也會很高。此外，這個方案依然不能對數據的流批處理、數據 ETL 再加工提供支持。 #### 2 傳統訂單架構總結 總之，MySQL 分庫分表方案無法解決數據膨脹帶來的擴容問題。基于 MySQL + HBase 的架構在數據檢索上面存在明顯短板。而 MySQL + HBase + Elasticsearch 的方案，雖然能夠解決擴容和數據檢索問題，但其系統復雜，維護成本高；另外，這種方案無法對數據分析工作、數據再加工 ETL 工作提供有效支持。而 MySQL + Tablestore 不僅解決了擴容問題、檢索問題，還支持數據流批處理以及 ETL 再加工工作，且系統復雜度低，運維成本低，能夠滿足大規模訂單系統的各項需求。 ### 四 MySQL + Tablestore 方案 表格存儲（Tablestore）是阿里云自研的多模型結構化數據存儲，提供海量結構化數據存儲以及快速的查詢和分析服務。 MySQL + Tablestore 后，可以很好的滿足大規模訂單場景下遇到的各種需求。其整體架構圖如圖。  MySQL 處理訂單的寫入和近期數據的基本讀取，并且利用數據同步工具如 DTS 將數據實時同步給 Tablestore。在 Tablestore 中，利用其二級索引和多元索引，可以處理檢索需求。通過 DLA，可以實現使用 SQL 直接查詢 Tablestore。Tablestore 的通道服務可以對接 Spark streaming 以及 Flink，可以實現實時數據分析。將 Tablestore 和 ODPS 對接，可以很便捷的實現對訂單數據的 ETL 作業。而結合 OSS 和 Tablestore，可以實現訂單數據的歸檔，并且可以在 OSS 中實現全量歷史數據的分析工作。 #### 1 數據同步 傳統的訂單架構中，開發者不可避免需要處理數據同步進入 HBase 或者 Elasticsearch 之類的工作。這不僅加重了開發者的開發工作，也提高了運維難度。在 Tablestore 中，阿里云提供 DataX、Data Transmission Service（DTS）、Canal 多種數據同步工具完成數據從 MySQL 到 Tablestore 的同步工作。用戶只需要進行少量的開發和配置工作就可以完成數據實時同步。操作方便簡單，實時性高，大大降低了維護成本。 #### 2 數據檢索 Tablestore 提供了二級索引和多元索引來支持數據的檢索。二級索引可以完成基于主鍵列和預定義列的數據查詢，例如查詢用戶過去一個月成交的訂單情況。而多元索引，基于倒排索引和列式存儲，對外提供了更加強大的數據檢索功能，他解決大數據的復雜查詢難題。它可以實現如搜索購買過某產品的用戶這樣的需求。 Tablestore 的多元索引補齊了 MySQL、HBase 等在搜索上面的短板。而相對于 Elasticsearch，多元索引不再需要使用者專門維護集群、維護數據同步任務，成本更低。 #### 3 基于SQL的數據分析 Tablestore 以多種方式支持 SQL 對 Tablestore 中數據的讀寫。若想直接讀取 Tablestore 中的數據，建議直接使用 Tablestore 的 SQL 支持能力進行操作；而若希望進行多數據存儲的聯邦查詢，推薦使用 DLA 所支持的 SQL。對于兩種形式的SQL，Tablestore 都利用多元索引對其進行了充分的優化。擁有 SQL 處理能力，開發者可以更加高效率的進行代碼開發、代碼遷移工作。直接使用 SQL 查詢 Tablestore 也會為 MySQL 主庫卸載流量。 #### 4 實時數據分析 Tablestore 的通道服務，可以將 Tablestore 庫中數據的變化傳入通道。使用 Spark streaming或者 Flink 等流式數據處理工具對接通道，可以實現例如統計實時成交額這一類的實時數據分析需求。 #### 5 歷史數據分析 Tablestore 可以將數據投遞到 OSS 系統，這樣可以完成訂單的歸檔需求，并且利用 OSS 系統對接 Spark ，可以完成對全量歷史數據的分析工作。這樣，在 Tablestore 中存儲近期數據，在 OSS 中存儲全量歷史數據，以 OSS 來支持涉及全量歷史數據的分析工作。 #### 6 ETL數據再加工 通過將 Tablestore 數據接入 ODPS ，可以利用 ODPS 強大的數據處理能力，更便捷的對數據做 ETL 作業，進行數據的再次加工。 ### 五 總結 本文簡要介紹了基于 MySQL 結合 Tablestore 的大規模訂單系統方案。這種方案支持大數據存儲、高性能數據檢索、SQL搜索、實時與全量數據分析，且部署簡單、運維成本低。 https://developer.aliyun.com/article/789320