導讀：
　　轉貼：QQ的架構問題
　　-----------sodme 大寶
　　hi, all:
　　我把第一個問題選為：QQ的架構。呵呵，題目是不是有點大？QQ現在的最高線上使用者數是1900萬，我們來討論一下要作一個這樣的架構如何來作更好，大家積極發言，這也是我這個週末為自己選擇的思考題，呵呵。大家積極暢所欲言。
　　我們討論的問題可以包括但不限於這些內容：
　　１.登入時的負載如何解決的
　　２.伺服器主要作哪些事，負載如何解決
　　３.資料庫負載如何解決
　　...
　　------------- Arbow
　　我來這看熱鬧的，也沒做過啥大系統，隨便說兩句啊:)
　　按照我們的設想，對於3，是不會使用資料庫來撐大訪問量的，特別是一些不需要實時更新的資料，會通過一個的Server對資料進行彙總，然後在資料庫比較空閒的時間段進行批量更新。而客戶端查詢相關資訊，也不會直接查詢資料庫，而是直接連線Server來獲取。對於這些Server群的負載，就有很多方法了，沒做過，就不紙上談兵啦。
　　另外說說Web負載，根據HTTP協議返回的資訊，QQ是使用Apache來實現Web負載的，Apache雖然定製非常方便，擴充套件性強，但是效能並不是最優的。Google就實現了它自己的WebServer
　　GWS
　　(Gmail中是GFE？？)，跟它的GFS緊密結合起來，效能做到最好。
　　好了，搬個小板凳看老大們發言啊@

[email protected]
　　-------------tingya
　　QQ的後臺用的是MySQl資料庫哦，呵呵，是不是不可思議啊？不過整個MySqL都是面目全非了，被QQ的人修改的不成人形。效能非常的高，尤其資料的讀取和儲存。
　　QQ的伺服器技術號稱世界領先，呵呵，
　　------------Donald
　　只知道QQ的廣告伺服器是分省的，廣告下發要一到兩天，其他的就不知道了
　　登陸和登出確實是個比較麻煩的事情，要通知到所有的好友，所以使用者資料必須是集中的，登陸有時候通知會失效，不知道是不是UDP的協議，聽大家說說
　　---------- Roger Chen
　　以前對MSN Messenger協議有所研究，MSN Messenger伺服器可以分為三類：Dispatch
　　Server(DS)、Notification Server(NS)、Switchboard Server(SB)。
　　DS是Messenger登陸時首先連線的伺服器。然後DS指定一個NS的IP返回給客戶端，
　　然後關閉連線。
　　Messenger接著連線到得到的NS IP地址，所有的操作資訊，比如新增好友、刪除好
　　友，更名等等都是通過NS的這個連線完成。只要Messenger線上，該連線會一直保
　　持。
　　如果要開始對話，發起人傳送指定指令到NS，NS返回一個指定的SB IP，接受者會
　　在其NS連線上也收到該SB IP的通知。然後雙方均連線到該SB上進行對話，對話完
　　成後關閉連線。
　　以下是我對這三種伺服器的看法：
　　DS採用的負載均衡方式應該比較簡單，通過DNS解析來做負載均衡。並且由於在DS
　　上的連線都是短連線，保持時間非常短，所以應該DS伺服器的數量應該不會很多。
　　由於DS必須要返回一個可用的NS IP，那麼內部應該還有其他種類的伺服器來儲存
　　當前所有可用的NS伺服器，以及這些NS伺服器上的負載。通過DS這一層來為接下來
　　的NS做負載均衡。
　　NS連線均為長連線，所以在這一層上的負載由DS來調節。如果NS負載太大，新客戶
　　連線上DS時會返回其他相對空閒的NS伺服器。當然NS伺服器之間也有相互通訊的機
　　制也是少不了的，比如上下線通知、對話發起等等。
　　SB連線的時間介於NS和DS之間，其負載由NS來作控制。對話完成後和SB之間的連線
　　就關閉了。不過由於所有的對話都在SB上進行，MS的伺服器資源再強也會吃緊，所
　　以現在新版的MSN Messenger都加入了P2P Message型別，在發起對話的時候會判斷
　　如果雙方都支援P2P Message，則會直接點對點連線連線，繞過SB這一層。
　　-----------------anders lin
　　我認為qq登入也是差不多這樣。
　　其登入採用udp（預設登入方式）， 登入伺服器（相當於NS）不需要保持連線的，負載很好做。
　　至於對話，qq和msn一樣，都是P2P訊息（可以開啟msn的連線日誌看到），不過msn在8.0之前，不支援離線訊息。
　　所以，我很關鍵的技術問題，應該在於資料庫上，一些表必須違反正規化，做特別的冗餘。
　　-------------------zhuam
　　接觸網路程式設計有一年多了， 感觸頗深啊，
　　在此我要感謝 Roger Chen
　　，他幫我解答過不少的問題，謝了，
　　我一直在做XMPP Server 端的開發工作， 是基於Jive wildfire
　　來做二次開發， 由於Jabber 是採用 TCP
　　的方式來交換資訊，也有用 HTTP
　　的方式，那是在5222埠被封的情況下，我們會通過HTTP
　　的80 斷口來交換資訊，基於TCP 的 Server
　　有一個缺點，那就是必須要保持連線，這是很浪費資源的，當達到十萬
　　- 百萬級的線上後，我認為最好的方式是基於UDP 的
　　Server ，那也是最靈活的，做P2P 的IM Client
　　也是最靈活的。
　　Skype 是做P2P IM 最好的一個，
　　他的方式是我最為欣賞的，不是QQ MSN
　　的架構能比的，真的，這種IM
　　的架夠才是我們需要實現與學習的。
　　------------------ top(木)
　　象QQ這樣的規模是採用分佈構價的,有點象DNS伺服器不是完全一樣，但是可以用來理解巨大的訪問量可以被複數的伺服器分擔。QQ的伺服器也應該分DS、 NS、SB三種或其他若干，其實就是在實際應用中伺服器設定的比例不同,我不知道非會員是否伺服器需要記錄聊天記錄如果不要NS負荷也不大，線上也不用實時連線的這樣NS的負荷就大幅度下降了。而P2P是QQ使用者之間交換資料於伺服器無關忽略不計。而離線問題，只有在一位使用者已經不線上的情況下，才向伺服器傳送聊天記錄，或者該使用者是會員在向對方傳送記錄的同時在向伺服器傳送記錄，這樣伺服器只需要處理會員的聊天記錄和暫時無法到達的聊天記錄。一臺伺服器用10萬的併發流量來說（理論）,而且10W個使用者並非同時向伺服器傳送記錄。使用者登陸由DS
　　NS負責的，通知到所有的好友。這個由其他伺服器負責，登陸、離線發生的頻率更加稀疏。這樣負載不會很大。其實不夠了再加伺服器。關鍵是構架可以擴充套件。對於資料庫我覺得他們是採用分散式資料庫。QQ對使用者沒有彙總式查詢。將一些使用者的資料放在樹的某的節點上。可以把每個節點設定成資料伺服器。這樣就把查詢量分散了。所有資料並不在一臺伺服器上，QQ應該是分散式的因為理論上不需要彙總資料，除非需要高效的彙總查詢。
　　---------------------大寶(sodme)
　　很高興能看到大家積極討論,這兩天針對於這個問題,我也有了一些自己的初步想法,拿出來與大家共享.
　　前兩週,聽杭州研究院的同事介紹了海量資料儲存方面的東西,這個講座對我還是有點啟發的.其中,在介紹有關GFS(GOOGLE自己的檔案系統)的內容時,他闡述了這樣一個思想:高效能的應用系統,並不全是由高效能的硬體伺服器來支援的,甚至,他們有時更多的就是一些普通的伺服器,而再甚至,他們可能是目前已經不是市場主流的廢舊機器,我們就是要在這些廉價的硬體基礎上,通過我們的架構設計和軟體設計完成可觀的高效能應用,這才是我們所應該追求的目標, 也是符合絕大多數網路公司發展現狀的選擇,因為網路應用系統所承載的未來使用者數是不可預期的,它只會不斷增大.
　　如果有需要的朋友,我可以給你們發一份當時講座用到的GFS資料.在談到GFS的時候,我覺得對於我而言,收穫最大的就是chunk server
　　與 master server之間的分工,讓我很受啟發.簡單地說,chunk server才是負責作真正邏輯的地方,而master
　　server只是作了一箇中介者,傳遞了一個資訊而已,在具體的應用環境中,GFS client會向master
　　server詢問所要查詢的資料檔案在哪個chunk server上,然後GFS client就會與chunk server之間直接進行通訊.
　　說到QQ的架構,我想我們現在更多的是站在自己已有的知識架構上去想象和理解它,或者說,這個討論的主題是這樣更為合適些:"如果讓你作QQ的網路架構, 你會怎麼作?"不然,當我們在這時煞有介事地討論QQ架構的時候,騰訊的朋友看到了,可能會覺得我們討論的與他們實現的差別太大.所以,我想,我下面的發言內容,將會以這個主題來進行:如果讓我來作QQ的架構,我會怎麼作?
　　OK,現在我就把自己當作是一個QQ架構的設計者,我想象一下我會怎樣在廉價的硬體伺服器基礎上去搭建這樣的一個海量使用者的網路應用系統.
　　在討論問題時,我喜歡把問題細化.我們先看一下QQ在聊天(請注意:先只談聊天)方面具有哪些大致的功能.對於一個網路聊天程式而言,它會具有以下大致功能:
　　1.賬號管理(包括註冊,登入驗證等)
　　2.好友管理(包括好友的增,刪,黑名單的增,刪)
　　3.訊息通知(使用者上下線資訊的轉發,離線訊息轉發)
　　總體而言,我把QQ系統的設計難點歸納為兩個:一是應用伺服器如何部署,二是資料庫如何部署.下面,是我的設計思路.
　　我的基本設計思想是:把QQ號按分段的思想進行管理(比如每100萬是一個號段),每段是一個單獨的QQ管理叢集(暫且稱為QQ server
　　cluster),每個叢集之間通過分散式架構支援海量使用者線上.同時,會有一個全域性唯一的QQ master
　　server存放全域性索引資訊,這些資訊將主要包括:號段所對應的伺服器資訊及狀態. QQ
　　cluster的主要組成,將同時包括:應用伺服器(稱為QQ chat server)和資料庫伺服器(QQ db
　　server).我的可擴充套件架構設想是:當發現現有的使用者數已經接近飽和狀態時,只要增加一個相對獨立的cluster,並把這個新的cluster的相關資訊註冊到全域性唯一的QQ
　　master server上即可.
　　每一個QQ server cluster應該提供哪些基本服務:
　　1.對於客戶端,每個cluster是一個相對獨立的邏輯組,它承擔了使用者需要伺服器支援的大多數邏輯,比如:好友上下線訊息通知,離線訊息轉發等.
　　2.同時,對於其它的cluster,要向它們提供這樣的介面:好友線上狀態查詢,使用者詳細資訊查詢等.
　　3.為了實現P2P,還要打通兩個客戶端之間的UDP通訊通道.
　　4.當客戶端選擇採用TCP進行通訊時,還要負責訊息的轉發.
　　那麼,每一個cluster裡的db都存放了哪些資訊呢?
　　1.存放屬於本段使用者的詳細個人資料(包括除了必要的暱稱資訊等之外,還包括諸如:年齡,住址等的詳細資訊)
　　2.存放好友名單及黑名單(而在這兩個名單中,在本地的db上應該只包括必要的基本資訊:好友QQ號,好友暱稱等)
　　當客戶端登入時,客戶端首先只能獲得好友的簡單資訊,如果要想獲得詳細詳細,就需要向本號段的cluster查詢,如果cluster發現好友的號不在本號段內,它會向其它cluster查詢好友的詳細資訊(當然,這裡的查詢方法也是有多種方式的).
　　說到這裡,還有很重要的一點,QQ的登入又該如何來處理呢?
　　1.首先,我會設定若干個(假設n個)對外開放的登入域名(比如login01.qq.com~login08.qq.com),這些域名中的每一個是可以同時指向多個登入伺服器(稱為QQ
　　login server)IP的,這樣可以有效分擔連線負載;
　　2.當客戶端連線到login server之後,login server將對使用者進行賬號認證,成功後,會向客戶端傳送一個cluster
　　server的ip,將客戶端引導到cluster上去;
　　3.一旦客戶端連線到cluster上成功後,所有的邏輯就由cluster來控制了.
　　當然,這裡仍然還有很多細節問題要考慮,比如:對於這樣的分段管理,每個cluster中的QQ chat
　　server可能一個還不行,那這些chat server之間就要考慮還要加一個chat
　　master了.不過,這樣的話,分層是不是多了一點呢?還有待更進一層的細想,等我想清楚了詳細設計方案的時候,會以附件的形式配以圖表發上來,此文全當一個引子.
　　關於我的思路的優缺點:
　　優點是:
　　這樣的思路類似於現實生活中電話號碼的管理,它是分地區的,也就是分段的,我個人認為這樣以後的擴充套件相對來說可能簡單一點.
　　缺點是:
　　作為一個解決方案,這個思路並沒有充分考慮到根據當前使用者線上數來實現動態平衡的目標.比如說1~100萬內的線上人數很少,而100萬~200萬號內線上的人很多,那麼這兩個不同號段的伺服器負載就會完全不一樣,從而浪費了伺服器資源.
　　克服缺點的辦法:
　　如果要實現完全根據當前線上使用者數來實現伺服器負載的動態平衡,那就得將chat server與db server撥離, 讓chat
　　server這一層完全按動態均衡的思路來作,
　　而db這一塊的工作,可以抽象成一個數據管理層來作,但具體的使用者資料儲存仍然採用分段儲存的方式,為不同的號段作不同的資料庫儲存. 而chat
　　server這一層的思路, 基本上也是master + chunk的方式,客戶端最終仍然是與chat保持長連線.
　　-----------------top(木……)
　　一個必要考慮的問題是登陸時要以地域就近的原則,提供最快的網路響應,所以實際服務應用層應與資料層耦合的.分段式管理可以運用在資料儲存的分散式構架中,這是一個數據層的概念,即如何有效的組織分散式資料.因為QQ在實際操作中在即時通訊中需要查詢的資料量極少,寫入資料層的資訊量在所有通訊量中也佔很小的比重.所以考核負載可從服務應用層和資料層兩方面來考慮.服務應用層主要考慮使用者的時實性與伺服器負載平衡問題.資料層主要考慮如何提供更有效的分散式儲存方案.即採用黑盒的想法,我們在設計服務層時,可意想的認為我們象一個虛擬的資料伺服器提出資料請求必然會獲得響應.至於服務層如何實現認為是一個黑盒,無須考慮.接著我們只需考慮在服務層的各伺服器上如何儲存轉發暫存取得的資料以提高效率（減少向虛擬資料伺服器的查詢量,減少與客戶端的通訊量, 減少服務層各伺服器之間的通訊量為目的）
　　top(木……) 說:
　　其實我們只是說了一個大框架,其實在伺服器的配置功能的劃分服務層網路的構架上有很多細節問題.這些要針對實際運用需求而分別配置,所以,在設計之前最好先將需求梳理歸納.不過這個工程玩大了，呵呵
　　我(sodme)的觀點:
　　與top想法一樣, 資料層是個黑盒, 相對獨立. 至於其內部, 採用分段管理.

本文轉自

http://www.yaosansi.com/blog/article.asp?id=1132