背景
團隊目前在做一個使用者資料看板（下面簡稱看板），基本覆蓋使用者的所有行為資料，並生成分析資料，使用者行為資料來源於多個資料來源（餐飲、生活日用、充值消費、交通出行、通訊物流、交通出行、醫療保健、住房物業、運動健康...），基於對大量資料的任意請求、排序和統計，沒有辦法對原生表（原生多表查詢相對複雜）直接進行資料採用，所以我們在當日的凌晨獲取前一天資料，並將資料做成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 實時聚合的目標
