消息同步 —— 在 Airbnb 咱們是怎樣擴展移動消息的

• 原文地址：Messaging Sync — Scaling Mobile Messaging at Airbnb
• 原文做者：Zhiyao Wang, Michelle Leon , Jason Goodman , Nick Reynolds , Julia Fu , Jeff Hodnett , Manuel Deschamps , John Pottebaum, Charlie Jiang
• 譯文出自：掘金翻譯計劃
• 譯者：Tuccuay
• 校對者：ZhangRuixiang , zhangqippp

弱網環境下的新舊收件箱對比

隨着從移動端發出的消息條數超過每小時 100k，消息傳遞成爲了 Airbnb 應用中被使用得最頻繁的功能，可是咱們以前用在移動版收件箱中獲取消息的方法緩慢且不能保證數據的一致性，必需要有網絡鏈接才能閱讀消息。這些緣由致使了移動版收件箱的房東和遊客的體驗都不太好。爲了讓收件箱更快、更可靠、更一致，咱們在 Airbnb 中構建了消息同步機制。

舊版收件箱的實現方式相似於上世紀末的郵箱客戶端，用戶每點擊一次，就網絡加載一次，從而獲取須要展現的消息。經過消息同步，只有當數據改變時纔會更新消息內容和消息列表，從而大大減小了網絡請求的數量。這意味着在收件箱和消息列表之間來回切換導航的速度快了不少，大部分時間都是用本地緩存來展現數據，而再也不須要在進入每一個界面的時候都發起網絡請求。消息同步還減小了每一個網絡請求的響應大小，從而使 API 的響應速度提高了兩倍之多。這些體驗優化在網速較慢的地區尤其明顯。

如下爲消息同步的工做方式，分三種狀況：

情景 1： 全幅增量更新

常見的情景是這樣的：

1. 移動客戶端使用本地存儲的 sequence_id （好比 1490000000，表示客戶端上一次與服務器同步的時間）請求同步。
2. API 服務器只返回全部已修改的消息對象和新的消息並附帶一個新的 sequence_id （好比 1491111111）。
3. 移動客戶端將這些被修改的消息和新的消息和本地數據庫合併。
4. 移動客戶端還要存儲新的 sequence_id 以供下次使用。

情景 2：初始化同步

這是在有大量的消息更新須要返回時的方案。好比當用戶首次下載 app 的時候，服務器須要發送 10 個會話對象和 30 個消息以進行全增量更新。完整的增量同步響應體將會很是巨大，這將致使更長的加載時間和更差的用戶體驗。因此這個時候，咱們只返回當前屏幕須要展現的會話。

1. 移動客戶端使用本地存儲的 sequene_id 來調用同步 API。
2. API 服務器估計徹底增量同步的響應體大小，而且判斷以爲它太大了。
3. API 服務器僅返回最新 N 個會話對象，足夠客戶端渲染整個屏幕而沒有空白。
4. 客戶端清除本地的數據庫。
5. 客戶端存儲最新的消息和 sequence_id。
6. 當用戶打開會話時，客戶端會向服務器請求這個會話的全部消息。
7. 當用戶在收件箱中瀏覽歷史記錄時，客戶端會發送分頁請求來獲取會話的消息。

情景 3：刪除會話

會話有時候會須要從應用中移除。好比當房東搭檔再也不管理這個房子的時候，服務器將刪除房東搭檔和房客之間的會話。在這種狀況 API 會在最後一次同步時發送包含全部須要刪除的會話 ID 數組。

迴歸測試

當遷移到新的消息同步 API 的時候，有幾個須要注意的點：

1. Airbnb 的消息系統與核心的預約流程及其它產品邏輯緊密結合。服務器須要監聽那些會影響數據在屏幕上顯示的變更。好比當行程完成後，應用須要在會話中顯示「評價」按鈕。咱們當時有兩種方案可選：一個是在閱讀消息的時候檢查評論對象是否被修改；另外一個是訂閱評論對象的狀態並在下一次讀取會話消息的時候改變它。咱們選擇了第二種方案，由於這種方案節省資源。可是，監控這些能影響 UI 改變的對象，是一個挑戰。

2. 更新後的會話可能和本地存儲的會話有不一樣的順序。咱們須要確保在合併數據後可以正確的刷新 UI。

爲了抓取在舊的消息 API 和新的消息同步 API 返回的數據之間的差別，一小部分應用同時運行新舊兩套 API 進行抽查。它記錄兩套 API 返回的會話中全部的屬性值和會話順序。這容許咱們對新的 API 迴歸測試並進行快速迭代。每當遇到一個 bug 時，服務器會將會話對象標記爲已修改，以便在下一次同步時糾正錯誤。

結論

1. 消息同步 API 將請求的延遲減小了一半。相對於舊的API（下面突出的藍線），新的API的網絡請求更加穩定。

1. 消息同步使用戶可以在飛行模式或者網絡情況不佳的狀況下閱讀消息。

在推出消息同步和其餘關於消息的改進以後，咱們看到更多的消息從手機上發送了（在 Android 和 iOS 上分別是 +3.8% 和 +5.3%），從網頁上發送的消息變少了（-4.6% 和 -4.2%）。而且天天查看收件箱的次數也提高了（+200% 和 +96%），由於它如今是房東的首頁。這個發佈對於咱們房東社區來講是一個很是巨大的勝利，由於消息是房東在 Airbnb 上最經常使用的功能。

最後說一下，若是你有興趣創造一個蓬勃發展的社區，在世界各地款待你們，Host & Homes 團隊正在招募工程師 尋找有才華的人加入！

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、React、前端、後端、產品、設計 等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃。