本篇介紹筆者接觸的第一個后臺系統，從自身見聞出發，因此涉及的內容相對比較基礎，后臺大牛請自覺略過，
什么是好友系統？
簡單的說，好友系統是維護用戶好友關系的系統，我們最熟悉的好友系統案例當屬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解決，類似的問題還有很多，不再贅述，
總結一下，本篇主要介紹了好友系統的整體架構和部分模塊的實作方式，分布式系統中各個模塊的實作其實并不難，難點主要在于應對復雜網路環境帶來的問題（如丟包、時延等）和服務器例外帶來的問題（如為了應對服務器宕機會增加服務器冗余度，進而又會引發其它問題），
好友系統雖然簡單，但麻雀雖小五臟俱全，架構設計的各種技識訓本都有涉及，例如分層結構、負載均衡、平行擴展、容災、服務發現、服務器開發框架等方面，后面我會在各個不同的專案中介紹這些技術，敬請期待，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/37756.html
標籤：架構設計