1. 程式人生 > >負載均衡--大型線上系統實現的關鍵(下篇)(伺服器叢集架構的設計與選擇)

負載均衡--大型線上系統實現的關鍵(下篇)(伺服器叢集架構的設計與選擇)

本文作者:sodme
本文出處:http://blog.csdn.net/sodme
宣告:本文可以不經作者同意任意轉載,但任何對本文的引用都須註明作者、出處及此宣告資訊。謝謝!!

  在網路應用中,“負載均衡”已經不能算是什麼新鮮話題了,從硬體到軟體,也都有了很多的方法來實現負載均衡。我們這裡討論的負載均衡,並不是指依靠DNS轉向或其它硬體裝置等所作的負載均衡,而是指在應用層所作的負載均衡。

  一般而言,只有在大型線上系統當中才有必要引入負載均衡,那麼,多大的系統才能被稱為大型系統呢?比如動輒同時線上數十萬的網路遊戲,比如同時線上數在10萬以上的WEB應用,這些我們都可以理解為大型系統,這本身就是一個寬泛的概念。

  設計再好的伺服器程式,其單個程式所能承載的同時訪問量也是有限的,面對一個龐大且日益增長的網路使用者群,如何讓我們的架構能適應未來海量使用者訪問,這自然就牽涉到了負載均衡問題。支援百萬級以上的大型線上系統,它的架構核心就是如何將“百萬”這麼大的一個同時線上量分攤到每個單獨的伺服器程式上去。真正的邏輯處理應該是在這最終的底層的伺服器程式(如QQ遊戲平臺的遊戲房間伺服器)上的,而在此之前所存在的那些伺服器,都可以被稱為“引路者”,它們的作用就是將客戶端一步步引導到這最終的負責真正邏輯的底層伺服器上去,我們計算“百萬級線上”所需要的伺服器數量,也是首先考慮這底層的邏輯伺服器單個可承載的客戶端連線量。

  比如:按上篇我們所分析QQ遊戲架構而言,假設每個伺服器程式最高支援2W的使用者線上(假設一臺機子只執行一個伺服器程式),那麼實現150萬的線上量至少需要多少臺伺服器呢?如果算得簡單一點的話,就應該是:150/2=75臺。當然,這樣算起來,可能並不能代表真正的伺服器數量,因為除了這底層的伺服器外,還要包括登入/賬號伺服器以及大廳伺服器。但是,由於登入/賬號伺服器和大廳伺服器,它們與客戶端的連線都屬於短連線(即:取得所需要資訊後,客戶端與伺服器即斷開連線),所以,客戶端給這兩類伺服器帶來的壓力相比於長連線(即:客戶端與伺服器始終保持連線)而言就要輕得多,它們的壓力主要在處理瞬間的併發訪問上。

  “短連線”,是實現應用層負載均衡的基本手段!!!如果客戶端要始終與登入/賬號伺服器以及大廳伺服器保持連線,那麼這樣作的分層架構將是無意義的,這也沒有辦法從根本上解決使用者量不斷增長與伺服器數量有限之間的矛盾。

  當然,短連線之所以可以被使用並能維護正常的遊戲邏輯,是因為在玩家看不到的地方,伺服器與伺服器之間進行了大量的資料同步操作。如果一個玩家沒有登入到登入伺服器上去而是直接連線進了遊戲房間伺服器並試圖進行遊戲,那麼,由於遊戲房間伺服器與大廳伺服器和登入/賬號伺服器之間都會有針對於玩家登入的邏輯維護,遊戲房間伺服器會檢測出來該玩家之前並沒有到登入伺服器進行必要的賬號驗證工作,它便會將玩家踢下線。由此看來,各伺服器之間的資料同步,又是實現負載均衡的又一必要條件了。

  伺服器之間的資料同步問題,依據應用的不同,也會呈現不同的實現方案。比如,我們在處理玩家登入這個問題上。我們首先可以向玩家開放一些預設的登入伺服器(伺服器的IP及PORT資訊),當玩家連線到當前的登入伺服器後,由該伺服器首先判斷自己同時連線的玩家是不是超過了自定義的上限,如果是,由向與該伺服器連線著的“登入伺服器管理者”(一般是一個內部的伺服器,不直接向玩家開放)申請仲裁,由“登入伺服器管理者”根據當前各登入伺服器的負載情況選擇一個新的伺服器IP和PORT資訊傳給客戶端,客戶端收到這個IP和PORT資訊之後重定向連線到這個新的登入伺服器上去,完成後續的登入驗證過程。

  這種方案的一個特點是,在面向玩家的一側,會提供一個外部訪問介面,而在伺服器叢集的內部,會提供一個“伺服器管理者”及時記錄各登入伺服器的負載情況以便客戶端需要重定向時根據策略選擇一個新的登入介面給客戶端。

  採用分散式結構的好處是可以有效分攤整個系統的壓力,但是,不足點就是對於全域性資訊的索引將會變得比較困難,因為每個單獨的底層邏輯伺服器上都只是存放了自己這一個伺服器上的使用者資料,它沒有辦法查詢到其它伺服器上的使用者資料。解決這個問題,簡單一點的作法,就是在叢集內部,由一箇中介者,提供一個全域性的玩家列表。這個全域性列表,根據需要,可以直接放在“伺服器管理者”上,也可以存放在資料庫中。

  對於邏輯相對獨立的應用,全域性列表的使用機會其實並不多,最主要的作用就是用來檢測玩家是不是重複登入了。但如果有其它的某些應用,要使用這樣的全域性列表,就會使資料同步顯得比較複雜。比如,我們在超大無縫地圖的MMORPG裡,如果允許跨服操作(如跨服戰鬥、跨服交易等)的話,這時的資料同步將會變得異常複雜,也容易使處理邏輯出現不可預測性。

  我認為,對於休閒平臺而言,QQ遊戲的架構已經是比較合理的,也可以稱之為休閒平臺的標準架構了。那麼,MMORPG一般的架構是什麼樣的呢?

  MMORPG一般是把整個遊戲分成若干個遊戲世界組,每個組內其實就是一個單獨的遊戲世界。而不同的組之間,其資料皆是相互獨立的,並不象QQ休閒平臺一樣所有的使用者都會有一個集中的資料存放點,MMORPG的遊戲資料是按伺服器組的不同而各自存放的。玩家在登入QQ遊戲時,QQ遊戲相關的伺服器會自動為玩家的登入進行負載均衡,選擇相對不忙的伺服器為其執行使用者驗證並最終讓使用者選擇進入哪一個遊戲房間。但是,玩家在登入MMORPG時,卻沒有這樣的自動負載均衡,一般是由玩家人為地去選擇要進入哪一個伺服器組,之所以這樣,是因為各伺服器組之間的資料是不相通的。其實,細緻想來,MMORPG的伺服器架構思想與休閒平臺的架構思想有異曲同工之妙,MMORPG的思想是:可以為玩家無限地開獨立的遊戲世界(即伺服器組),以滿足大型玩家線上;而休閒平臺的思想則是:可以為玩家無限地開遊戲房間以滿足大量玩家線上。這兩種應用,可以無限開的都是“具有完整遊戲性的遊戲世界”,對於MMORPG而言,它的一個完整的遊戲地圖就是一個整體的“遊戲世界”,而對於休閒平臺,它的一個遊戲房間就可以描述為一個“遊戲世界”。如果MMORPG作成了休閒平臺那樣的全服皆通,也不是不可以,但隨之而來的,就是要解決眾多跨服問題,比如:好友、組隊、幫派等等的問題,所有在傳統MMORPG裡所定義的這些玩家組織形式的規則可能都會因為“全服皆通”而改變。

  架構的選擇是多樣性的,確實沒有一種可以稱得上是最好的所謂的架構,適合於當前專案的,不一定就適合於另一個專案。針對於特定的應用,會靈活選用不同的架構。但有一點,是可以說的:不管你如何架構,你所要作的就是--要以儘可能簡單的方案實現儘可能的穩定、高效!

  <全文完>