QQ是怎樣創造出來的？——解密好友系統的設計

本篇介紹筆者接觸的第一個后臺系統，從自身見聞出發，因此涉及的內容相對比較基礎，后臺大牛請自覺略過。

什么是好友系統？

簡單的說，好友系統是維護用戶好友關系的系統。我們最熟悉的好友系統案例當屬QQ，實際上QQ是一款即時通訊工具，憑著好友系統沉淀了海量的好友關系鏈，從而鑄就了一個堅不可摧的商業帝國。好友系統的重要性可見一斑。

熟悉互聯網產品的人都知道，當產品有了一定的用戶量，往往會開發一個好友系統。其主要目的是增加用戶粘性（有了好友就會常來）或者增加社區活躍度（有了好友就會多交流）。

而我的后臺開發生涯就是從這樣一個系統開始的。

那時候，好友系統對于我們團隊大部分人來說，都是一個全新的事物，因為我們大部分人都是應屆生。整個系統的架構自然不是我們一群黃毛小孩所能創造。當年的架構圖已經找不到了，但是憑著一點記憶和多年來的經驗積累，還是可以把當年的架構勾勒出來。

如圖，好友系統的架構是常見的3層結構，包括接入層、邏輯層和數據層。

我們先從數據層講起。

因為我們對QQ太熟悉了，我們可以很容易地列出好友系統的數據主要包括用戶資料、好友關系鏈、消息（聊天消息和系統消息）、在線狀態等。

互聯網產品往往要面對海量的請求并發，傳統的關系型數據庫比較難滿足讀寫需求。在存儲中，一般是讀多寫少的數據才會使用MySQL等關系型數據庫，而且往往還需要增加緩存來保證性能；NoSQL（Not Only SQL）應該是目前的主流。

對于好友系統，用戶資料和好友關系鏈都使用了kv存儲，而消息使用公司自研的tlist（可以用redis的list替代），在線狀態下面再介紹。

接著是邏輯層。

在這個系統中復雜度最高的應該是消息服務（而這個服務我并沒有參與開發[捂臉]）。

消息服務中，消息按類型分為聊天消息和系統消息（系統消息包括加好友消息、全局tips推送等），按狀態分為在線消息和離線消息。在實現中，維護3種list：聊天消息、系統消息和離線消息。聊天消息是兩個用戶共享的，系統消息和離線消息每個用戶獨占。當用戶在線時，聊天消息和系統消息是直接發送的；如果用戶離線，就把消息往離線消息list存入一份，等用戶再次登錄時拉取。

這樣看來，消息服務并不復雜？其實不然，系統設計中常規的流程設計往往是比較簡單的，但是對于互聯網產品，異常情況才是常態，當把各種異常情況都考慮進來時，系統就會非常復雜。

這個例子中，消息發送丟包是一種異常情況，怎么保證在丟包情況下，還能正常運行就是一個不小的問題。

常見的解決方法是收包方回復確認包，發送方如果沒收到確認包就重發。但是確認包又可能丟包，那又可以給確認包增加一個確認包，這是一個永無止境的確認。

解決方法可以參考TCP的重傳機制。那問題來了，我們為什么不用TCP呢？因為TCP還是比較慢的，聊天消息的可靠性沒有交易數據要求那么高，丟幾條消息并不會造成嚴重后果，但是如果用戶每次發送消息后都要等很久才能被收到，那體驗是很差的。

一個比較折中的方案是，收包方回復確認包，如果發送方在一定時間內沒有收到確認就重發；如果收包方收到兩個相同的包（自定義seq一樣），去重即可。

一個面試題引發的討論：

面試時我常常會問候選人一個問題：在分布式系統中怎樣實現一個用戶同時只能有一個終端在線（用戶在兩個地方先后登錄賬號，后一次登錄可以把前一次登錄踢下線）？這是互聯網產品中非常基礎的一個功能，考察的是候選人基本的架構設計能力。

設計要先從接入服務器（下稱接口機）說起。接口機是好友系統對外的窗口，主要功能是維護用戶連接、登錄鑒權、加解密數據和向后端服務透傳數據等。用戶連接好友系統，首先是連接到接口機，鑒權成功后，接口機會在內存中維護用戶session，后續的操作都是基于session進行。

如圖所示，用戶如果嘗試登錄兩次，接口機通過session就可以將第一次的登錄踢下線，從而保證只有一個終端在線。

問題解決了嗎？

沒有。因為實際系統肯定不會只有一臺接口機，在多臺接口的情況下，上面的方法就不可行了。因為每個接口機只能維護部分用戶的session，所以如果用戶先后連接到不同的接口機，就會造成用戶多處登錄的問題。

自然可以想到，解決的方法就是要維護一個用戶狀態的全局視圖。在我們的好友系統中，稱為在線狀態服務。

在線狀態服務，顧名思義就是維護用戶的在線狀態（登錄時間、接口機IP等）的服務。用戶登錄和退出會通過接口機觸發這里的狀態變更。因為登錄包和退出包都可能丟包，所以心跳包也用作在線狀態維護（收到一次心跳標記為在線，收不到n次心跳標記為離線）。

一種常用的方法是，采用bitmap存儲在線狀態，具體是指在內存中分配一塊空間，32位機器上的自然數一共有4294967296個，如果用一個bit來表示一個用戶ID（例如QQ號），1代表在線，0代表離線，那么把全部自然數存儲在內存只要4294967296 / (8 1024 1024) = 512MB（8bit = 1Byte）。當然，實現中也可以根據需要給每個用戶分配更多的bit。

于是，踢下線功能如圖所示。

用戶登錄的時候，接口機首先查找本機上是否有session，如果有則更新session，接著給在線狀態服務發送登錄包，在線狀態服務檢查用戶是否已經在線，如果在線則更新狀態信息，并向上次登錄的接口機IP發送踢下線包；接口機在收到踢下線包時會檢查包中的用戶ID是否存在session，如果存在則給客戶端發送踢下線包并刪除session。

在實際中，踢下線功能還有很多細節問題需要注意。

又回到用戶先后登錄同一臺接口機的情況：

圖中踢下線流程是正確的，但是如果步驟10和13調換了順序（在UDP傳輸中是常見的）會發生什么？大家可以自己推演一下，后到的踢下線包會把第二次登錄的A’踢下線了。這不是我們期望的。怎么辦呢？

解決方法分幾個細節，①接口機在收到13號登錄成功包時，先將session A替換成session A’，然后給客戶端A發生踢下線包（避免多處存活導致互相踢下線）；②踢下線包中必須包含除用戶ID外的其他標識信息，session的唯一標識應該是ID+XXX的形式（我最開始采用的是ID+LoginTime），XXX是為了區分某次的登錄；③接口機在收到踢下線包的時候只要判斷ID+XXX是否吻合來決定是否給客戶端發踢下線包。

現實情況，問題總是千奇百怪的，好在辦法總比問題多。

比如我在項目中遇到過接口機和在線狀態服務時間漂移（差幾秒）的情況。這樣踢下線的唯一標識就不能是用戶ID+LoginTime的形式了。可以為每次的登錄生成一個唯一的UUID解決。類似的問題還有很多，不再贅述。

總結一下，本篇主要介紹了好友系統的整體架構和部分模塊的實現方式。分布式系統中各個模塊的實現其實并不難，難點主要在于應對復雜網絡環境帶來的問題（如丟包、時延等）和服務器異常帶來的問題（如為了應對服務器宕機會增加服務器冗余度，進而又會引發其它問題）。

好友系統雖然簡單，但麻雀雖小五臟俱全，架構設計的各種技術基本都有涉及。例如分層結構、負載均衡、平行擴展、容災、服務發現、服務器開發框架等方面，后面我會在各個不同的項目中介紹這些技術，敬請期待。