背景

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

&n