有贊使用storm已經有將近3年時間，穩定支撐著實時統計、數據同步、對賬、監控、風控等業務。訂單實時統計是其中一個典型的業務，對數據準確性、性能等方面都有較高要求，也是上線時間最久的一個實時計算應用。通過訂單實時統計，描述使用storm時，遇到的準確性、性能、可靠性等方面的問題。
訂單實時統計的演進
第一版：流程走通
在使用storm之前，顯示實時統計數據一般有兩種方案：
在數據庫裡執行count、sum等聚合查詢，是簡單快速的實現方案，但容易出現慢查詢。
在業務代碼裡對統計指標做累加，可以滿足指標的快速查詢，但統計邏輯耦合到業務代碼，維護不方便，而且錯誤數據定位和修正不方便。
既要解耦業務和統計，也要滿足指標快速查詢，基於storm的實時計算方案可以滿足這兩點需求。
一個storm應用的基本結構有三部分：數據源、storm應用、結果集。storm應用從數據源讀取數據，經過計算後，把結果持久化或發送消息給其他應用。
第一版的訂單實時統計結構如下圖。在數據源方面，最早嘗試在業務代碼裡打日誌的方式，但總有業務分支無法覆蓋，採集的數據不全。我們的業務數據庫是mysql，隨後嘗試基於mysql binlog的數據源，採用了阿里開源的canal，可以做到完整的收集業務數據變更。
在結果數據的處理上，我們把統計結果持久化到了mysql，並通過另一個後台應用的RESTful API對外提供服務，一個mysql就可以滿足數據的讀寫需求。
為了提昇實時統計應用吞吐量，需要提升消息的並發度。spout裡設置了消息緩衝區，只要消息緩衝區不滿，就會源源不斷從消息源canal拉取數據，並把分發到多個bolt處理。
第二版：性能提升
第一版的性能瓶頸在統計結果持久化上。為了確保數據的準確性，把所有的統計指標持久化放在一個數據庫事務裡。一筆訂單狀態更新後，會在一個事務裡有兩類操作：
訂單的歷史狀態也在數據庫裡存著，要與歷史狀態對比決定統計邏輯，並把最新的狀態持久化。storm的應用本身是無狀態的，需要使用存儲設備記錄狀態信息
當大家知道實時計算好用後，各產品都希望有實時數據，統計邏輯越來越複雜。店鋪、商品、用戶等多個指標的寫操作都是在一個事務裡commit，這一簡單粗暴的方式早期很好滿足的統計需求，但是對於update操作持有鎖時間過長，嚴重影響了並發能力。
