來公司第一個比較大的業務需求，便是換了新的行情提供商dxfeed，需要把所有K線的處理都重新倒騰一遍。這里說說重寫分時K線圖的一點心得。
先交代一下dxfeed的情況：
1）股票分時數據采用訂閱的方式，可以訂閱歷史數據
2）每分鐘每只股票可能會接收到多條分時數據，也可能一條不推。有些股票在開市過程中每分鐘都會有分時數據，有些股票則一個交易日只有幾條數據，甚至沒有，差別很大
3）推送的分時數據有延遲，從監控獲得數據，開市期間大約在60s-120s左右（分時數據看的是趨勢，這是可以忍受的）
4）每個訂閱對實時數據有qps限制，對歷史數據無qps限制（從監控上得到的）
再交代一下股票分時K線數據的情況：
1）股票數目為8400+（我們只做美股相關）
2）每只股票1個交易日的分時線包含391條數據（9:30-16:00, America/New_York），每條數據包含這一分鐘的最高價、最低價、均價、昨收價、漲幅、交易量、VWAP等，數據量在150k左右
3）每天存儲的分時數據在120w條左右
4）股票分時線如果某一分鐘沒有點，使用上一分鐘的點代替，但無交易量
接下來重點說一下這里的設計：(以AAPL為例)
1）由于分時數據有延遲，無法確定每一分鐘的最后一條數據什么時候會來到。因此開市期間并不去保存分時數據。實時的分時數據存儲在redis中，計算K線時從redis中取
2）redis中分時數據的存儲格式為hash結構，每只股票一個key，為了防止當前交易日使用上個交易日的數據，因此分時數據緩存時是包含日期的，比如：TMT_AAPL0105, key為美東時間，格式：HHmm， value為簡單計算后的分時數據。上一個交易日的分時數據通過定時任務在指定時間清理。（這里沒有對分時數據做過期設置，是因為剛開市時數據推送量及redis操作量很大，而使用hashes這個結構，是不支持直接傳入expire time的，同時即使某天系統出什么問題，也只是多占些硬盤的問題，不會對其他造成影響，對這個操作添加監控及報警就可以了）
3）結構有了，如果dxfeed每次都推送數據過來時，都去操作redis更新，那樣redis很可能會吃不消，誰都無法曉得第三方是否會出什么問題瘋狂推送一下（事實證明，dxfeed也確實這樣有過，可能因網絡故障等補償推送歷史數據）。接下來是緩存的的重點：在內存中通過guava cache緩存了最近幾分鐘的所有symbol的最新數據，key: 股票+HHmm(美東時間)， value：一條分時數據，每次推送分時數據過來時，根據股票及分時數據時間進行cache，過期數據（很久以前或非最新數據）或臟數據（相關數據為NaN）直接拋棄，然后通過ScheduledExecutorService維護一個1分鐘1執行的job去將最近幾分鐘的分時數據更新到redis中。這樣既解決了分時數據有延遲的問題，又保證了每分鐘的redis更新數據量。
4）數據存儲結束后，就是處理分時K線的數據了。當請求AAPL時，會先查看是否已經有cache了，比如C_TT_AAPL, 如果有取出cache中數據處理后返回，沒有開始計算。計算會先取出上面存儲的數據，即TMT_AAPL0105，然后計算當前k線的時間點（開市過程中從1個點慢慢增長到391個點），遍歷HHmm去TMT_AAPL0105中取分時數據，如果有直接取出即可，如果沒有使用上一個點生成（第一個記得特殊處理一下，沒有需要拿上個交易日最后一個點補），計算完后轉成json放到redis中，key為計算前查詢的key: C_TT_AAPL，然后將結果返回。開市過程中緩存到下一分鐘開始，閉市了緩存到下個交易日開始。由于這里緩存的是string，因此直接帶上過期時間，之后就不用care了。如此，最核心的分時K線數據絕大部分都是在操作redis，每只股票每分鐘只需要計算一次即可，當然這是基于分時K線主要看的是趨勢。
5）上面說了，分時數據可以拿歷史數據。這里我單獨寫了一個job，可以在給定開始時間后，取出期望的歷史數據，然后更新歷史分時數據。當實時推送出問題時，這個job可以用來在秒級獲取歷史數據來修復redis中的分時數據。實際上，這個job在故障中的表現遠遠超出預期，之前因為對實時那里做優化，幾次都有點問題導致開市后實時數據獲取或處理有問題，這時候啟動這個拿歷史分時的job，幾秒內就可以保證redis中的數據變成最新，保證核心的分時圖數據一直ok。
6）說到這里，分時數據還沒保存。這里借助上面拿歷史數據的job，在閉市后（北京時間凌晨5點以后）自動執行，更新redis中數據后開始插入數據庫。由于插入量特別大，通過guava的RateLimiter控制寫入速度在合理的qps值，慢慢更新就好啦
當然這不是全部，還有些細節，比如動態增加股票，就不多說了。此外，我單獨補了許多核心監控，比如定時任務是否正常執行、讀取及更新redis時間、開市期間推送的qps、計算分時K線平均時間、平均每分鐘推送不同股票數目等等，目前達到的結果是：docker上部署的2個4g的服務來處理所有K線圖，分時K線圖數據可以在平均10ms左右返回，大量的分時數據在低峰時間端插入，服務器在開市閉市都沒什么壓力。
