狀態模型

presence 模型通常包含 subject、node、last_seen_at、ttl。主體可能是使用者、裝置、連線或工作者。模型設計重點是查詢責任：需要查單一主體是否在線、查群組在線清單，還是查節點負載分布。

presence 資料具備高變動、短保留特性。設計時應避免把正式業務欄位混入 presence store，讓它保持可快速更新與快速過期。

heartbeat 與 expiration

heartbeat 的責任是維持活性訊號，expiration 的責任是清理失效狀態。heartbeat 間隔太長會放大誤判離線，太短會增加寫入壓力。expiration 視窗要和網路抖動容忍度一起設計。

穩定做法是定義「可接受延遲在線」窗口，而不是追求絕對即時。presence 判讀通常是近即時近似，不是強一致保證。

cross-node query

跨節點查詢要先明確一致性需求。聊天室在線名單可容忍短暫不一致；調度系統節點可用性則需要更保守窗口與校驗策略。查詢層應同時提供快取讀取與回源校正路徑，避免單一路徑失真。

在多區部署中，presence 常採區域內優先、跨區聚合延遲同步。這樣能降低廣域寫入成本，同時保留可接受的全域可見性。

cleanup 策略

cleanup 的責任是避免殭屍狀態堆積。定期掃描、lazy cleanup、事件驅動清理可混合使用。清理策略要與業務容忍度對齊：社交場景可容忍秒級延遲清除，調度場景則需更快收斂。

判讀訊號

常見誤區

把在線狀態儲存當正式狀態來源，會讓一致性與修復成本快速上升。presence 模型適合即時協調，最終業務判定仍由正式資料層承擔。

把 heartbeat 當固定頻率任務，也會造成高峰寫入抖動。頻率應該與線上人數與連線型態一起調整。

案例回寫

presence 模型可用 2.C2 Meta：mcrouter 跨區路由 回寫。先看跨區路由如何影響在線可見性，再回到本章檢查 heartbeat 視窗、跨節點聚合與清理節奏是否一致。 這個案例主要支撐的是「跨區可見性與狀態新鮮度」判讀，不直接支撐 lock 租約或 queue 語意；若問題是互斥衝突或重播邊界，應轉到 2.4 或 3.x。

若區域內在線正常、跨區可見性延遲偏大，先調整跨區同步策略與 fallback 壽命，再把影響評估接到 8.20 Customer Impact Assessment。

跨模組路由

1. 與 2.3 的交接：保留與清理策略回到 TTL 與 eviction。
2. 與 4.17 的交接：presence 資料品質與延遲偏差回到 Telemetry Data Quality。
3. 與 6.22 的交接：穩態定義與高峰演練回到 Steady State Definition。
4. 與 8.20 的交接：即時狀態誤判造成客戶影響回到 Customer Impact Assessment。
5. 與 2.10 的交接：presence 狀態變更如何即時廣播給其他節點回到 Pub/Sub 與即時 fan-out。

下一步路由

要看快取層一致性與失效策略，接著讀 2.2 cache aside 與失效策略。要看 presence 狀態變更如何即時扇出給其他節點，接著讀 2.10 Pub/Sub 與即時 fan-out。要看跨規模 presence 路由案例，接著讀 2.C2 Meta：mcrouter 跨區路由。