攜程實時用戶行為服務作為基礎服務，目前普遍應用在多個場景中，比如猜你喜歡（攜程的推薦系統）、動態廣告、用戶畫像、瀏覽歷史等等。

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

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

　　而近幾年旅游市場高速增長，數據量越來越大，并且會持續快速增長。有越來越多的使用需求，對系統的實時性，穩定性也提出了更高的要求。總的來說，當前需求對系統的實時性/可用性/性能/擴展性方面都有很高的要求。

　　一、架構

　　這樣的背景下，我們按照如下結構重新設計了系統：

　　圖1 實時用戶行為系統邏輯視圖

　　新的架構下，數據有兩種流向，分別是處理流和輸出流。

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

　　輸出流相對簡單，Web Service的后臺會從數據層拉取數據，并輸出給調用方，有的是內部服務調用，比如推薦系統，也有的是輸出到前臺，比如瀏覽歷史。系統實現采用的是Java+Kafka+Storm+Redis+MySQL+Tomcat+Spring的技術棧。

　　Java：目前公司內部Java化的氛圍比較濃厚，并且Java有比較成熟的大數據組件

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

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

　　MySQL： 作為基礎系統，穩定性和性能也是系統的兩大指標，對比NoSQL的主要選項，比如HBase和ElasticSearch，十億數據級別上MySQL在這兩方面有更好的表現，并且經過設計能夠有不錯的水平擴展能力。

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