網站的消息（通知）系統一般是如何實現的？

01-25

就比如說知乎為每個用戶發送的通知這樣的功能。

我來嘗試回答一下把。像知乎這樣的通知系統通常都需要一個專門的隊列工具來實現。

說到隊列系統無非就兩種思路，一種是推的，一種是拉的。

每個用戶，問題等等可以關注的東西都有一個隊列，可以理解成一個有限大小的有序集合。

推的比較常見，就是例如這個知乎的這個問題，維護著一張關注者的列表，每當觸發這個問題推送的條件時（例如有人回答問題），就把這個通知發送給每個關注者。

拉的相對麻煩一點，就是推的反向，例如每個用戶都有一張關注問題的列表，每當用戶上線的時候，對每個問題進行輪詢，當問題的事件列表出現了比我原本時間戳大的信息就進行拉取。

由於贊同、評論，回答，感謝，關注，私信。。。。太多太多東西能夠觸發消息系統了，所以可以說知乎的消息系統非常的忙碌，當忙碌到一定程度的時候問題就出現了。例如在推的模式下，@張亮，@周源什麼的關注者極多，這種人突然抽風似得開始點擊贊同，系統就會出現一下要推給上萬上百萬人次的宕機困境，在拉的模式下，幾十個關注了所有知乎的所有問題所有活躍用戶的狂人突然高興了，一起上線也是一樣的道理。

所以這樣的消息系統平時問題不大，但是在消息峰值的時候卻通常是伺服器的噩夢。所以一般來說，一個網站在架構的時候，會為這樣忙碌的消息系統採用比較高速的存儲介質，例如 Redis ，MemCache 都是用內存，據說新浪微博還在幾台伺服器上用上了 L3 Cache .其次，這樣的消息系統通常需要一個延遲處理系統來進行工作顆粒的細化和調度，例如 Resque，DelayJob 這樣的開源庫，再次就是對於推拉模式的取捨進行優化，例如 Twitter 在伺服器較繁忙的時候只會對 Online 的用戶推送，offline 的用戶延遲推送，活躍用戶用推，不活躍用戶用拉，等等。

總之這個問題是大數據的時候比較典型的東西。不過，很多東西在產品出生前就做出架構是很難也是沒必要的，都是在具體問題演生的同時進行處理和升級。