去年我負責為一個交易平台做即時監控儀表板。需求是：以百萬事件/秒的速率可視化市場資料，從事件發生到用戶螢幕的延遲要低於 100ms。
這把我們過去對資料可視化的認知全打破了。
「即時」的真相
沒人會告訴你的是：「即時」往往並不是真正的即時。而且很多時候這沒問題。
大多數標著「即時」的儀表板其實是每 5–30 秒重新整理一次。對多數場景這已經夠用。但當你真的需要亞秒級更新時，規則就完全變了。
「即時」的三個層級
層級 1：近即時（5–60 秒重新整理）
典型場景：業務儀表板、行銷分析、銷售指標
架構：輪詢 API、批次彙總
複雜度：中等
這是大多數人需要的：資料團隊每分鐘彙總一次，儀表板輪詢更新，簡單有效。
層級 2：即時（1–5 秒重新整理）
典型場景：維運監控、即時活動追蹤、客服佇列
架構：WebSocket、服務端推送、串流查詢
複雜度：高
從輪詢到推送，一切都不一樣了：要維護長連線、處理重連、管理客戶端/服務端狀態。
層級 3：亞秒級（小於 1 秒）
典型場景：交易平台、即時遊戲統計、工業監控
架構：串流管道、專用資料庫、優化渲染
複雜度：很高
我們在這個層級待了 8 個月，每一處優化、每一毫秒都算數。
即時可視化難在哪
問題 1：資料量
每秒 100 萬事件時，不可能逐條渲染——那是每秒 100 萬個點，瀏覽器會崩。
做法：預彙總。不要把原始事件推到前端，在源頭按時間桶做均值、計數、分位數等彙總。我們每秒只發 10 次彙總結果，而不是 100 萬條原始事件。
問題 2：渲染效能
即使每秒只有 10 次更新，整圖重繪也會拖垮效能。React 的調和、SVG 操作、Canvas 重畫都會疊加。
做法：增量更新。不要重建整張圖，只追加。我們對最高頻的圖用了基於 WebGL 的渲染，可以穩定跑 60fps 更新。
問題 3：人眼與認知
一個反直覺的結論：更新快於約 200ms 就會糊成一片。用戶處理不了 10+ fps 的資訊，只會覺得在閃。
做法：視覺平滑。即使資料是 10Hz 更新，我們把過渡動畫拉長到 200ms，圖表既「活」又不亂。
問題 4：網路不穩定
WebSocket 會斷、封包會延遲、行動端會切網。
做法：可靠重連、訊息佇列、優雅降級。斷線時展示上次已知狀態並顯示「重連中」，而不是白屏。
我們用的架構
滿足「百萬事件/秒」的大致技術棧是：
資料層
- Apache Kafka 做事件接入
- Apache Flink 做即時彙總
- Redis 做最新狀態快取
- TimescaleDB 做歷史查詢
API 層
- Go 寫 WebSocket 服務（高並行友好）
- gRPC 做內部服務通訊
- 訊息批次發送（每 100ms 發一批，而不是每個事件一發）
前端
- React 負責 UI 結構
- WebGL（透過 regl）做高頻圖
- 輕量 Canvas 做中頻圖
- SVG（透過 D3）只用於低頻、強互動的圖
關鍵決策
- 盡量早彙總：前端應拿到「可直接展示」的資料，而不是原始事件。
- 區分更新頻率：不是每個元素都要 10fps，靜態上下文可以 30 秒一更。
- 讓用戶選粒度：在「總覽」（更新慢、資訊多）和「明細」（更新快、視野集中）之間可選。
效能優化
服務端
- 預計算時間桶，別讓客戶端算「最近 5 分鐘」
- 增量編碼：只發變化量，不發全量
- 壓縮：對 WebSocket 訊息做 gzip，效果明顯
- 連線複用：多訂閱共用連線
客戶端
- 物件池：複用圖表元素，減少 GC
- 用 RequestAnimationFrame 把更新對齊到瀏覽器渲染
- Canvas 分層：靜態一層、動態一層
- Web Worker：在主線外解析入站資料
不推薦
- 用 SVG 做高頻更新（DOM 太慢）
- 用 Redux 管即時狀態（更新太頻繁時開銷大）
- 用通用圖表庫做 >5fps（大多沒為這類場景優化）
即時場景的 UX 教訓
教訓 1：把控制權交給用戶
不是所有人都想要即時重新整理，有人會覺得干擾。我們加了：暫停按鈕、更新頻率選擇（1 秒 / 5 秒 / 30 秒）、歷史模式（「顯示 5 分鐘前的狀態」）。
教訓 2：狀態要一目了然
用戶需要知道：當前是即時還是歷史？上次更新是什麼時候？連線是否正常？
我們加了一個隨每次更新脈動的「心跳」指示，對安心感幫助很大。
教訓 3：處理好「無聊」狀態
大部分時間沒有異常，圖表只是用相近的值在更新。
這時要靠標註：「14:32 檢測到尖峰」把注意力引到有意義的變動上，否則用戶面對的是噪音。
教訓 4：行動端要區別對待
螢幕小、網路差、要省電。行動端應：自動降低更新頻率、簡化圖表、加強重連邏輯。
何時不必做「即時」
做完這套系統後，我對「即時」需求更謹慎了。要先問：
- 更快更新會改變用戶行為嗎？
- 用戶真能在那麼快的節奏下行動嗎？
- 工程成本值嗎？
對多數儀表板，答案是否定的。15 秒重新整理往往就夠了，把「即時」留給「秒級真的重要」的場景。
工具與資源
層級 1–2（近即時、即時）：
像 ChartGen 這類工具可以產生能有效輪詢 API 的圖表，配合 WebSocket 介面就能做出不錯的即時儀表板，無需自建整套基礎設施。
層級 3（亞秒級）：
需要專門方案：D3 + Canvas、自研 WebGL、或 uPlot、Apache ECharts 的增量更新模式等。
串流基礎設施可選：
- Apache Kafka + Flink（複雜但強大）
- AWS Kinesis + Lambda（託管但有限）
- Redis Streams + 自研彙總（簡單但擴展性較弱）
如何監控即時系統
我們關注：端到端延遲（事件時間戳到像素上螢幕）、連線健康（每小時重連次數）、渲染效能（幀率）、用戶參與（是否真的在看即時視圖）。
一個發現：很多人打開儀表板看兩分鐘就切到背景，「即時」資料大多沒被看到。
最後一點
即時可視化既是工程挑戰，也是 UX 挑戰。最難的不是把資料盡快送到螢幕，而是以人類能理解和行動的方式呈現。
在做即時之前先問：用戶有了更快的資料，到底會多做哪一步？
如果答案不清楚，可能根本不需要即時。