推薦閱讀：
背景
團隊目前在做一個用戶數據看板（下面簡稱看板），基本覆蓋用戶的所有行爲數據，並生成分析數據，用戶行爲數據來源於多個數據源（餐飲、生活日用、充值消費、交通出行、通訊物流、交通出行、醫療保健、住房物業、運動健康...），基於對大量數據的任意請求、排序和統計，沒有辦法對原生表（原生多表查詢相對複雜）直接進行數據採用，所以我們在當日的凌晨獲取前一天數據，並將數據做成Json對象保存在Mongo數據庫中。
所以看板最初採用得是T+1的策略，這樣就減少了實時數據計算的過程，另一方面能夠保證數據的準確性。但是目前很多人反饋，希望能夠實時的獲取到看板最新的數據，而且每月月底會有消費數據覈對，消費數據按照看板統計得出並覈對，如果等到第二天（也就是次月1號）再輸出數據報表，這種體驗就太差了。
優化方案
針對看板的原型需求和數據呈現形式，形成了類似 （數據(Mongo)服務 - 接口服務 - 前端展示頁面）的架構模式，以T+1的策略提供數據，
來保障用戶可以高效的瀏覽到自己的行爲數據結構，並給出具體得數據分析和建議。
原有流程：通過設計開發控制檯調度服務，並部署到中心服務器上，調度配置每天凌晨一點做服務啓動，會根據用戶新增和修改的日誌做數據增量。
優化目標：改成每次用戶行爲數據的修改、刪除和保存都採用消息隊列形式實時的通知到服務去消費，服務消費之後立刻把Mongo的行爲數據做好。
T+0 服務概要設計
核心功能實現設計
1、用戶行爲數據保存後實時發送MQ消息通知，解耦行爲數據保存和看板數據生產的強關聯。
2、開發獨立服務消費MQ，同步聚合看板數據、輸出用戶行爲數據報表，並推送通知消息給用戶進行查看。
數據服務生成流程
時序圖/流程圖說明
1、原有是獨立服務每天凌晨進行數據計算，改成每次用戶行爲完成修改之後發送MQ
2、服務端程序監聽MQ，消費到數據，則調用調度服務進行處理
3、調度服務根據配置好的調度規則，進行控制檯服務啓動，並將對應的數據增量拉取到內存中，進行數據的篩選、排序、整合，合併成目標mongo文檔，並保存到mongo集羣中
4、調度服務數據處理完成之後，同步聚合看板數據、輸出用戶行爲數據報表，並推送通知消息給用戶進行查看。
數據聚合過程說明
所有的用戶行爲模塊都遵循這個規則，最後實現數據T+0 實時聚合的目標
