Twitter工程經理Sarrabh Pathak在倫敦QCon 2017大會上介紹了Twitter網站的通知系統架構。他主要介紹了Twitter所面臨的獨特挑戰，比如社交網絡的雙峰（bimodal）性、如何應付尖刺流量以及如何實現實時的通知機制。
Pathak解釋說，與一般的社交網絡不同，Twitter的用戶數據具有不對稱性。有些用戶有數百萬關注者，而有些則只有不到百人。這導致了通知具有雙峰性，也給實現實時通知帶來了挑戰。例如，名人的推文比普通人的推文產生更大的通知負載。
Pathak說，不同類型的用戶以及嚴格的性能需求給架構帶來了如下挑戰：
延遲：人們要盡可能快地收到通知，畢竟Twitter需要實時地通知用戶當下正在發生的事情。展開（fanout）：一個擁有數百萬關注者的用戶，他的一個推文會觸發數百萬個通知，系統必須能夠處理這種大型的尖刺流量。不均衡的調用：有些內部調用，比如訪問緩存，只需要幾毫秒。而有些外部調用，比如訪問Google，可能需要半秒多鐘。在進行伸縮時必須考慮到這些情況。多數據中心：Twitter必須盡可能地具備彈性，即使發生了故障，也要保證用戶仍然能夠收到通知。首先，通知分為推送和拉取兩種模式。人們在訪問Twitter時看到的通知信息流使用的是拉取模式，而短信和郵件則使用推送模式。
Pathak說，對于拉取模式，通知一般是從緩存里獲取的，因為信息流的生成是很耗費資源的。Twitter使用了Manhatten，Twitter的實時分布式后端存儲，也是Redis的一個分支。通過使用緩存，最小化了延遲，提升了用戶體驗。與此同時，通知信息流通過異步的方式被復制到多個數據中心，目的是在發生故障時，用戶仍然能夠看到相同的信息流。
為了應對延遲和尖刺流量問題，Twitter使用了推送通知模式，不僅進行橫向伸縮，同時還使用了臨時緩存。這解決了同一個用戶有數百萬個通知事件的問題。
為了解決不均衡調用問題，Twitter使用了優先級隊列來防止調用阻塞；名人的推文不會對其他用戶的登錄造成阻塞。另外，不同類型的調用被分成組，這意味著因外部依賴發生宕機造成的影響是相互隔離的。
最后，Pathak對該架構進行了總結：
盡可能專注在異步操作上，因為它比同步操作更容易伸縮。在權衡讀取時間和寫入時間時，考慮只寫入不太可能發生過期的數據，比如ID。確保應用能夠支持多數據中心部署。整個訪談可以在線觀看，里面還有一個來自Twitter工程師Gary Lam關于個人定制化通知的訪談。
查看英文原文： Real-Time Notifications at Twitter
京公網安備 11010502049343號