去年做活動(dòng)復(fù)盤的時(shí)候我對(duì)著后臺(tái)的SQL報(bào)表愣了很久明明活動(dòng)還在進(jìn)行中業(yè)務(wù)方問(wèn)當(dāng)前實(shí)時(shí)新增有多少我答不上來(lái)。不是沒(méi)有數(shù)據(jù)而是數(shù)據(jù)散落在日志、數(shù)據(jù)庫(kù)和一堆臨時(shí)腳本里等我把它們攢齊、清洗、匯總出來(lái)十分鐘已經(jīng)過(guò)去了。就是在那一天我決定自己動(dòng)手做一套輕量級(jí)的實(shí)時(shí)事件分析系統(tǒng)代號(hào)就叫rea全稱是Real-time Event Analytics。這套系統(tǒng)從設(shè)計(jì)到上線前前后后花了不到三周卻徹底改變了我們處理現(xiàn)在到底發(fā)生了什么這類問(wèn)題的方式。它沒(méi)有做成多么龐大的平臺(tái)只是一個(gè)能支撐內(nèi)部運(yùn)營(yíng)、產(chǎn)品和開(kāi)發(fā)同學(xué)實(shí)時(shí)看數(shù)的系統(tǒng)。這篇內(nèi)容適合那些不想一上來(lái)就引入重型流計(jì)算框架的中小團(tuán)隊(duì)也適合想搞清楚埋點(diǎn)、采集、聚合、查詢?nèi)溌返降资窃趺椿厥碌那昂蠖斯こ處煛?. 逼我動(dòng)手的三個(gè)需求痛點(diǎn)1.1 活動(dòng)大屏背后的實(shí)時(shí)其實(shí)是延遲統(tǒng)計(jì)我所在的團(tuán)隊(duì)負(fù)責(zé)一個(gè)中型產(chǎn)品日活不算夸張但運(yùn)營(yíng)活動(dòng)非常頻繁。每當(dāng)首頁(yè)改版或者營(yíng)銷活動(dòng)上線業(yè)務(wù)方最關(guān)心的問(wèn)題永遠(yuǎn)是現(xiàn)在到底有多少用戶進(jìn)來(lái)了點(diǎn)擊率怎么樣聽(tīng)起來(lái)很簡(jiǎn)單實(shí)際查詢卻要繞一大圈。事件日志被統(tǒng)一收在文件里每天的定時(shí)任務(wù)負(fù)責(zé)把它們載入數(shù)據(jù)庫(kù)再生成一份離線報(bào)表。這意味著當(dāng)天白天的數(shù)據(jù)要等到凌晨才能看到白天只能靠寫臨時(shí)SQL去查每次執(zhí)行時(shí)間還取決于數(shù)據(jù)量?；顒?dòng)期間流量是平時(shí)的幾倍臨時(shí)查詢一個(gè)不小心就是幾十萬(wàn)行記錄去聚合數(shù)據(jù)庫(kù)CPU直接被頂滿其他業(yè)務(wù)跟著遭殃。這種偽實(shí)時(shí)帶來(lái)的痛點(diǎn)不只是慢。更關(guān)鍵的是它嚴(yán)重壓縮了運(yùn)營(yíng)決策的反應(yīng)時(shí)間?；顒?dòng)上線前半小時(shí)運(yùn)營(yíng)想根據(jù)實(shí)時(shí)數(shù)據(jù)調(diào)整入口位置或廣告語(yǔ)等我們算出數(shù)字用戶早就流失了。要解決問(wèn)題我得讓數(shù)據(jù)鏈路從小時(shí)級(jí)至少走到秒級(jí)。1.2 找現(xiàn)成工具時(shí)遇到的三個(gè)不合身著手之前我花了一周時(shí)間調(diào)研現(xiàn)有的開(kāi)源和商業(yè)方案。結(jié)論是沒(méi)有哪一款能直接塞進(jìn)我們團(tuán)隊(duì)而不產(chǎn)生新的問(wèn)題。第一類是商業(yè)數(shù)據(jù)分析SaaS。它們體驗(yàn)確實(shí)好接入也快但費(fèi)用不低而且核心數(shù)據(jù)要傳到第三方平臺(tái)。當(dāng)時(shí)我們產(chǎn)品里有一些核心業(yè)務(wù)行為的數(shù)據(jù)業(yè)務(wù)方明確不希望在外部系統(tǒng)留存這一條就把大部分SaaS方案排除了。第二類是開(kāi)源重型組件。比如基于流計(jì)算生態(tài)的方案功能強(qiáng)大但需要配套的消息隊(duì)列、計(jì)算集群、監(jiān)控體系。我們團(tuán)隊(duì)一共就四五個(gè)人還要兼顧日常業(yè)務(wù)開(kāi)發(fā)根本沒(méi)有余力去維護(hù)一套分布式系統(tǒng)。為了每天幾萬(wàn)個(gè)事件上流計(jì)算框架明顯是殺雞用牛刀。第三類是傳統(tǒng)BI報(bào)表工具。它們擅長(zhǎng)把已有表結(jié)構(gòu)做可視化但對(duì)事件流這件事沒(méi)什么概念。我想要的是從埋點(diǎn)采集到實(shí)時(shí)聚合到查詢API一整條鏈路都能自己掌控的東西而不是在數(shù)據(jù)已經(jīng)入庫(kù)之后再手工建模。三種路數(shù)擺在一起差距很明顯方案類型優(yōu)點(diǎn)不合適的地方商業(yè)SaaS接入快、圖表全費(fèi)用高、數(shù)據(jù)出域、定制受限開(kāi)源流計(jì)算全家桶擴(kuò)展性強(qiáng)、生態(tài)完善運(yùn)維復(fù)雜、對(duì)團(tuán)隊(duì)要求高傳統(tǒng)BI可視化強(qiáng)、報(bào)表豐富不關(guān)心事件鏈路、實(shí)時(shí)性弱自研輕量系統(tǒng)完全可控、成本低需要自己維護(hù)、迭代1.3 用一句話給rea劃清邊界當(dāng)時(shí)很多人勸我要不先用定時(shí)SQL湊合等數(shù)據(jù)量大了再說(shuō)。我堅(jiān)持要做是因?yàn)榈葦?shù)據(jù)量大往往永遠(yuǎn)等不到。關(guān)鍵不是數(shù)據(jù)量而是能不能在被問(wèn)到時(shí)快速給出答案。所以rea的邊界在一開(kāi)始就定死了用一句話說(shuō)就是一個(gè)輕量級(jí)的、秒級(jí)延遲的、只關(guān)注關(guān)鍵事件的內(nèi)部實(shí)時(shí)事件分析系統(tǒng)。具體來(lái)說(shuō)rea不做以下幾件事不采集全量用戶行為只收錄我們關(guān)心的核心事件不做用戶畫像和廣告投放決策不做毫秒級(jí)實(shí)時(shí)競(jìng)價(jià)那樣的低延遲場(chǎng)景不追求分布式和高可用。這幾條邊界非常重要因?yàn)樗鼈儧Q定了技術(shù)上可以走簡(jiǎn)單粗暴但可靠的路線。邊界劃清之后整個(gè)系統(tǒng)的技術(shù)選型就變得非常輕松因?yàn)槲抑恍枰卮鹨粋€(gè)問(wèn)題在每秒幾千事件、查詢頻率不高的規(guī)模下怎么用最少的人力把鏈路打通下面是我當(dāng)時(shí)的完整設(shè)計(jì)。2. 技術(shù)架構(gòu)怎么在夠用和未來(lái)擴(kuò)展之間找平衡2.1 埋點(diǎn)SDK自己寫還是用現(xiàn)成的埋點(diǎn)是一切分析的地基。調(diào)研了一圈現(xiàn)成的開(kāi)源埋點(diǎn)SDK功能確實(shí)不少自動(dòng)采集頁(yè)面瀏覽、點(diǎn)擊熱圖、用戶屬性全都有。但我掂量了一下決定自己寫一個(gè)不到10KB的輕量SDK原因有三。首先是包體積。我們的前端頁(yè)面本身掛了圖表庫(kù)、請(qǐng)求庫(kù)隨便一個(gè)商業(yè)埋點(diǎn)SDK動(dòng)輒幾十KB對(duì)移動(dòng)端用戶體驗(yàn)影響不是小事。自己寫的SDK可以只保留事件發(fā)送、重試、節(jié)流三個(gè)能力。其次是數(shù)據(jù)協(xié)議的可控性?，F(xiàn)成SDK的事件字段格式往往是固定的想加一個(gè)團(tuán)隊(duì)自定義的環(huán)境標(biāo)識(shí)要么做二次開(kāi)發(fā)要么在數(shù)據(jù)落庫(kù)之后再清洗。自研SDK可以直接采用我們內(nèi)部定義的事件協(xié)議采集端、傳輸端、存儲(chǔ)端使用同一套結(jié)構(gòu)省掉很多中間轉(zhuǎn)換。最后是隱私合規(guī)。自研SDK可以明確地控制哪些數(shù)據(jù)允許采集例如默認(rèn)不采集系統(tǒng)字體、屏幕亮度這類無(wú)意義但容易引起誤會(huì)的字段。由于rea從一開(kāi)始就面向內(nèi)部場(chǎng)景我們不希望采集用戶敏感信息自研可以讓這個(gè)承諾寫進(jìn)代碼而不是寫進(jìn)文檔。這里給一個(gè)最簡(jiǎn)單的瀏覽器端發(fā)送邏輯function sendReaEvent(eventName, props {}) { if (!window._rea || !window._rea.userId) { return; // 未初始化或匿名場(chǎng)景 } const event { v: 1, // 事件協(xié)議版本 id: generateUUID(), // 全局唯一事件ID name: eventName, userId: window._rea.userId, anonymousId: window._rea.anonymousId, time: Date.now(), // 設(shè)備本地時(shí)間戳 props: JSON.stringify(props), }; if (navigator.sendBeacon window.location.protocol https:) { navigator.sendBeacon(/rea/track, new Blob([JSON.stringify(event)], { type: application/json })); } else { fetch(/rea/track, { method: POST, body: JSON.stringify(event), headers: { Content-Type: application/json }, keepalive: true, }).catch(() {}); } }為什么用sendBeacon因?yàn)樗m合頁(yè)面卸載場(chǎng)景下上報(bào)事件不阻塞頁(yè)面跳轉(zhuǎn)瀏覽器會(huì)在網(wǎng)絡(luò)空閑時(shí)把數(shù)據(jù)發(fā)出去。如果沒(méi)有這條很多點(diǎn)擊后立刻跳走的事件就會(huì)白白丟失。2.2 消息管道別一上來(lái)就上Kafka消息隊(duì)列是整個(gè)鏈路的緩沖層很多人第一反應(yīng)是Kafka。Kafka確實(shí)好高吞吐、持久化、消費(fèi)者組一應(yīng)俱全。但對(duì)我們這個(gè)每天幾十萬(wàn)事件、峰值每秒兩三千請(qǐng)求的場(chǎng)景它的問(wèn)題也很明顯依賴獨(dú)立集群運(yùn)維心智高磁盤占用、副本配置、分區(qū)調(diào)優(yōu)哪一項(xiàng)都要花時(shí)間。我的選擇是先用NATS。這是一個(gè)極簡(jiǎn)的云原生消息系統(tǒng)安裝一個(gè)二進(jìn)制就能跑支持主題訂閱吞吐量對(duì)rea的場(chǎng)景完全夠用還自帶持久化選項(xiàng)。團(tuán)隊(duì)沒(méi)有專職運(yùn)維NATS單節(jié)點(diǎn)崩潰了也能快速重啟成本非常低。如果你不想引入新組件用Redis Stream也可以它一樣能做到消息的持久化和消費(fèi)組。我后來(lái)把兩種都跑過(guò)壓測(cè)結(jié)論在下面這張表里對(duì)比項(xiàng)NATSRedis StreamKafka安裝復(fù)雜度低低依賴Redis高單機(jī)吞吐數(shù)萬(wàn)級(jí)/s數(shù)萬(wàn)級(jí)/s百萬(wàn)級(jí)/s持久化支持JetStream支持強(qiáng)運(yùn)維成本低低高適合rea適合適合大材小用選擇NATS之后我們用它的主題把事件從采集服務(wù)分發(fā)給聚合服務(wù)和歸檔服務(wù)。這樣即使聚合服務(wù)重啟事件也會(huì)留在JetStream中不會(huì)丟失。哪天流量真的漲上來(lái)了從NATS遷移到Kafka只需要改消費(fèi)端的幾行代碼因?yàn)閞ea的業(yè)務(wù)邏輯全部在消費(fèi)者內(nèi)部與消息系統(tǒng)解耦得比較干凈。2.3 存儲(chǔ)選型PostgreSQL起步ClickHouse留后路事件明細(xì)最終要落到數(shù)據(jù)庫(kù)里。最開(kāi)始我的候選名單里有四個(gè)選手PostgreSQL、MySQL、ClickHouse、DuckDB。先排除DuckDB它是嵌入式分析型數(shù)據(jù)庫(kù)做離線分析很爽但并發(fā)查詢能力和多用戶訪問(wèn)的支持弱一些不適合作為線上服務(wù)的主存儲(chǔ)。MySQL是順手就能用但數(shù)據(jù)分析場(chǎng)景下它的聚合能力確實(shí)不如PostgreSQL更何況后面我打算用預(yù)處理索引優(yōu)化。ClickHouse是我心里的未來(lái)方向列式存儲(chǔ)、壓縮比高、聚合極快特別適合事件分析。之所以沒(méi)有一開(kāi)始就用是因?yàn)槲覀儓F(tuán)隊(duì)對(duì)它的運(yùn)維經(jīng)驗(yàn)不足同時(shí)ClickHouse更適合在數(shù)據(jù)量已經(jīng)很大的情況下體現(xiàn)優(yōu)勢(shì)。幾十萬(wàn)行數(shù)據(jù)在PostgreSQL里用一條帶索引的SQL也能在幾百毫秒內(nèi)返回完全夠用。所以在第一版里我選了PostgreSQL但留下了一個(gè)伏筆定義事件明細(xì)表時(shí)把event_time、userId、event_name這些分析字段單獨(dú)作為事件維度寬表來(lái)建方便以后原樣遷移到ClickHouse。表格長(zhǎng)這樣CREATE TABLE rea_events ( id VARCHAR(40) PRIMARY KEY, -- 事件ID冪等鍵 name VARCHAR(64) NOT NULL, -- 事件名 user_id VARCHAR(64), -- 用戶ID哈希后 anonymous_id VARCHAR(64), occurred_at TIMESTAMPTZ NOT NULL, -- 事件發(fā)生時(shí)間 received_at TIMESTAMPTZ NOT NULL, -- 服務(wù)端接收時(shí)間 props JSONB NOT NULL DEFAULT {}, -- 擴(kuò)展屬性 created_at TIMESTAMPTZ DEFAULT NOW() ); CREATE INDEX idx_rea_events_name_time ON rea_events (name, occurred_at DESC);2.4 查詢與展示用最少代碼做內(nèi)部看板存儲(chǔ)定了之后展示層我猶豫了一下要不要接一個(gè)開(kāi)源BI工具它們功能確實(shí)豐富可以做下鉆、聯(lián)動(dòng)、權(quán)限管理。但我們的需求其實(shí)很單一幾個(gè)關(guān)鍵指標(biāo)的趨勢(shì)、實(shí)時(shí)粗略計(jì)數(shù)、按事件名分組匯總。為一個(gè)單一需求引入一套完整的BI同樣不劃算。最后我用一個(gè)輕量API服務(wù)加一個(gè)不到200行的前端頁(yè)面解決了。API服務(wù)負(fù)責(zé)查庫(kù)、聚合、緩存前端頁(yè)面就放幾塊圖表實(shí)時(shí)趨勢(shì)折線、事件排行榜、基礎(chǔ)漏斗。數(shù)據(jù)格式統(tǒng)一用JSON返回前端用一套現(xiàn)成的圖表庫(kù)渲染。這個(gè)方案的好處是后續(xù)想換BI、想開(kāi)放數(shù)據(jù)給其他系統(tǒng)只要API不變底層隨便換。3. 核心實(shí)現(xiàn)rea從0到1的五個(gè)關(guān)鍵環(huán)節(jié)3.1 先定事件協(xié)議再寫代碼這是我認(rèn)為整個(gè)項(xiàng)目最重要的決定。如果沒(méi)有統(tǒng)一的事件協(xié)議后面每一個(gè)環(huán)節(jié)都會(huì)因?yàn)樽侄尾黄ヅ涠影?。rea的事件協(xié)議在JSON層面就定義死了字段意義如下v協(xié)議版本整數(shù)從1開(kāi)始。后續(xù)加字段就升版本消費(fèi)端按版本做兼容。id事件唯一ID由前端生成UUID。這個(gè)字段為冪等去重而生后面踩坑部分會(huì)專門講到。name事件名命名規(guī)則是對(duì)象_動(dòng)作比如button_click、page_view、order_submit。userId和anonymousId登錄用戶ID經(jīng)過(guò)哈希后的值和匿名用戶ID用來(lái)做漏斗和留存。time設(shè)備本地時(shí)間毫秒時(shí)間戳。props擴(kuò)展屬性JSON對(duì)象允許不同事件帶不同的業(yè)務(wù)屬性。這里有個(gè)細(xì)節(jié)為什么不直接用Protobuf或者Avro因?yàn)閞ea是內(nèi)部系統(tǒng)解析鏈路上的消費(fèi)者只有采集服務(wù)和聚合服務(wù)JSON的解析開(kāi)銷完全不是瓶頸。Protobuf雖然節(jié)省帶寬、類型約束強(qiáng)但多一層編譯、多一層schema管理對(duì)三周內(nèi)要上線的項(xiàng)目來(lái)說(shuō)收益不抵成本。技術(shù)選型要放在具體約束下看脫離場(chǎng)景談性能沒(méi)有意義。3.2 采集服務(wù)批量寫入和背壓處理采集服務(wù)是前端埋點(diǎn)請(qǐng)求的第一站它的職責(zé)很簡(jiǎn)單接收事件、校驗(yàn)字段、寫入消息管道。但簡(jiǎn)單不代表可以隨意寫。我見(jiàn)過(guò)不少同類系統(tǒng)采集接口一個(gè)一個(gè)往數(shù)據(jù)庫(kù)插結(jié)果流量稍大就卡死。rea的做法是在服務(wù)內(nèi)做兩級(jí)緩沖。第一級(jí)緩沖是一個(gè)內(nèi)存隊(duì)列接收到的每一條事件先丟進(jìn)隊(duì)列由后臺(tái)批量任務(wù)每500毫秒或者攢夠1000條后一次性打包發(fā)給消息管道。第二級(jí)緩沖就是NATS本身它保證即使采集服務(wù)進(jìn)程崩潰已提交到JetStream的事件也不會(huì)丟。緩沖帶來(lái)的直接問(wèn)題是怎么處理隊(duì)列滿了。如果生產(chǎn)速度遠(yuǎn)超消費(fèi)能力繼續(xù)往隊(duì)列里塞只會(huì)導(dǎo)致內(nèi)存溢出。我當(dāng)時(shí)定了一個(gè)降級(jí)策略核心事件比如訂單、支付結(jié)果不允許丟棄即使延遲也要保非核心事件比如普通的按鈕點(diǎn)擊在隊(duì)列超過(guò)80%水位時(shí)直接采樣丟棄一部分并打一條日志。寫代碼時(shí)大概是這個(gè)樣子# 偽代碼示意reactive處理的思路 def handle_event(event, is_criticalFalse): if not queue.offer(event, timeout_ms100): if is_critical: # 核心事件阻塞等待 queue.put(event) else: dropped_count.inc() logger.warning(queue full, drop non-critical event) def batch_flush(): while True: batch queue.take_n(max_count1000, timeout_ms500) if batch: nats.publish(rea.event, batch)背壓處理是最容易被忽略的。很多自建采集系統(tǒng)都是從單條寫入改成批量寫入就完事了完全不考慮生產(chǎn)者太快會(huì)怎樣。結(jié)果就是突發(fā)流量一來(lái)服務(wù)直接內(nèi)存溢出。3.3 實(shí)時(shí)聚合計(jì)數(shù)器放Redis明細(xì)留給數(shù)據(jù)庫(kù)實(shí)時(shí)看數(shù)和精確統(tǒng)計(jì)是兩種不同的需求。業(yè)務(wù)方問(wèn)現(xiàn)在在線多少人其實(shí)不要求100%精確但他們的真實(shí)心理預(yù)期是很快看到大概趨勢(shì)。rea的做法是兩條路并行。一條路是實(shí)時(shí)計(jì)數(shù)。聚合服務(wù)從NATS消費(fèi)事件后按照事件名分鐘級(jí)時(shí)間窗口在Redis里做自增計(jì)數(shù)器。比如keyrea:count:button_click:202506131420值就是這一分鐘內(nèi)這個(gè)事件的數(shù)量。另一個(gè)定時(shí)任務(wù)每分鐘把Redis中的值異步寫入PostgreSQL的匯總表作為長(zhǎng)期趨勢(shì)的依據(jù)。這樣查詢端想看最近五分鐘的趨勢(shì)直接查Redis毫秒級(jí)返回。另一條路是明細(xì)歸檔。同樣從NATS消費(fèi)事件但這條消費(fèi)者專門負(fù)責(zé)把原始事件寫入PostgreSQL的rea_events表供精確查詢和下鉆使用。為什么要拆成兩條消費(fèi)鏈路而不是消費(fèi)一條然后既聚合又入庫(kù)因?yàn)閮煞N操作的耗時(shí)差異很大。寫數(shù)據(jù)庫(kù)涉及磁盤IO和索引維護(hù)耗時(shí)不穩(wěn)定Redis自增是純內(nèi)存操作耗時(shí)非常穩(wěn)定。如果把它們混在一個(gè)管道里一次慢查詢就能拖住實(shí)時(shí)計(jì)數(shù)導(dǎo)致報(bào)表的實(shí)時(shí)名存實(shí)亡。分而治之讓實(shí)時(shí)鏈路盡可能短是rea一個(gè)很核心的設(shè)計(jì)決策。3.4 查詢API三個(gè)緩存的配合查詢API直接面向內(nèi)部看板穩(wěn)定性必須保證。rea的做法是三層緩存。第一層是本進(jìn)程內(nèi)的LRU緩存適合查同一個(gè)事件、同一個(gè)時(shí)間窗口的重復(fù)請(qǐng)求。第二層是Redis存的是分鐘級(jí)別的預(yù)聚合數(shù)據(jù)查詢時(shí)把時(shí)間段拆成分鐘做聚合再在內(nèi)存里合并。第三層才是數(shù)據(jù)庫(kù)只有當(dāng)窗口跨度過(guò)大或者需要按事件名做聯(lián)合過(guò)濾時(shí)才會(huì)執(zhí)行SQL查詢。為什么不能只用數(shù)據(jù)庫(kù)我實(shí)測(cè)過(guò)當(dāng)明細(xì)表數(shù)據(jù)到了幾百萬(wàn)行一條按事件名時(shí)間范圍做COUNT的SQL在PostgreSQL里大約需要200毫秒到1秒這對(duì)于網(wǎng)頁(yè)接口來(lái)說(shuō)還可以接受。但活動(dòng)大屏上的實(shí)時(shí)看板可能每5秒自動(dòng)刷新一次還疊加了三四個(gè)圖表如果全部打到數(shù)據(jù)庫(kù)高峰期查詢線程會(huì)被占滿連采集服務(wù)的連接都會(huì)被拖累。加入緩存之后大部分查詢落到了內(nèi)存數(shù)據(jù)庫(kù)壓力直線下降。一個(gè)典型的API返回結(jié)構(gòu){ event: button_click, granularity: 1m, points: [ { time: 2025-06-13T14:20:00Z, count: 1200 }, { time: 2025-06-13T14:21:00Z, count: 1345 } ], queryTimeMs: 12 }3.5 權(quán)限與數(shù)據(jù)治理內(nèi)部工具也有底線內(nèi)部工具最容易犯的毛病是能用就行權(quán)限和安全往后放。rea雖然只對(duì)內(nèi)部開(kāi)放我還是花了一點(diǎn)時(shí)間做了幾件基礎(chǔ)的事避免以后變成大麻煩。第一事件接入按項(xiàng)目隔離。不同的業(yè)務(wù)項(xiàng)目使用不同的token事件數(shù)據(jù)里帶上project_id查詢時(shí)默認(rèn)按當(dāng)前用戶可訪問(wèn)的項(xiàng)目過(guò)濾。第二userId在采集端就做哈希處理數(shù)據(jù)庫(kù)里不存明文。雖然會(huì)影響精確識(shí)別單個(gè)用戶的能力但對(duì)內(nèi)部事件分析來(lái)說(shuō)我們更關(guān)心群體行為哈希后的ID足夠算留存和漏斗。第三數(shù)據(jù)保留策略。明細(xì)表只保留90天匯總表保留兩年過(guò)期數(shù)據(jù)每天由定時(shí)任務(wù)清理。這條策略不是為了省存儲(chǔ)而是為了在有人問(wèn)你們憑什么存著我兩年前的操作記錄時(shí)我們有一個(gè)明確且合規(guī)的答案。4. 上線前后踩過(guò)的三個(gè)坑完整排查鏈路4.1 時(shí)間戳錯(cuò)亂設(shè)備本地時(shí)間把報(bào)表搞成了亂碼第一個(gè)坑在試運(yùn)行第二天就出現(xiàn)了。我打開(kāi)看板發(fā)現(xiàn)凌晨?jī)扇c(diǎn)出現(xiàn)了一大片page_view事件而當(dāng)時(shí)明顯沒(méi)有多少用戶在訪問(wèn)。再看明細(xì)表某些事件的occurred_at比received_at晚了整整8小時(shí)還有一些事件的occurred_at在未來(lái)。第一反應(yīng)是數(shù)據(jù)源有問(wèn)題。我檢查了采集服務(wù)和數(shù)據(jù)庫(kù)的系統(tǒng)時(shí)間同步服務(wù)器時(shí)間都是準(zhǔn)的又看了消費(fèi)服務(wù)的日志發(fā)現(xiàn)它寫入的received_at是服務(wù)端接收時(shí)間正確無(wú)誤。問(wèn)題只能出在事件本身的time字段。前端埋點(diǎn)代碼用的是Date.now()也就是設(shè)備本地時(shí)間。如果用戶手機(jī)的時(shí)間設(shè)置錯(cuò)誤或者人在海外沒(méi)有校準(zhǔn)時(shí)區(qū)事件時(shí)間就會(huì)偏差很大。修復(fù)方案分兩步。第一步將所有看板的時(shí)間計(jì)算基準(zhǔn)改為received_at也就是服務(wù)端接收時(shí)間保證什么時(shí)間到達(dá)系統(tǒng)是可信的。第二步仍然保留occurred_at作為業(yè)務(wù)分析用的體驗(yàn)發(fā)生時(shí)間但是消費(fèi)端增加了一個(gè)清洗邏輯如果occurred_at和received_at相差超過(guò)24小時(shí)就把occurred_at視為非法用received_at覆蓋并給事件打上一個(gè)clock_skew標(biāo)記。這樣既保住了絕大多數(shù)準(zhǔn)確的時(shí)間戳又不會(huì)讓少數(shù)設(shè)備問(wèn)題污染全局報(bào)表。這個(gè)坑給我的啟示是任何帶有設(shè)備端時(shí)間戳的系統(tǒng)都必須建立一個(gè)接收時(shí)間和發(fā)生時(shí)間的雙軌制并且要有明確的校準(zhǔn)策略。只信設(shè)備時(shí)間早晚會(huì)被雷到。4.2 高峰期寫入阻塞隊(duì)列共享帶來(lái)的連鎖問(wèn)題第二個(gè)坑出現(xiàn)在一次推廣活動(dòng)流量高峰。數(shù)據(jù)庫(kù)連接的等待時(shí)間瞬間拉高表象是明細(xì)表寫入變慢進(jìn)而導(dǎo)致看板上的實(shí)時(shí)指標(biāo)在高峰期掉了20分鐘左右的數(shù)據(jù)。我當(dāng)時(shí)的排查鏈路是先看消費(fèi)服務(wù)日志發(fā)現(xiàn)大量batch flush timeout再看NATS上的堆積數(shù)量超過(guò)正常水位十倍接著排查采集服務(wù)的隊(duì)列積壓情況發(fā)現(xiàn)內(nèi)存隊(duì)列已經(jīng)滿了并且Drop日志在大量刷屏說(shuō)明非核心事件正在被丟棄。按理說(shuō)丟棄之后積壓應(yīng)該緩解但指標(biāo)還是掉。最后我打開(kāi)了整個(gè)采集服務(wù)的線程池統(tǒng)計(jì)才發(fā)現(xiàn)問(wèn)題根源不是消費(fèi)端慢而是采集服務(wù)里接收線程和flush線程共用同一個(gè)線程池高峰期幾條大SQL查詢把線程池占滿之后連事件寫入NATS的線程也被阻塞了。也就是說(shuō)慢查詢通過(guò)線程池競(jìng)爭(zhēng)反向拖住了整個(gè)入口鏈路形成連鎖反應(yīng)。修復(fù)措施是把IO密集的寫管道和計(jì)算密集的SQL查詢徹底分離。采集服務(wù)只用獨(dú)立的一小簇線程處理接收事件寫NATS另一簇線程專門處理查詢或批量聚合。同時(shí)為NATS生產(chǎn)通道單獨(dú)設(shè)置積壓上限超過(guò)閾值時(shí)優(yōu)先丟棄非核心事件而不是讓所有線程一起去搶連接。這次改動(dòng)之后再遇到流量高峰實(shí)時(shí)鏈路基本穩(wěn)住了。排查線上問(wèn)題一定要先畫出請(qǐng)求的完整鏈路看看事件從入口到落庫(kù)要經(jīng)過(guò)哪幾個(gè)隊(duì)列、哪幾個(gè)線程池所有共享資源的競(jìng)爭(zhēng)都可能成為牽一發(fā)動(dòng)全身的瓶頸。4.3 指標(biāo)翻倍事件重放和缺少冪等鍵第三個(gè)坑是報(bào)表數(shù)據(jù)變成真實(shí)的四倍。我排查了一個(gè)下午才找到原因事后看相當(dāng)?shù)湫?。某天活?dòng)看板上顯示按鈕點(diǎn)擊量突然漲到了平日的四倍直覺(jué)告訴我這個(gè)暴漲不合理但前端流量統(tǒng)計(jì)并沒(méi)有明顯異常。排查過(guò)程是從明細(xì)數(shù)據(jù)開(kāi)始倒查的。我先查最近一小時(shí)哪個(gè)事件增長(zhǎng)最猛很快鎖定了click_feed_button然后對(duì)這一小時(shí)的事件按事件ID做去重發(fā)現(xiàn)ID的重復(fù)率接近75%。也就是說(shuō)看板上大部分?jǐn)?shù)字是重復(fù)上報(bào)帶來(lái)的。繼續(xù)往前看采集和消費(fèi)服務(wù)都沒(méi)有重復(fù)消費(fèi)的邏輯消費(fèi)確認(rèn)機(jī)制也正常于是我打開(kāi)了埋點(diǎn)的發(fā)送日志。真相浮出水面頁(yè)面在弱網(wǎng)環(huán)境下fetch失敗后SDK會(huì)自動(dòng)重試但重試時(shí)沒(méi)有重新生成事件ID每次失敗重試都會(huì)把同一個(gè)事件再次發(fā)送。更糟的是在某些瀏覽器里頁(yè)面關(guān)閉時(shí)多次觸發(fā)重發(fā)邏輯一條事件能被送出去三四次。修復(fù)很簡(jiǎn)單前端SDK在創(chuàng)建事件的時(shí)候保留同一個(gè)id但消費(fèi)端做冪等寫入。數(shù)據(jù)庫(kù)的rea_events表給id字段加了主鍵重復(fù)插入直接沖突報(bào)錯(cuò)匯總計(jì)數(shù)那里也按事件ID做了一次Redis的布隆過(guò)濾器重復(fù)事件不會(huì)再進(jìn)入計(jì)數(shù)。后端的冪等設(shè)計(jì)看起來(lái)像是多此一舉但在有網(wǎng)絡(luò)重試機(jī)制的分布式系統(tǒng)里這是人命關(guān)天的事。5. 實(shí)測(cè)效果和我的最終取舍5.1 一組可復(fù)現(xiàn)的壓測(cè)數(shù)字項(xiàng)目上線穩(wěn)定運(yùn)行一個(gè)月后我做了一組簡(jiǎn)單的壓測(cè)目標(biāo)是回答這套輕量級(jí)方案到底扛不扛得住。測(cè)試環(huán)境是兩臺(tái)2核4G的云主機(jī)一臺(tái)跑采集服務(wù)和NATS一臺(tái)跑PostgreSQL和聚合服務(wù)。壓測(cè)工具模擬客戶端以每秒100到5000的速率發(fā)送事件持續(xù)10分鐘。結(jié)果匯總?cè)缦掳l(fā)送速率事件/秒采集服務(wù)CPU數(shù)據(jù)庫(kù)CPU端到端P50延遲端到端P95延遲2005%8%400ms800ms100015%20%600ms1.2s300030%45%800ms2.8s500045%70%1.2s4.1s注意這里的端到端延遲指事件從瀏覽器發(fā)出到進(jìn)入聚合計(jì)數(shù)的時(shí)間整體在秒級(jí)滿足當(dāng)初秒級(jí)延遲的設(shè)定。一旦速率超過(guò)5000數(shù)據(jù)庫(kù)IO開(kāi)始吃緊采集服務(wù)內(nèi)存也會(huì)上漲但這已經(jīng)超出rea預(yù)期的目標(biāo)范圍了。如果你的業(yè)務(wù)量級(jí)遠(yuǎn)高于這個(gè)數(shù)就該考慮ClickHouse和真正的流處理框架了。5.2 和商業(yè)方案和開(kāi)源重方案的對(duì)比賬項(xiàng)目做完之后我把rea和一個(gè)中等價(jià)位的商業(yè)SaaS方案做了個(gè)粗略對(duì)比。按照我們每個(gè)月大約5000萬(wàn)事件的體量商業(yè)方案的年費(fèi)大約在五位數(shù)到六位數(shù)人民幣這個(gè)量級(jí)還不包括數(shù)據(jù)出域可能帶來(lái)的合規(guī)評(píng)估成本。rea的成本主要是兩臺(tái)云主機(jī)和一個(gè)人一個(gè)月大約30%的工作量整體低一個(gè)數(shù)量級(jí)。當(dāng)然商業(yè)方案帶來(lái)的價(jià)值也不能光看錢比如它有一堆現(xiàn)成的漏斗、留存、熱力圖分析不用自己開(kāi)發(fā)。但那些功能對(duì)當(dāng)時(shí)的我們來(lái)說(shuō)是低頻功能我們真正高頻用的只有實(shí)時(shí)趨勢(shì)、事件排行、基礎(chǔ)漏斗三個(gè)。為了低頻功能付出高頻成本不劃算。開(kāi)源重方案那邊也是一樣的道理。如果當(dāng)初直接上完整的流計(jì)算棧光是把環(huán)境撐起來(lái)、保證數(shù)據(jù)不丟就得花掉比業(yè)務(wù)開(kāi)發(fā)更多的時(shí)間。這也引出了我的一個(gè)核心觀點(diǎn)實(shí)時(shí)分析系統(tǒng)的復(fù)雜度應(yīng)該跟著業(yè)務(wù)量級(jí)走而不是跟著技術(shù)潮流走。5.3 項(xiàng)目后續(xù)的擴(kuò)展思路rea目前是能用狀態(tài)但我知道它離一個(gè)完整的數(shù)據(jù)平臺(tái)還差很多。這里列幾個(gè)我接下來(lái)打算做的方向。第一是漏斗分析。目前只能對(duì)單個(gè)事件做計(jì)數(shù)還沒(méi)有把多個(gè)事件按用戶ID串聯(lián)起來(lái)算轉(zhuǎn)化率。我打算基于明細(xì)表寫一個(gè)專門的事件序列查詢接口用哈希后的用戶ID做關(guān)聯(lián)預(yù)計(jì)三到五天能完成。第二是異常檢測(cè)。既然有了Redis里的分鐘級(jí)計(jì)數(shù)完全可以寫一個(gè)簡(jiǎn)單的檢測(cè)器當(dāng)當(dāng)前分鐘的事件數(shù)和過(guò)去7天同一分鐘的中位數(shù)相比偏離超過(guò)三倍時(shí)推送一條告警到內(nèi)部群里。這個(gè)功能對(duì)活動(dòng)期實(shí)時(shí)監(jiān)控特別有用不必等數(shù)據(jù)部門發(fā)現(xiàn)異常。第三是歷史數(shù)據(jù)遷移到ClickHouse。等到明細(xì)表超過(guò)一億行PostgreSQL的聚合查詢會(huì)越來(lái)越吃力屆時(shí)把rea_events同步到ClickHouse查詢接口只在掃描型查詢時(shí)切換數(shù)據(jù)源其余邏輯不用動(dòng)。因?yàn)楸斫Y(jié)構(gòu)從一開(kāi)始就是按分析場(chǎng)景設(shè)計(jì)的這個(gè)遷移成本很低。到這個(gè)階段我已經(jīng)把rea從臨時(shí)救火的腳本正式變成了一件持續(xù)迭代的工具。最后分享一點(diǎn)個(gè)人的實(shí)際體會(huì)。做這類內(nèi)部工具最大的瓶頸不是技術(shù)而是需求邊界。一開(kāi)始我也想把功能做全后來(lái)發(fā)現(xiàn)每個(gè)新增的順手功能都會(huì)帶來(lái)額外的復(fù)雜度。rea之所以能在三周內(nèi)上線并穩(wěn)定運(yùn)行靠的正是開(kāi)始時(shí)那句邊界宣言——輕量級(jí)、秒級(jí)延遲、關(guān)鍵事件、面向內(nèi)部。如果你也想搭一套類似的實(shí)時(shí)分析系統(tǒng)不妨先寫下這三行邊界再開(kāi)始選型。很多時(shí)候知道什么不做比知道做什么更值錢。