十點過一分的通知：微信運動的推送，是一頁被算好時間的介面

2026 年 10 月 22 日，掘金上一篇技術文章重新討論了一個多數人每天收到卻很少細看的東西：微信運動的晚間推送。每天晚上十點多，微信會發一條消息，告訴你今天走了幾步，順帶提醒你去看排行榜。作者注意到一個細節：推送時間並不統一，體感上在十點整後的一分鐘上下浮動。

這一分鐘的鬆動，正是整件事最值得看的地方。一條通知的到達時間被設計成一個區間而非一個整點，背後對應的是一套把「什麼時候發」與「怎麼發」拆開的排程設計。

一秒之內的一億件事

文章用一個假設值算帳：若日活一億，希望所有提醒在一分鐘內發完，平均每秒要處理約 167 萬條。如果全部任務都定在 22:00:00 觸發，那就是一億條訊息落在同一秒。

最直覺的做法撐不住。一張任務表加一個單機定時掃描，按每秒五千條估算，發完全部要五個半小時，通知會拖到凌晨三點半才送完。文章給出的拆法是三層：調度器到點只負責把這批用戶塞進佇列，發送交給消費端，佇列在這裡的角色是緩衝；再按 uid 分片給多個調度實例；最後把一分鐘切成六十秒，用 hash 決定每個用戶落在第幾秒，讓流量由雜湊保證大致均勻。

用戶能感知到的，只是「十點過一會兒收到」。精確到秒的差異沒有人看得出來，這一分鐘怎麼排，是系統自己能決定的自由度。這是介面設計裡常見的取捨：把使用者不在意的精度讓渡給系統，換來整體的平穩。

這與我們先前分析過的WorkBuddy 簽到機器人的訊息設計是同一類課題，一條每天準時抵達的通知，真正的設計工作都發生在使用者看不見的那一側。

好友榜：每個人看到的那一份都不一樣

推送只是入口，點進去之後是排行榜。文章指出，榜單其實有兩種完全不同的東西。

全域榜是所有人看同一份排名，用 Redis 的 ZSet 就能做，更新與取前若幹名的複雜度都在對數級別。一億成員約佔十 GB 記憶體，代價不小，但方向可行。

好友榜是另一回事。每個人看的是「我的好友裡誰走得最多」，成員集合與名次都因人而異，全域榜的名次回答不了這個問題。若給每人一份 ZSet，假設平均兩百個好友，就是兩百億個條目，達 TB 級的常駐記憶體，而這份資料一天只被結算一次。更麻煩的是寫入：一個人白天持續上報步數，每次增量都要同步改所有好友榜裡的那一條，寫放大兩百倍。

即時計算是另一條路：取兩百個好友的步數，現場排序回傳。成本換了位置，從儲存換到查詢。

榜單先被排好了順序，情緒也跟著排好了

從設計角度看，微信運動的排行榜是一種高明的排序介面。它不需要即時，一天結算一次就夠；它不需要絕對精確，好友之間差個幾步無人在意。它真正要做的事，是在每晚十點這個一天將盡、適合回顧的時刻，把「你和你的朋友今天走了多少」排成一幅可比較的畫面。

我們在直播打賞排行榜的親密感設計裡看過排行榜如何塑造行為，微信運動的榜單是同一套機制溫和許多的版本：它用好友關係做成員過濾，用步數做排序鍵，用晚間推送做入口，把一個健康行為包裝成一場每天舉行一次、賭注極低的小型競賽。

掘金那篇文章沒有猜測微信內部的實際實作，它只是把問題攤開：一億條任務怎麼調度、每人的榜怎麼算、是不是真的都要提前算好。這種攤開本身就有價值。一條每晚準時出現的通知，看似只是把數字讀出來發一下，實際上時間被切成了秒，任務被切成了片，排行榜在儲存與計算之間被反覆權衡。

使用者看到的是一行步數與幾個名字的排序。看不見的，是那一分鐘裡每秒一百多萬次的從容。