攜程實時用戶行為服務(wù)作為基礎(chǔ)服務(wù)，目前普遍應(yīng)用在多個場景中，比如猜你喜歡（攜程的推薦系統(tǒng)）、動態(tài)廣告、用戶畫像、瀏覽歷史等等。

　　以猜你喜歡為例，猜你喜歡為應(yīng)用內(nèi)用戶提供潛在選項，提高成交效率。旅行是一項綜合性的需求，用戶往往需要不止一個產(chǎn)品。作為一站式的旅游服務(wù)平臺，跨業(yè)務(wù)線的推薦，特別是實時推薦，能實際滿足用戶的需求，因此在上游提供打通各業(yè)務(wù)線之間的用戶行為數(shù)據(jù)有很大的必要性。

　　攜程原有的實時用戶行為系統(tǒng)存在一些問題，包括：1）數(shù)據(jù)覆蓋不全；2）數(shù)據(jù)輸出沒有統(tǒng)一格式，對眾多使用方提高了接入成本；3）日志處理模塊是Web Service，比較難支持多種數(shù)據(jù)處理策略和實現(xiàn)方便擴(kuò)容應(yīng)對流量洪峰的需求等。

　　而近幾年旅游市場高速增長，數(shù)據(jù)量越來越大，并且會持續(xù)快速增長。有越來越多的使用需求，對系統(tǒng)的實時性，穩(wěn)定性也提出了更高的要求。總的來說，當(dāng)前需求對系統(tǒng)的實時性/可用性/性能/擴(kuò)展性方面都有很高的要求。

　　一、架構(gòu)

　　這樣的背景下，我們按照如下結(jié)構(gòu)重新設(shè)計了系統(tǒng)：

　　圖1 實時用戶行為系統(tǒng)邏輯視圖

　　新的架構(gòu)下，數(shù)據(jù)有兩種流向，分別是處理流和輸出流。

　　在處理流，行為日志會從客戶端（App/Online/H5）上傳到服務(wù)端的Collector Service。Collector Service將消息發(fā)送到分布式隊列。數(shù)據(jù)處理模塊由流計算框架完成，從分布式隊列讀出數(shù)據(jù)，處理之后把數(shù)據(jù)寫入數(shù)據(jù)層，由分布式緩存和數(shù)據(jù)庫集群組成。

　　輸出流相對簡單，Web Service的后臺會從數(shù)據(jù)層拉取數(shù)據(jù)，并輸出給調(diào)用方，有的是內(nèi)部服務(wù)調(diào)用，比如推薦系統(tǒng)，也有的是輸出到前臺，比如瀏覽歷史。系統(tǒng)實現(xiàn)采用的是Java+Kafka+Storm+Redis+MySQL+Tomcat+Spring的技術(shù)棧。

　　Java：目前公司內(nèi)部Java化的氛圍比較濃厚，并且Java有比較成熟的大數(shù)據(jù)組件

　　Kafka/Storm：Kafka作為分布式消息隊列已經(jīng)在公司有比較成熟的應(yīng)用，流計算框架Storm也已經(jīng)落地，并且有比較好的運(yùn)維支持環(huán)境。

　　Redis： Redis的HA，SortedSet和過期等特性比較好地滿足了系統(tǒng)的需求。

　　MySQL： 作為基礎(chǔ)系統(tǒng)，穩(wěn)定性和性能也是系統(tǒng)的兩大指標(biāo)，對比NoSQL的主要選項，比如HBase和ElasticSearch，十億數(shù)據(jù)級別上MySQL在這兩方面有更好的表現(xiàn)，并且經(jīng)過設(shè)計能夠有不錯的水平擴(kuò)展能力。

　　目前系統(tǒng)每天處理20億左右的數(shù)據(jù)量，數(shù)據(jù)從上線到可用的時間在300毫秒左右。查詢服務(wù)每天服務(wù)8000萬左右的請求，平均延遲在6毫秒左右。下面從實時性/可用性/性能/部署幾個維度來說明系統(tǒng)的設(shè)計。