互聯(lián)網(wǎng)歷史訂單集群的設(shè)計(jì)與實(shí)現(xiàn)

梅巧玲，劉文韜，楊立鵬，王 拓

（中國鐵道科學(xué)研究院 電子計(jì)算技術(shù)研究所，北京 100081）

鐵路信息技術(shù)

互聯(lián)網(wǎng)歷史訂單集群的設(shè)計(jì)與實(shí)現(xiàn)

梅巧玲，劉文韜，楊立鵬，王 拓

（中國鐵道科學(xué)研究院 電子計(jì)算技術(shù)研究所，北京 100081）

針對(duì)歷史訂單的查詢流程，將內(nèi)存數(shù)據(jù)庫技術(shù)和大數(shù)據(jù)Hadoop技術(shù)無縫結(jié)合，實(shí)現(xiàn)旅客快速地查詢到更多的歷史訂單信息。不僅為旅客查詢訂單提供便利，也為分布式大數(shù)據(jù)技術(shù)在客票系統(tǒng)中的廣泛推廣打下堅(jiān)實(shí)的基礎(chǔ)。

Hadoop ；訂單查詢； 歷史數(shù)據(jù) ； 消息 ； 分布式

從2011年6月互聯(lián)網(wǎng)售票系統(tǒng)上線以來，注冊(cè)用戶已達(dá)1.2億多，十一國慶節(jié)期間網(wǎng)站最高日售票量達(dá)636.8萬張。截止到目前為止，互聯(lián)網(wǎng)用戶的訂單數(shù)據(jù)已達(dá)幾十億條左右，互聯(lián)網(wǎng)售票系統(tǒng)面臨前所未有的并發(fā)訪問壓力和海量數(shù)據(jù)存儲(chǔ)壓力。相比于國內(nèi)和國外主流的電商網(wǎng)站，現(xiàn)有的鐵路互聯(lián)網(wǎng)售票系統(tǒng)受到架設(shè)在鐵路既有客票系統(tǒng)之上等因素的影響，鐵路互聯(lián)網(wǎng)售票系統(tǒng)與這些電商網(wǎng)站有著明顯差別。互聯(lián)網(wǎng)售票系統(tǒng)除了售票主要功能之外，還有其他業(yè)務(wù)，包括退票、改簽、訂單跟蹤、退款詳情、快遞詳情等，要辦理或者查詢這些業(yè)務(wù)，需要到“我的訂單”中進(jìn)行訂單查詢才能看到，訂單查詢是這些業(yè)務(wù)的入口。鐵路客票預(yù)售期由原來的20天調(diào)整為60天后，未出行訂單的數(shù)量根據(jù)歷史數(shù)據(jù)的分析預(yù)估增加1.5倍，這樣的數(shù)據(jù)量對(duì)現(xiàn)有的分布式內(nèi)存數(shù)據(jù)庫是一種挑戰(zhàn)。基于上面因素的考慮，引入了分布式Hadoop數(shù)據(jù)庫技術(shù)，將12306中“我的訂單”查詢功能分為“未出行訂單”和“歷史訂單”。旅客頻繁訪問的未出行訂單數(shù)據(jù)存放在內(nèi)存數(shù)據(jù)庫中，歷史訂單數(shù)據(jù)存放在分布式大數(shù)據(jù)Hadoop數(shù)據(jù)庫中，將數(shù)據(jù)進(jìn)行分布式存儲(chǔ)，實(shí)現(xiàn)“表面集中、內(nèi)在分散”的現(xiàn)象，達(dá)到并行計(jì)算快速查詢的目的。

1 關(guān)鍵技術(shù)

1.1 大數(shù)據(jù)Hadoop技術(shù)

Hadoop是一個(gè)對(duì)大量數(shù)據(jù)進(jìn)行分布式處理的軟件框架，它包括兩個(gè)核心模塊：HDFS和Map-Reduce。HDFS是Hadoop中的分布式文件系統(tǒng)，存儲(chǔ)Hadoop生態(tài)系統(tǒng)中的各種文件，實(shí)現(xiàn)了對(duì)文件的增刪改查等操作。HDFS有高容錯(cuò)性的特點(diǎn)，并且適合部署在硬件上；而且它能提供高吞吐量應(yīng)用程序的訪問數(shù)據(jù)，適合那些有著超大數(shù)據(jù)集的應(yīng)用程序。MapReduce是一種簡(jiǎn)化的用于并行處理大數(shù)據(jù)集的分布式編程模式，讓程序自動(dòng)分布到一個(gè)由普通機(jī)器組成的超大集群上并發(fā)執(zhí)行。

1.2 異構(gòu)數(shù)據(jù)同步中間件

異構(gòu)數(shù)據(jù)同步中間件CTMSX主要用于異構(gòu)環(huán)境的數(shù)據(jù)同步。通過讀取并轉(zhuǎn)發(fā)關(guān)系型數(shù)據(jù)庫復(fù)制服務(wù)主點(diǎn)到從點(diǎn)數(shù)據(jù)庫的消息，作為數(shù)據(jù)橋模擬復(fù)制主點(diǎn)數(shù)據(jù)庫的響應(yīng)消息序列到復(fù)制從點(diǎn)，以確保實(shí)時(shí)數(shù)據(jù)的完整性和一致性，完成數(shù)據(jù)庫主、從點(diǎn)之間的數(shù)據(jù)同步，同時(shí)通過數(shù)據(jù)適配器、解析器將消息和數(shù)據(jù)實(shí)時(shí)同步轉(zhuǎn)發(fā)到消息服務(wù)器MQServer中，由消費(fèi)程序消費(fèi)MQServer的隊(duì)列，將數(shù)據(jù)操作動(dòng)作同步到GemFire內(nèi)存數(shù)據(jù)庫和Hadoop集群中，最終實(shí)現(xiàn)Sybase 數(shù)據(jù)庫與GemFire內(nèi)存數(shù)據(jù)庫和Hadoop集群的異構(gòu)數(shù)據(jù)同步功能。

1.3 MQServer消息機(jī)制

RabbitMQ是由 LShift 提供的一個(gè)AMQP（Advanced Message Queuing Protocol）的開源消息隊(duì)列系統(tǒng)，由以高性能、健壯以及可伸縮性出名的Erlang 寫成。一端往消息隊(duì)列中不斷寫入消息，而另一端則可以讀取或者訂閱隊(duì)列中的消息。綁定協(xié)議，包括消息交換機(jī)（Exchange）和路由關(guān)鍵字（RoutingKey），定義了Exchange和消息隊(duì)列實(shí)體Queue之間的關(guān)聯(lián)，提供路由規(guī)則。Exchange指定消息的路由規(guī)則，由異構(gòu)系統(tǒng)雙方（或多方）共同約定。

1.4 數(shù)據(jù)庫復(fù)制技術(shù)

復(fù)制服務(wù)器（Replication Server）維護(hù)多個(gè)數(shù)據(jù)庫中的復(fù)制數(shù)據(jù)，同時(shí)確保數(shù)據(jù)的完整性和一致性。使用復(fù)制系統(tǒng)中的數(shù)據(jù)庫的客戶機(jī)可以在本地訪問數(shù)據(jù)，減少網(wǎng)絡(luò)負(fù)載和中央計(jì)算機(jī)系統(tǒng)的復(fù)制。Replication Server采用一種基本的“發(fā)布-預(yù)訂”模式來實(shí)現(xiàn)跨網(wǎng)絡(luò)的數(shù)據(jù)復(fù)制。用戶“發(fā)布”主點(diǎn)數(shù)據(jù)庫中的可用數(shù)據(jù)，其它用戶“預(yù)訂”這些數(shù)據(jù)以便將其發(fā)送到復(fù)制點(diǎn)數(shù)據(jù)庫。

1.5 分布式內(nèi)存數(shù)據(jù)庫

內(nèi)存數(shù)據(jù)庫是一個(gè)較新的研究領(lǐng)域，全部數(shù)據(jù)常駐內(nèi)存，在CPU進(jìn)行運(yùn)算時(shí)，存取數(shù)據(jù)只需與內(nèi)存進(jìn)行I/O 操作，效率非常高。采用分布式內(nèi)存數(shù)據(jù)庫集群后，根據(jù)用戶指定的數(shù)據(jù)存儲(chǔ)規(guī)則，不同范圍的記錄由不同的物理節(jié)點(diǎn)進(jìn)行存儲(chǔ)，并行查詢和并行處理也會(huì)隨之分布到不同的物理節(jié)點(diǎn)上，最終由控制節(jié)點(diǎn)完成匯總。內(nèi)存數(shù)據(jù)庫集群支持動(dòng)態(tài)水平擴(kuò)展節(jié)點(diǎn)，由于本身具有備份機(jī)制，即使單點(diǎn)故障，也不會(huì)影響到整個(gè)集群。同時(shí)還支持?jǐn)?shù)據(jù)持久化，如果整個(gè)集群發(fā)生異常時(shí)，數(shù)據(jù)也不會(huì)丟失，可以從硬盤的持久的文件中恢復(fù)。

2 歷史訂單集群架構(gòu)設(shè)計(jì)及實(shí)現(xiàn)

2.1 歷史訂單集群設(shè)計(jì)思路

歷史訂單查詢，指的是當(dāng)天之前（不包括當(dāng)天）的訂單信息，旅客除了由于鐵路原因可以進(jìn)行原退操作外，更多的是查詢功能，因此可以將訂單相關(guān)數(shù)據(jù)劃分為兩部分?jǐn)?shù)據(jù)：內(nèi)存數(shù)據(jù)和磁盤數(shù)據(jù)，將訪問頻繁的數(shù)據(jù)量少的數(shù)據(jù)放到內(nèi)存中，為了保證高可靠性，可在磁盤上做持久化配置；將訪問較少的數(shù)據(jù)量多的數(shù)據(jù)保存到磁盤上，將所需數(shù)據(jù)加載到內(nèi)存后，進(jìn)行相關(guān)邏輯判斷，這樣既能滿足大數(shù)據(jù)的存儲(chǔ)，也能加快查詢效率。

在歷史訂單集群框架中，內(nèi)存數(shù)據(jù)庫集群在初始啟動(dòng)時(shí)只有少量的基礎(chǔ)數(shù)據(jù)，在關(guān)系型數(shù)據(jù)庫和Hadoop集群中各有一份全量數(shù)據(jù)。當(dāng)用戶登錄互聯(lián)網(wǎng)售票系統(tǒng)后，在“我的訂單”功能中，點(diǎn)擊歷史訂單查詢時(shí)，分級(jí)存儲(chǔ)系統(tǒng)自動(dòng)將這些被立即訪問的數(shù)據(jù)從二級(jí)存儲(chǔ)設(shè)備Hadoop集群加載到一級(jí)存儲(chǔ)設(shè)備分布式內(nèi)存數(shù)據(jù)庫中。上述數(shù)據(jù)的搬遷過程對(duì)于用戶來說是完全透明的。

2.2 歷史訂單集群系統(tǒng)實(shí)現(xiàn)

歷史訂單集群框架主要包括3個(gè)模塊：數(shù)據(jù)產(chǎn)生模塊（傳統(tǒng)Sybase關(guān)系型數(shù)據(jù)庫）、訂單相關(guān)數(shù)據(jù)同步模塊（包括復(fù)制服務(wù)器系統(tǒng)、CTMSX和MQServer）、存儲(chǔ)運(yùn)算模塊（包括分布式內(nèi)存數(shù)據(jù)庫和Hadoop集群），系統(tǒng)架構(gòu)如圖1所示。

2.2.1 數(shù)據(jù)產(chǎn)生模塊

第1個(gè)模塊是數(shù)據(jù)產(chǎn)生模塊，訂單相關(guān)的所有數(shù)據(jù)是在關(guān)系型數(shù)據(jù)庫中產(chǎn)生的，關(guān)系型數(shù)據(jù)庫是通過用戶名來區(qū)分的一個(gè)數(shù)據(jù)庫集群組成，每個(gè)用戶產(chǎn)生的訂單數(shù)據(jù)存放在各個(gè)節(jié)點(diǎn)上，從上到下縱列的下端是上端的備份節(jié)點(diǎn)。

2.2.2 數(shù)據(jù)同步模塊

第2個(gè)模塊是數(shù)據(jù)同步模塊，復(fù)制服務(wù)器負(fù)責(zé)偵聽數(shù)據(jù)庫的數(shù)據(jù)變化，將捕獲到的相關(guān)訂單數(shù)據(jù)變化發(fā)送給異構(gòu)數(shù)據(jù)同步中間件CTMXS，CTMSX再將變化的數(shù)據(jù)以消息的方式發(fā)給MQServer。MQserver作為透明的消息轉(zhuǎn)發(fā)中間模塊，消費(fèi)端接收到變化的SQL語句，對(duì)不同的Update、Insert和Delete語句進(jìn)行不同的解析處理，寫入內(nèi)存集群和Hadoop集群中。

圖1 歷史訂單集群架構(gòu)圖

2.2.3 存儲(chǔ)運(yùn)算模塊

第3個(gè)模塊是存儲(chǔ)運(yùn)算模塊，它是分布式歷史訂單集群的核心模塊，其具有數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)運(yùn)算的兩大重要功能，由分布式內(nèi)存數(shù)據(jù)集群和分布式Hadoop集群組成，內(nèi)存數(shù)據(jù)集群負(fù)責(zé)數(shù)據(jù)運(yùn)算和存儲(chǔ)，Hadoop集群負(fù)責(zé)數(shù)據(jù)存儲(chǔ)。內(nèi)存數(shù)據(jù)庫集群由分布在不同物理服務(wù)器上的多個(gè)節(jié)點(diǎn)組成，每個(gè)節(jié)點(diǎn)內(nèi)含有若干個(gè)數(shù)據(jù)區(qū)域，每個(gè)數(shù)據(jù)區(qū)域內(nèi)含有若干個(gè)數(shù)據(jù)單元，數(shù)據(jù)按照一致性Hash理論分散存儲(chǔ)在不同的數(shù)據(jù)單元中。從物理邏輯上看，一個(gè)完整的數(shù)據(jù)存儲(chǔ)容器包含了3個(gè)層次：多個(gè)內(nèi)存數(shù)據(jù)庫Server節(jié)點(diǎn)組成了整體的存儲(chǔ)運(yùn)算模塊，多個(gè)數(shù)據(jù)存儲(chǔ)區(qū)域Region組成了一個(gè)數(shù)據(jù)Server節(jié)點(diǎn)，多個(gè)數(shù)據(jù)存儲(chǔ)單元bucket組成了一個(gè)數(shù)據(jù)存儲(chǔ)區(qū)域Region。集群并行調(diào)度多個(gè)節(jié)點(diǎn)參與運(yùn)算，每個(gè)節(jié)點(diǎn)只進(jìn)行與自己內(nèi)存單元中關(guān)聯(lián)數(shù)據(jù)的運(yùn)算，避免跨網(wǎng)絡(luò)的讀取大量數(shù)據(jù)，最終將所有參與運(yùn)算節(jié)點(diǎn)的運(yùn)算結(jié)果數(shù)據(jù)匯總，完成訂單查詢的計(jì)算?；钴S數(shù)據(jù)的存儲(chǔ)與對(duì)數(shù)據(jù)的處理均在物理內(nèi)存中完成。

歷史訂單Hadoop集群由兩個(gè)命名節(jié)點(diǎn)（Name-Node）和多個(gè)數(shù)據(jù)節(jié)點(diǎn)（DataNode）組成。NameNode的作用是管理元數(shù)據(jù)和文件塊、管理命名空間、監(jiān)聽并處理請(qǐng)求和心跳檢測(cè)。DataNode的作用是讀寫數(shù)據(jù)塊、向NameNode匯報(bào)活躍狀態(tài)和執(zhí)行數(shù)據(jù)流水線復(fù)制。訂單數(shù)據(jù)被切分成文件塊的形式分散存儲(chǔ)在分布式文件系統(tǒng)（HDFS，Hadoop Distributed File System）的不同DataNode節(jié)點(diǎn)上。在HDFS中，訂單數(shù)據(jù)以注冊(cè)用戶名作為劃分列導(dǎo)向存儲(chǔ)機(jī)制的數(shù)據(jù)庫（HBase）區(qū)域的原則，將數(shù)據(jù)分布在不同HDFS DataNode物理節(jié)點(diǎn)上，在讀寫時(shí)將自動(dòng)進(jìn)行校驗(yàn)，NameNode 上保存了每份數(shù)據(jù)的版本信息，發(fā)現(xiàn)不同數(shù)據(jù)節(jié)點(diǎn)的同一個(gè)數(shù)據(jù)塊的版本不一致，就會(huì)觸發(fā)恢復(fù)流程同步所有的節(jié)點(diǎn)數(shù)據(jù)，一旦發(fā)現(xiàn)數(shù)據(jù)校驗(yàn)錯(cuò)誤將重新進(jìn)行復(fù)制，最大程度保障了數(shù)據(jù)的準(zhǔn)確性和一致性。盡最大程度提高查詢性能，將關(guān)系型數(shù)據(jù)庫中的唯一索引設(shè)置為HBase的rowkey，客戶端進(jìn)行查詢時(shí)，先通過login_name模糊匹配，再通過訂單號(hào)等其他條件拼接rowkey來獲取數(shù)據(jù)。Hive數(shù)據(jù)倉庫可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射到一張數(shù)據(jù)庫表上，提供簡(jiǎn)單的SQL查詢功能，可以將SQL語句轉(zhuǎn)換為MapReduce任務(wù)運(yùn)行。以HBase為基礎(chǔ)，建立Hive到HBase的外部關(guān)聯(lián)表，對(duì)歷史訂單數(shù)據(jù)進(jìn)行更深層次的數(shù)據(jù)挖掘。

2.3 歷史訂單集群試驗(yàn)效果

互聯(lián)網(wǎng)售票上線運(yùn)營以來，高峰日售票量占客票交易總額的68%以上，累計(jì)銷售客票約18.1億張。按照高峰期的售票量統(tǒng)計(jì)，互聯(lián)網(wǎng)每日產(chǎn)生900萬張訂單（包括自動(dòng)返庫和主動(dòng)取消的訂單），再加上與之相關(guān)聯(lián)的其他數(shù)據(jù)，每日凈增3 900萬條數(shù)據(jù)。模擬并發(fā)用戶1 000個(gè)對(duì)歷史訂單集群進(jìn)行壓力測(cè)試，訂單查詢請(qǐng)求平均值為761次/s，平均響應(yīng)時(shí)間RT為492 ms，滿足高峰時(shí)期系統(tǒng)的查詢請(qǐng)求。

3 結(jié)束語

本文分析了鐵路互聯(lián)網(wǎng)售票系統(tǒng)面臨的并發(fā)和存儲(chǔ)雙重壓力，提出使用新的技術(shù)來嘗試解決網(wǎng)站面臨的問題：分布式內(nèi)存數(shù)據(jù)庫技術(shù)用于應(yīng)對(duì)高并發(fā)，Hadoop大數(shù)據(jù)存儲(chǔ)技術(shù)用于應(yīng)對(duì)海量存儲(chǔ)，同時(shí)使用復(fù)制服務(wù)器、中間件CTMSX和RabbitMQ消息中間件，實(shí)現(xiàn)異構(gòu)系統(tǒng)間順暢、準(zhǔn)確的進(jìn)行消息傳遞的目的。在互聯(lián)網(wǎng)售票系統(tǒng)中將來可以用作全路實(shí)名制數(shù)據(jù)分析、用戶行為分析、系統(tǒng)日志分析等需求。

綜上所述，分布式內(nèi)存數(shù)據(jù)庫技術(shù)和Hadoop大數(shù)據(jù)存儲(chǔ)技術(shù)在鐵路客票系統(tǒng)中或者鐵路行業(yè)的其他系統(tǒng)中有著良好的發(fā)展前景。

[1]A Novel Real-time Database Memory Management Approach[C]. Wuhan:2010 The 2nd International Conference on Industrial Mecha-tronics and Automation, 2010.

[2]曹 英. 大數(shù)據(jù)環(huán)境下Hadoop性能優(yōu)化的研究[D].大連：大連海事大學(xué)，2013.

責(zé)任編輯 徐侃春

Internet history ordering clusters

MEI Qiaoling, LIU Wentao, YANG Lipeng, WANG Tuo
( Institute of Computing Technologies, China Academy of Railway Sciences, Beijing 100081, China )

According to the query processing of history orders, the paper combined the memory database technology with large data Hadoop technology, implemented quick query more history orders for passengers, provided convenience for passengers to order query, laid a solid foundation for distributed large data technology in the Railway Ticketing and Reservation System.

Hadoop; order-query; history data; message; distributed

U293.22∶TP39

A

1005-8451（2015）08-0020-04

2014-12-11

梅巧玲 副研究員；劉文韜，副研究員。