1。Erlang的保留字有：

after and andalso band begin bnot bor bsl bsr bxor case catch cond div end fun if let not of or orelse query receive rem try when xor

基本都是些用于邏輯運算、位運算以及特殊表達式的符號

2.Erlang的類型，除了在前面入門一提到的類型外，還包括：
1)Binary，用于表示某段未知類型的內存區域
比如：
1> <<10,20>>.
<<10,20>>
2> <<"ABC">>.
 <<65,66,67>>

2）Reference，通過調用mk_ref/0產生的運行時的unique term

3)String，字符串，Erlang中的字符串用雙引號包括起來，其實也是list。編譯時期，兩個鄰近的字符串將被連接起來，比如"string" "42" 等價于 "string42"

4)Record，記錄類型，與c語言中的struct類似，模塊可以通過-record屬性聲明，比如：
-module(person).
-export([new/2]).
-record(person, {name, age}).
new(Name, Age) ->
     #person{name=Name, age=Age}.
1> person:new(dennis, 44).
{person,dennis,44}
 在編譯后其實已經被轉化為tuple?？梢酝ㄟ^Name#person.name來訪問Name Record的name屬性。

3.模塊的預定義屬性：
-module(Module).    聲明模塊名稱，必須與文件名相同
-export(Functions).   指定向外界導出的函數列表
-import(Module,Functions).   引入函數，引入的函數可以被當作本地定義的函數使用
-compile(Options).     設置編譯選項，比如export_all
-vsn(Vsn).         模塊版本，設置了此項，可以通過beam_lib:version/1 獲取此項信息
可以通過-include和-include_lib來包含文件，兩者的區別是include-lib不能通過絕對路徑查找文件，而是在你當前Erlang的lib目錄進行查找。

4.try表達式，try表達式可以與catch結合使用，比如：

try Expr
catch
    throw:Term -> Term;
    exit:Reason -> {'EXIT',Reason}
    error:Reason -> {'EXIT',{Reason,erlang:get_stacktrace()}}
end

不僅如此，try還可以與after結合使用，類似java中的try..finally，用于進行清除作用，比如：
termize_file(Name) ->
{ok,F} = file:open(Name, [read,binary]),
try
{ok,Bin} = file:read(F, 1024*1024),
binary_to_term(Bin)
after
file:close(F)
end.


5.列表推斷（List Comprehensions），函數式語言特性之一，Erlang中的語法類似：
[Expr || Qualifier1,...,QualifierN]
Expr可以是任意的表達式，而Qualifier是generator或者filter。還是各舉例子說明下。
1>  [X*2 || X <- [1,2,3]].
[2,4,6]

2> L=[1,2,3,4,5,6,7].
[1,2,3,4,5,6,7]


3> [X|X<-L,X>=3].
[3,4,5,6,7]


再看幾個比較酷的例子，來自Programming Erlang，
比如快速排序：
-module(qsort).
-export([qsort/1]).
qsort([])->[];
qsort([Pivot|T])->
  qsort([X||X<-T,X




6.宏，定義常量或者函數等等，語法如下：

-define(Const, Replacement).

-define(Func(Var1,...,VarN), Replacement).



使用的時候在宏名前加個問號？，比如?Const，Replacement將插入宏出現的位置。系統預定義了一些宏:

?MODULE   表示當前模塊名



?MODULE_STRING 同上，但是以字符串形式

?FILE    當前模塊的文件名

?LINE    調用的當前代碼行數

?MACHINE  機器名



Erlang的宏與C語言的宏很相似，同樣有宏指示符，包括：

-undef(Macro). 
取消宏定義

-ifdef(Macro). 
當宏Macro有定義的時候，執行以下代碼

-ifndef(Macro). 
同上，反之

-else. 
接在ifdef或者ifndef之后，表示不滿足前者條件時執行以下代碼



-endif. 
if終止符
假設宏-define(Square(X),X*X).用于計算平方，那么??X將返回X表達式的字符串形式，類似C語言中#arg



一個簡單的宏例子：

ruby 代碼

 

    
-module(macros_demo).  
    
-ifdef(debug).  
    
-define(LOG(X), io:format("{~p,~p}: ~p~n", [?MODULE,?LINE,X])).  
    
-else.  
    
-define(LOG(X), true).  
    
-endif.  
    
-define(Square(X),X*X).  
    
-compile(export_all).  
    
test()->  
    
    A=3,  
    
    ?LOG(A),  
    
    B=?Square(A),  
    
    io:format("square(~w) is ~w~n",[A,B]).   




當編譯時不開啟debug選項的時候：

17> c(macros_demo).

{ok,macros_demo}

18> macros_demo:test().

square(3) is 9



當編譯時開啟debug之后：



19> c(macros_demo,{d,debug}).

{ok,macros_demo}

20> macros_demo:test().

{macros_demo,11}: 3

square(3) is 9

ok



可以看到LOG的輸出了，行數、模塊名以及參數



7、Process Dictionary，每個進程都有自己的process dictionary，用于存儲這個進程內的全局變量，可以通過下列

BIFs操作：

put(Key, Value)

get(Key)

get()

get_keys(Value)

erase(Key)

erase()



8、關于分布式編程，需要補充的幾點

1）節點之間的連接默認是transitive，也就是當節點A連接了節點B，節點B連接了節點C，那么節點A也與節點C互相連接

可以通過啟動節點時指定參數-connect_all false來取消默認行為



2）隱藏節點，某些情況下，你希望連接一個節點而不去連接其他節點，你可以通過在節點啟動時指定-hidden選項

來啟動一個hidden node。在此情況下，通過nodes()查看所有連接的節點將不會出現隱藏的節點，想看到隱藏的節點

可以通過nodes(hidden)或者nodes(connected)來查看。



完整的erl選項如下：




    

        

            
-connect_all false 
            
上面已經解釋。 
        
        

            
-hidden 
            
啟動一個hidden node

        
        

            
-name Name 
            
啟動一個系統成為節點，使用long name. 
        
        

            
-setcookie Cookie 
            
與Erlang:set_cookie(node(), Cookie).相同，設置magic cookie

        
        

            
-sname Name 
            
啟動一個Erlang系統作為節點，使用short name 

        
    





注意,short name啟動的節點是無法與long name節點通信的。



.一個小細節，在Erlang中小于等于是用=<表示，而不是一般語言中的<=語法，我犯過錯誤的地方，同樣，不等于都是用/號，而不是
!,比如/=、=/=。

10.and or 和andalso orelse的區別

and和or會計算兩邊的表達式，而andalso和orelse的求值采用短路機制，比如exp1 andalso exp2，當exp1返回false之后，就不會去求值
exp2，而是直接返回false，而exp1 and exp2會對exp1和exp2都進行求值，or與orelse也類似。

  任何一門語言都有自己的錯誤處理機制，Erlang也不例外，語法錯誤編譯器可以幫你指出，而邏輯錯誤和運行時錯誤就只有靠程序員利用Erlang提供的機制來妥善處理，放置程序的崩潰。
    Erlang的機制有：
1)監控某個表達式的執行
2）監控其他進程的行為
3）捕捉未定義函數執行錯誤等

一、catch和throw語句
    調用某個會產生錯誤的表達式會導致調用進程的非正常退出，比如錯誤的模式匹配（2=3），這種情況下可以用catch語句：
                                      catch expression
    試看一個例子，一個函數foo：


當沒有使用catch的時候，假設有一個標識符為Pid的進程調用函數foo（在一個模塊中），那么：
foo(1) - 返回hello
foo(2) - 語句throw({myerror, abc})執行，因為我們沒有在一個catch中調用foo(2),因此進程Pid將因為錯誤而終止。

foo(3) - tuple_to_list將一個元組轉化為列表，因為a不是元組，因此進程Pid同樣因為錯誤而終止

foo(4) - 因為沒有使用catch，因此foo(4)調用了exit函數將使進程Pid終止，{myExit, 222} 參數用于說明退出的原因。

foo(5) - 進程Pid將因為foo(5)的調用而終止，因為沒有和foo(5)匹配的函數foo/1。

    讓我們看看用catch之后是什么樣：

再看看結果，
demo(1) - 沒有錯誤發生，因此catch語句將返回表達式結果hello
demo(2) - foo(2)拋出錯誤{myerror, abc}，被catch返回，因此將返回{user_error,abc}

demo(3) - foo(3)執行失敗，因為參數錯誤，因此catch返回{'EXIT',badarg'},最后返回{caught_error,badarg}

demo(4) - 返回{caught_error,{myexit,222}}
demo(5) - 返回{caught_error,function_clause}

    使用catch和throw可以將可能產生錯誤的代碼包裝起來，throw可以用于尾遞歸的退出等等。Erlang是和scheme一樣進行尾遞歸優化的，它們都沒有顯式的迭代結構（比如for循環）

二、進程的終止
    在進程中調用exit的BIFs就可以顯式地終止進程，exit(normal)表示正常終止，exit(Reason)通過Reason給出非正常終止的原因。進程的終止也完全有可能是因為運行時錯誤引起的。

三、連接的進程
    進程之間的連接是雙向的，也就是說進程A打開一個連接到B,也意味著有一個從B到A的連接。當進程終止的時候，有一個EXIT信號將發給所有與它連接的進程。信號的格式如下：
               {'EXIT', Exiting_Process_Id, Reason}
Exiting_Process_Id 是指終止的進程標記符
Reason 是進程終止的原因。如果Reason是normal，接受這個信號的進程的默認行為是忽略這個信號。默認對Exit信號的處理可以被重寫，以允許進程對Exit信號的接受做出不同的反應。
1.連接進程：
通過link(Pid)，就可以在調用進程與進程Pid之間建立連接
2.取消連接
反之通過unlink(Pid)取消連接。
3.創立進程并連接：
通過spawn_link(Module, Function, ArgumentList)創建進程并連接，該方法返回新創建的進程Pid

    通過進程的相互連接，許多的進程可以組織成一個網狀結構，EXIT信號（非normal)從某個進程發出（該進程終止），所有與它相連的進程以及與這些進 程相連的其他進程，都將收到這個信號并終止，除非它們實現了自定義的EXIT信號處理方法。一個進程鏈狀結構的例子：

執行：

四、運行時失敗
    一個運行時錯誤將導致進程的非正常終止，伴隨著非正常終止EXIT信號將發出給所有連接的進程，EXIT信號中有Reason并且Reason中包含一個atom類型用于說明錯誤的原因，常見的原因如下：

badmatch - 匹配失敗，比如一個進程進行1=3的匹配，這個進程將終止，并發出{'EXIT', From, badmatch}信號給連接的進程

badarg  - 顧名思義，參數錯誤，比如atom_to_list(123),數字不是atom，因此將發出{'EXIT', From, badarg}信號給連接進程

case_clause - 缺少分支匹配，比如
   

沒有分支3，因此將發出{'EXIT', From, case_clause}給連接進程

if_clause - 同理，if語句缺少匹配分支

function_clause - 缺少匹配的函數，比如：

如果我們調用foo(3)，因為沒有匹配的函數，將發出{'EXIT', From, function_clause} 給連接的進程。

undef - 進程執行一個不存在的函數

badarith - 非法的算術運算，比如1+foo。

timeout_value - 非法的超時時間設置，必須是整數或者infinity

nocatch - 使用了throw，沒有相應的catch去通訊。

五、修改默認的信號接收action
   當進程接收到EXIT信號，你可以通過process_flag/2方法來修改默認的接收行為。執行process_flag(trap_exit, true)設置捕獲EXIT信號為真來改變默認行為，也就是將EXIT信號作為一般的進程間通信的信號進行接受并處理；process_flag (trap_exit,false)將重新開啟默認行為。
   例子：

    創建的進程執行demo方法，demo方法中設置了trap_exit為true,因此，在receive中可以像對待一般的信息一樣處理EXIT信號，這個程序是很簡單了，測試看看：

六、未定義函數和未注冊名字
1.當調用一個未定義的函數時，Mod:Func(Arg0,...,ArgN)，這個調用將被轉為：
error_handler:undefined_function(Mod, Func, [Arg0,...,ArgN])
其中的error_handler模塊是系統自帶的錯誤處理模塊

2.當給一個未注冊的進程名發送消息時，調用將被轉為：
error_handler:unregistered_name(Name,Pid,Message)

3.如果不使用系統自帶的error_handler，可以通過process_flag(error_handler, MyMod) 設置自己的錯誤處理模塊。

七、Catch Vs. Trapping Exits
這兩者的區別在于應用場景不同，Trapping Exits應用于當接收到其他進程發送的EXIT信號時，而catch僅用于表達式的執行。

第8章介紹了如何利用錯誤處理機制去構造一個健壯的系統，用了幾個例子，我將8.2節的例子完整寫了下，并添加客戶端進程用于測試：

回家了，有空再詳細說明下這個例子吧。執行：

    所謂分布式的Erlang應用是運行在一系列Erlang節點組成的網絡之上。這樣的系統的性質與單一節點上的Erlang系統并沒有什么不同。分布式這是個“大詞”，Erlang從語言原生角度支持分布式編程，相比于java簡單不少。
一、分布式機制
下列的BIFs是用于分布式編程：
spawn(Node, Mod, Func, Args)
啟動遠程節點的一個進程

spawn_link(Node, Mod, Func, Args)
啟動遠程節點的一個進程并創建連接到該進程

monitor_node(Node, Flag)
如果Flag是true,這個函數將使調用（該函數）的進程可以監控節點Node。如果節點已經舍棄或者并不存在，調用的進程將收到一個{nodedown,Node}的消息。如果Flag是false,監控將被關閉

node()
返回我們自己的進程name

nodes()
返回其他已知的節點name列表

node(Item)
返回原來Item的節點名稱，Item可以是Pid,引用（reference）或者端口(port)

disconnect_node(Nodename)
從節點Nodename斷開。

    節點是分布式Erlang的核心概念。在一個分布式Erlang應用中，術語（term)節點(node）意味著一個可以加入分布式 transactions的運行系統。通過一個稱為net kernal的特殊進程，一個獨立的Erlang系統可以成為一個分布式Erlang系統的一部分。當net kernal進程啟動的時候，我們稱系統是alive的。

    與遠程節點上的進程進行通信，與同一節點內的進程通信只有一點不同：
  
顯然，需要接收方增加一個參數Node用于指定接受進程所在的節點。節點的name一般是用@隔開的atom類型，比如pong@dennis，表示計算機名為dennis上的pong節點。通過執行:

將在執行的計算機中創建一個節點pong。為了運行下面的例子，你可能需要兩臺計算機，如果只有一臺，只要同時開兩個Erlang系統并以不同的節點名稱運行也可以。

二、一些例子。
    這個例子完全來自上面提到的翻譯的連接，關于分布式編程的章節。我增加了截圖和說明。
首先是代碼：

    代碼是創建兩個相互通信的進程，相互發送消息并通過io顯示在屏幕上，本來是一個單一系統的例子，現在我們讓兩個進程運行在不同的兩個節點上。注意 start_ping方法，創建的進程調用ping方法，ping方法有兩個參數，一個是發送消息的次數，一個就是遠程節點的name了，也就是我們將要 創建的進程pong的所在節點。start_pong創建一個調用函數pong的進程，并注冊為名字pong（因此在ping方法中可以直接發送消息給 pong)。
    我是在windows機器上測試，首先打開兩個cmd窗口，并cd到Erlang的安裝目錄下的bin目錄，比如C:\Program Files\erl5.5.3\bin,將上面的程序存為tut17.erl，并拷貝到同一個目錄下。我們將創建兩個節點，一個叫 ping@dennis,一個叫pong@dennis,其中dennis是我的機器名。見下圖：

采用同樣的命令

erl -sname ping

創建ping節點。然后在pong節點下執行start_pong()：


OK,這樣就在節點pong上啟動了pong進程，然后在ping節點調用start_ping，傳入參數就是pong@dennis

執行結果如下圖：

同樣在pong節點上也可以看到：


    結果如我們預期的那樣，不同節點上的兩個進程相互通信如此簡單。我們給模塊tut17增加一個方法，用于啟動遠程進程，也就是調用spawn(Node,Module,Func,Args)方法：

pong進程啟動Ping_Node節點上的進程ping。具體結果不再給出。

   讀erlang.org上面的Erlang Course四天教程
1.數字類型，需要注意兩點
1）B#Val表示以B進制存儲的數字Val，比如

二進制存儲的101就是10進制的5了
2）$Char表示字符Char的ascii編碼，比如$A表示65

2.比較難以翻譯的概念——atom，可以理解成常量，它可以包含任何字符，以小寫字母開頭，如果不是以小寫字母開頭或者是字母之外的符號，需要用單引號包括起來，比如abc,'AB'

3.另一個概念——Tuple,有人翻譯成元組，可以理解成定長數組，是Erlang的基礎數據結構之一：

內置函數size求長度，元組可以嵌套元組或者其他結構。下面所講的列表也一樣。

4.另外一個基礎數據結構就是各個語言都有的list（列表），在[]內以,隔開，可以動態改變大小，

可以使用內置函數length求列表大小。以""包含的ascii字母代表一個列表，里面的元素就是這些字母的ascii值，比如"abc"表示列表[97,98,99]。

5.通過這兩個數據結構可以組合成各種復雜結構，與Lisp的cons、list演化出各種結構一樣的奇妙。

6.Erlang中變量有兩個特點：
1）變量必須以大寫字母開頭
2）變量只能綁定一次，或者以一般的說法就是只能賦值一次，其實Erlang并沒有賦值這樣的概念,=號也是用于驗證匹配。

7.模式匹配——Pattern Matching，Erlang的模式匹配非常強大，看了buaawhl的《Erlang語法提要》的介紹，模式匹配的功能不僅僅在課程中介紹的數據結構的拆解，在程序的分派也扮演重要角色，或者說Erlang的控制的流轉是通過模式匹配來實現的。具體功能參見鏈接，給出書中拆解列表的例子：

 
下面會給出更多模式匹配的例子，給出一個模塊用來計算列表等

8.Erlang中函數的定義必須在一個模塊內（Module），并且模塊和函數的名稱都必須是atom，函數的參數可以是任何的Erlang類型或者數據結構，函數要被調用需要從模塊中導出，函數調用的形式類似：
moduleName:funcName(Arg1,Arg2,...).
寫我們的第一個Erlang程序，人見人愛的Hello World：

存為helloWorld.erl，在Erlang Shell中執行：

打印出來了，現在解釋下程序構造，

這一行聲明了模塊helloWorld，函數必須定義在模塊內，并且模塊名稱必須與源文件名相同。

而這一行聲明導出的函數，run/1指的是有一個參數的run函數，因為Erlang允許定義同名的有不同參數的多個函數，通過指定/1來說明要導出的是哪個函數。
接下來就是函數定義了：

大寫開頭的是變量Name，調用io模塊的format方法輸出，~w可以理解成占位符，將被實際Name取代，~n就是換行了。注意，函數定義完了要以句號.結束。然后執行c(helloWorld).編譯源代碼，執行：

9.內置的常用函數：

10.常見Shell命令：
1）h(). 用來打印最近的20條歷史命令
2）b(). 查看所有綁定的變量
3) f(). 取消（遺忘）所有綁定的變量。
4) f(Val).  取消指定的綁定變量
5) e(n).   執行第n條歷史命令
6) e(-1).  執行上一條shell命令

11.又一個不知道怎么翻譯的概念——Guard。翻譯成約束？呵呵。用于限制變量的類型和范圍，比如：

為了方便比較，Erlang規定如下的比較順序：

12.忘了介紹apply函數，這個函數對于熟悉javascript的人來說很親切，javascript實現mixin就得靠它，它的調用方式如下：

apply(Mod, Func, Args),三個參數分別是模塊、函數以及參數列表，比如調用我們的第一個Erlang程序：

java 代碼


    
apply(helloWorld,run,[dennis]).  



13.if和case語句，if語句的結構如下：

java 代碼

 

    
if  
    
   Guard1 ->  
    
        Sequence1 ;  
    
   Guard2 ->  
    
        Sequence2 ;  
    
...  
    
end  



而case語句的結構如下：

java 代碼

 

    
case Expr of  
    
   Pattern1 [when Guard1] -> Seq1;  
    
   Pattern2 [when Guard2] -> Seq2;  
    
  
    
   PatternN [when GuardN] -> SeqN  
    
end  

if和case語句都有一個問題，就是當沒有模式匹配或者Grard都是false的時候會導致error，這個問題case可以增加一個類似java中default的：

通過_指代任意的Expr，返回true,而if可以這樣：

一樣的道理。case語句另一個需要注意的問題就是變量范圍，每個case分支中定義的變量都將默認導出case語句，也就是在case語句結束后可以被引用，因此一個規則就是每個case分支定義的變量應該一致，不然算是非法的，編譯器會給出警告，比如：

如果執行true分支，變量A和變量B都被定義，而如果執行的false分支，只有變量B被引用，可在case語句執行后，h(A)調用了變量A，這是不安全的，因為變量A完全可能沒有被定義，編譯器將給出警告
variable 'A' unsafe in 'case' (line 10)



14.給出一些稍微復雜的模型匹配例子，比如用于計算數字列表的和、平均值、長度、查找某元素是否在列表中，我們把這個模塊定義為list:

細細體會，利用遞歸來實現，比較有趣。_用于指代任意的變量，當我們只關注此處有變量，但并不關心變量的值的時候使用。用分號;來說明是同一個函數定義，只是不同的定義分支，通過模式匹配來決定調用哪個函數定義分支。
另一個例子，計算各種圖形的面積，也是課程中給出的例子：

執行一下看看：

Erlang使用%開始單行注釋。

看到這篇文章的時候，我覺得很驚訝，雖然我對這方面的了解并不多，但在自己的想像中，還是對網游這些東西稍有一點想法，因為曾經有朋友做過簡單的外掛，比如，抓包發包然后嘗試模擬包，來使網游達到你想實現的效果。
外掛這東西，在2003年左右應該是一個巔峰吧，那時候，奇跡外掛、傳奇外掛，確實讓一部分人先富起來，可是后來的零點行動，這些人都永遠的消失在外掛長河中。
那時候我就在想，外掛是什么原理，為什么我這邊的動作，可以讓服務端產生那樣的效果？其實，這就是一個同步的問題，我個人理解是服務器上有個觸發器，這邊發包后，然后那邊判斷包是否正常，然后就會有一個相應的動作。當然，動作程序還是在本機上，地圖也在本機上，發出去的包，只是告訴服務器我是這樣在動作的。于是就出現了瞬移，卡點這種情況，因為發出去的包，和坐標位置在服務器上都是正常的。（以上是我的猜測）

下面是文章：
不知道大家是否碰到過這種情況，當某個玩家發出一個火球，這個火球有自己的運動軌跡，那么如何來判斷火球是否打中了人呢？大部分情況，當策劃提出這個要求的時候，一般會被程序否認，原因是：太麻煩了，呵呵。復雜點的還有包括兩個火球相撞之類的事情發生。

那么網絡游戲中，是否真的無法模擬實現這種模擬呢？

首先我們來看看模擬此種操作會帶來什么樣的麻煩：

1，服務器必須trace火球的運行軌跡，乍一想，挺慢的。

2，網絡延遲，傳過來有延遲，傳過去有延遲，延遲還不穩定，麻煩。

3，都有兩點解決不了了，接下來不愿意再想了。

呵呵，實際上呢，對火球的模擬比對人物運動的模擬要輕松很多，原因很簡單，火球的方向不會變。下面來看看具體用什么樣的結構來實現：

不知道大家是否還記得我去年這個時候提到過的Dead Reckoning算法，我們要模擬火球運動的關鍵就在于一個叫Moving Objects Tracing Server的服務器程序，這個服務器是干什么的呢。這個服務器接收主游戲服務器發過來的注冊事件的信息，比如有個玩家，開始移動了，那么主游戲服務器就 把該玩家的運動PDU，包括方向，速度，加速度，起點發給MOTS (Moving Objects Tracing Server)，然后MOTS自己開始對其運行進行模擬，當游戲服務器發來第二個PDU包的時候，則對各個物件的位置進行修正，并重新開始模擬。那么，我 們模擬的目的是什么呢？當然是發生某些事件，比如說碰撞，或者掉入地圖的某個陷阱的時候，會將該事件回發給主邏輯服務器。然后邏輯服務器來處理該事件。

那么，對于火球的處理，也和處理其他玩家的同步一樣，當接收到玩家的發火球的指令以后，產生一個火球，并指定其PDU信息，在MOTS上注冊該個運 動物 體。當MOTS自行模擬到這個物體和其他玩家或者NPC物體產生碰撞，則通知主邏輯服務器，然后主邏輯服務器產生相應的動作。

那么關于延遲呢？有些人也許會說，比如說前面有個火球，我本地操縱的小人其實躲過去了，但是因為網絡延遲，在服務器上我并沒有躲過去，那么怎么算？ 呵呵， 不知道大家玩過星際沒有，有沒有發現在星際中玩多人連線模式的時候，有一點最特別的地方，就是控制一個小兵的時候，點了地圖上的某個位置，但是小兵并不會 馬上開始移動，而是有一定的延遲，但是這一小點延遲并不能掩蓋星際的經典，同樣的理論用到這里也成立。對于客戶端的控制，當玩家操縱的主角改變PDU信息 的時候，確保信息發送到服務器之后，再開始處理本地的操作指令，這樣就能保證本地的預測和服務器的預測幾乎是沒有什么誤差的，即使有很小的誤差產生，以服 務器為主，這樣玩家也不會有太大的抱怨。

————————————————————————————————————————-

網絡游戲同步詳解之一

同步在網絡游戲中是非常重要的，它保證了每個玩家在屏幕上看到的東西大體是一樣的。其實呢，解決同步問題的最簡單的方法就是把每個玩家的動作都向其 他玩家廣播一遍，這里其實就存在兩個問題：1，向哪些玩家廣播，廣播哪些消息。2，如果網絡延遲怎么辦。事實上呢，第一個問題是個非常簡單的問題，不過之 所以我提出這個問題來，是提醒大家在設計自己的消息結構的時候，需要把這個因素考慮進去。而對于第二個問題，則是一個挺麻煩的問題，大家可以來看這么個例 子：
比如有一個玩家A向服務器發了條指令，說我現在在P1點，要去P2點。指令發出的時間是T0，服務器收到指令的時間是T1，然后向周圍的玩家廣播這條 消息，消息的內容是“玩家A從P1到P2”有一個在A附近的玩家B，收到服務器的這則廣播的消息的時間是T2，然后開始在客戶端上畫圖，A從P1到P2 點。這個時候就存在一個不同步的問題，玩家A和玩家B的屏幕上顯示的畫面相差了T2-T1的時間。這個時候怎么辦呢？

有個解決方案，我給它取名叫預測拉扯，雖然有些怪異了點，不過基本上大家也能從字面上來理解它的意思。要解決這個問題，首先要定義一個值叫：預 測誤差。然后需要在服務器端每個玩家連接的類里面加一項屬性，叫TimeModified，然后在玩家登陸的時候，對客戶端的時間和服務器的時間進行比 較，得出來的差值保存在TimeModified里面。還是上面的那個例子，服務器廣播消息的時候，就根據要廣播對象的TimeModified，計算出 一個客戶端的CurrentTime，然后在消息頭里面包含這個CurrentTime，然后再進行廣播。并且同時在玩家A的客戶端本地建立一個隊列，保 存該條消息，只到獲得服務器驗證就從未被驗證的消息隊列里面將該消息刪除，如果驗證失敗，則會被拉扯回P1點。然后當玩家B收到了服務器發過來的消息“玩 家A從P1到P2”這個時候就檢查消息里面服務器發出的時間和本地時間做比較，如果大于定義的預測誤差，就算出在T2這個時間，玩家A的屏幕上走到的地點 P3，然后把玩家B屏幕上的玩家A直接拉扯到P3，再繼續走下去，這樣就能保證同步。更進一步，為了保證客戶端運行起來更加smooth，我并不推薦直接 把玩家拉扯過去，而是算出P3偏后的一點P4，然后用(P4-P1)/T(P4-P3)來算出一個很快的速度S，然后讓玩家A用速度S快速移動到P4，這 樣的處理方法是比較合理的，這種解決方案的原形在國際上被稱為（Full plesiochronous），當然，該原形被我篡改了很多來適應網絡游戲的同步，所以而變成所謂的：預測拉扯。

另外一個解決方案，我給它取名叫驗證同步，聽名字也知道，大體的意思就是每條指令在經過 服務器驗證通過了以后再執行動作。具體的思路如下：首先 也需要在每個玩家連接類型里面定義一個 TimeModified，然后在客戶端響應玩家鼠標行走的同時，客戶端并不會先行走動，而是發一條走路的指令給服務器，然后等待服務器的驗證。服務器接 受到這條消息以后，進行邏輯層的驗證，然后計算出需要廣播的范圍，包括玩家A在內，根據各個客戶端不同的TimeModified生成不同的消息頭，開始 廣播，這個時候這個玩家的走路信息就是完全同步的了。這個方法的優點是能保證各個客戶端之間絕對的同步，缺點是當網絡延遲比較大的時候，玩家的客戶端的行 為會變得比較不流暢，給玩家帶來很不爽的感覺。該種解決方案的原形在國際上被稱為（Hierarchical master-slave synchronization），80年代以后被廣泛應用于網絡的各個領域。

最后一種解決方案是一種理想化的解決方案，在國際上被稱為Mutual synchronization，是一種對未來網絡的前景的良好預測出來的解決方案。這里之所以要提這個方案，并不是說我們已經完全的實現了這種方案，而 只是在網絡游戲領域的某些方面應用到這種方案的某些思想。我對該種方案取名為：半服務器同步。大體的設計思路如下：

首先客戶端需要在登陸世界的時候建立很多張廣播列表，這些列表在客戶端后臺和服務器要進行不及時同步，之所以要建立多張列表，是因為要廣播的類 型是不止一種的，比如說有local message,有remote message,還有global message 等等，這些列表都需要在客戶端登陸的時候根據服務器發過來的消息建立好。在建立列表的同時，還需要獲得每個列表中廣播對象的TimeModified，并 且要維護一張完整的用戶狀態列表在后臺，也是不及時的和服務器進行同步，根據本地的用戶狀態表，可以做到一部分決策由客戶端自己來決定，當客戶端發送這部 分決策的時候，則直接將最終決策發送到各個廣播列表里面的客戶端，并對其時間進行校對，保證每個客戶端在收到的消息的時間是和根據本地時間進行校對過的。 那么再采用預測拉扯中提到過的計算提前量，提高速度行走過去的方法，將會使同步變得非常的smooth。該方案的優點是不通過服務器，客戶端自己之間進行 同步，大大的降低了由于網絡延遲而帶來的誤差，并且由于大部分決策都可以由客戶端來做，也大大的降低了服務器的資源。由此帶來的弊端就是由于消息和決策權 都放在客戶端本地，所以給外掛提供了很大的可乘之機。

綜合以上三種關于網絡同步派系的優缺點，綜合出一套關于網絡游戲傳輸同步的較完整的解決方案，我稱它為綜合同步法（colligate synchronization）。大體設計思路如下：

首先將服務器需要同步的所有消息從劃分一個優先等級，然后按照3/4的比例劃分出重要消息和非重要消息，對于非重要消息，把決策權放在客戶端，在客戶端邏輯上建立相關的決策機構和各種消息緩存區，以及相關的消息緩存區管理機構，如下圖所示：

上圖簡單說明了對于非重要消息，客戶端的大體處理流程，其中有一個客戶端被動行為值得大家注意，其中包括對服務器發過來的某些驗證代碼做返回， 來確保消息緩存中的消息和服務器端是一致的，從而有效的防止外掛來篡改本地消息緩存。其中的消息來源是包括本地的客戶端響應玩家的消息以及遠程服務器傳遞 過來的消息。

對于重要消息，比如說戰斗或者是某些牽扯到玩家一些比較敏感數據的操作，則采用另外一套方案，該方案首先需要在服務器和客戶端之間建立一套 Ping System，然后服務器保存和用戶的及時的ping值，當ping比較小的時候，響應玩家消息的同時先不進行動作，而是先把該消息反饋給服務器，并且阻 塞，服務器收到該消息，進行邏輯驗證之后向所有該詳細廣播的有效對象進行廣播（包括消息發起者），然后客戶端收到該消息的驗證，才開始執行動作。而當 ping比較大的時候，客戶端響應玩家消息的同時立刻進行動作，并且同時把該消息反饋給服務器，值得注意的是這個時候還需要在本地建立一個無驗證消息的隊 列，把該消息入隊，執行動作的同時等待服務器的驗證，還需要保存當前狀態。服務器收到客戶端的請求后，進行邏輯驗證，并把消息反饋到各個客戶端，帶上各個 客戶端校對過的本地時間。如果驗證通過不過，則通知消息發起者，該消息驗證失敗，然后客戶端自動把已經在進行中的動作取消，恢復原來狀態。如果驗證通過， 則廣播到的各個客戶端根據從服務器獲得校對時間進行對其進行拉扯，保證在該行為完成之前完成同步。

至此，一個比較成熟的網絡游戲的同步機制已經初步建立起來了，接下來的邏輯代碼就根據各自不同的游戲風格以及側重點來寫了。

同步是網絡游戲最重要的問題，如何同步也牽扯到各個方面的問題，比如說游戲的規模，游戲的類型以及各種各樣的方面，對于規模比較大的游戲，在同 步方面可以下很多的工夫，把消息分得十分的細膩，對于不同的消息采用不同的同步機制，而對于規模比較小的游戲，則可以采用大體上一樣的同步機制，究竟怎么 樣同步，沒有個定式，是需要根據自己的不同情況來做出不同的同步決策的網游同步算法之導航推測（Dead Reckoning）算法：

——————————————————————————————————————————

網絡游戲同步詳解之二

在了解該算法前，我們先來談談該算法的一些背景資料。大家都知道，在網絡傳輸的時候，延遲現象是很普遍的，而在基于Server/Client結構 下的網絡游戲的同步也就成了很頭疼的問題，在保證客戶端響應用戶本地指令流暢的情況下，沒法有效的保證的同步的及時性。同樣，在軍方也有類似的事情發生， 即使是同一LAN里面的機器，也會因為傳輸的延遲，導致一些運算的失誤，介于此，美國國防部投入了大量的資金用于研究一種比較的好的方案來解決分布式系統 中的延遲問題，特別是一個叫分布式模擬運動（Distributed Interactive Simulation）的系統，這套系統呢，其中就提出了一套號稱是Latency Hiding & Bandwidth Reduction的方案，命名為Dead Reckoning。呵呵，來頭很大吧，恩，那么我們下面就來看看這套系統的一些觀點，以及我們如何把它運用到我們的網絡游戲的同步中。

首先，這套同步方案是基于我那篇《網絡游戲的同步》一文中的Mutual Synchronization同步方案的，也就是說，它并不是Server/Client結構的，而是基于客戶端之間的同步的。下面我們先來說一些本文中將用到的名詞概念：
網狀網絡：客戶端之間構成的網絡
節點：網狀網絡中的每個客戶端
極限誤差：進行同步的時候可能產生的誤差的極值

恩，在探討其原理的之前，我們先來看看我們需要一個什么樣的環境。首先，需要一個網狀網絡，網狀網絡如何構成呢？當有新節點進入的時候，通知該 網絡里面的所有節點，各節點為該客戶端在本地創建一個副本，登出的時候，則通知所有節點銷毀本地關于該節點的副本。然后每個節點該保存一些什么數據呢？首 先有一個很重要的包需要保存，叫做協議數據包（PDU Protocol Data Unit），PDU包含節點的一些相關的運動信息，比如當前位置，速度，運動方向，或者還有加速度等一些信息。除PDU之外，還有其他信息需要保存，比如 說節點客戶端人物的HP，MP之類的。然后，保證每個節點在最少8秒之內要向其它節點廣播一次PDU信息。最后，設置一個極限誤差值。到此，其環境就算搭 建完成了。下面，我們就來看看相關的具體算法：

假設在節點A有一個小人（路人甲），開始跑路了，這個時候，就像所有的節點廣播一次他的PDU信息，包括：速度（S），方向（O），加速度 （A）。那么所有的節點就開始模擬路人甲的運動軌跡和路線，包括節點A本身（這點很重要），同時，路人甲在某某玩家的控制下，會不時的改變一下方向，讓其 跑路的路線變得不是那么正規。在跑路的過程中，節點A有一個值在不停的記錄著其真實坐標和在后臺模擬運動的坐標的差值，當差值大于極限誤差的時候，則計算 出當前的速度S，方向O和速度A（算法將在后面介紹），并廣播給網絡中其他所有節點。其他節點在收到這條消息之后呢，就可以用一些很平滑的移動把路人甲拉 扯過去，然后重新調整模擬跑路的數據，讓其繼續在后臺模擬跑路。

很顯然，如果極限誤差定義得大了，其他節點看到的偏差就會過大，如果極限偏差定義得小了，網絡帶寬就會增大。如果定義這個極限誤差，就該根據各 種數據的重要性來設計了。如果是回合制的網絡游戲，那么在走路上把極限誤差定義得大些無所謂，可以減少帶寬。但是如果是及時打斗的網絡游戲，那么就得把極 限誤差定義得小一些，否則會出現某人看到某人老遠把自己給砍死的情況。

Dead Reckoning的主要算法有9種，但是只有兩種是解決主要問題的，其他的基本上只是針對不同的坐標系的一些不同的算法，這里就不一一介紹了。好，那么我們下面來看傳說中的最主要的兩種算法：
第一：目標點 = 原點 + 速度 * 時間差
第二：目標點 = 原點 + 速度 * 時間差 + 1/2 * 加速度 * 時間差
呵呵，傳說中的算法都是很經典的，雖然我們早在初中物理的時候就學過。

該算法的好處呢，正如它開始所說的，Latency Hiding & Bandwidth Reduction，從原則上解決了網絡延遲導致的不同步的問題，并且有效的減少了帶寬，不好的地方就是該算法基本上只能使用于移動中的同步，當然，移動 的同步是網絡游戲中同步的最大的問題。

該方法結合我在《網絡游戲的同步》一文中提出的綜合同步法的構架可以基本上解決掉網絡游戲中走路同步的問題。相關問題歡迎大家一起討論。

有關導航推測算法（Dead Reckoning）中的平滑處理：

根據我上篇文章所介紹的，在節點A收到節點B新的PDU包時，如果和A本地的關于B的模擬運動的坐標不一致時，怎么樣在A的屏幕上把B拽到新的 PDU包所描敘的點上面去呢，上文中只提了用“很平滑的移動”把B“拉扯”過去，那么實際中應該怎么操作呢？這里介紹四種方法。

第一種方法，我取名叫直接拉扯法，大家聽名字也知道，就是直接把B硬生生的拽到新的PDU包所描敘的坐標上去，該方法的好處是：簡單。壞處是：看了以下三種方法之后你就不會用這種方法了。

第二種方法，叫直線行走（Linear），即讓B從它的當前坐標走直線到新的PDU包所描敘的坐標，行走速度用上文中所介紹的經典算法：
目標點 = 原點 + 速度 * 時間差 + 1/2 * 加速度 * 時間差算出：
首先算出從當前坐標到PDU包中描敘的坐標所需要的時間：
T = Dest( TargetB – OriginB ) / Speed
然后根據新PDU包中所描敘的坐標信息模擬計算出在時間T之后，按照新的PDU包中的運動信息所應該達到的位置：
_TargetB = NewPDU.Speed * T
然后根據當前模擬行動中的B和_TargetB的距離配合時間T算出一個修正過的速度_S：
_S = Dest( _TargetB – OriginB ) / T
然后在畫面上讓B以速度_S走直線到Target_B，并且在走到之后調整其速度，方向，加速度等信息為新的PDU包中所描敘的。

這種方法呢，非常的土，會讓物體在畫面上移動起來變得非常的不現實，經常會出現很生硬的拐角，而且對于經常要修改的速度_S，在玩家A的畫面上，玩家B的行動會變得非常的詭異。其好處是：比第一種方法要好。

第三種方法，叫二次方程行走（Quadratic），該方法的原理呢，就是在直線行走的過程中，加入二次方程來計算一條曲線路徑，讓Dest( _TargetB – OriginB )的過程是一條曲線，而不是一條直線，恩，具體的實現方法，就是在Linear方法的計算中，設定一個二次方程，在Dest函數計算距離的時候根據設定的 二次方程來計算，這樣一來，可以使B在玩家A屏幕上的移動變得比較的有人性化一些。但是該方法的考慮也是不周全的，僅僅只考慮了TargetB到 _TargetB的方向，而沒有考慮新的PDU包中的方向描敘，那么從_TargetB開始模擬行走的時候，仍然是會出現比較生硬的拐角，那么下面提出的 最終解決方案，將徹底解決這個問題。

——————————————————————————————————————————

網絡游戲同步詳解之三

最后一種方法叫：立方體抖動（Cubic Splines），這個東東比較復雜，它需要四個坐標信息作為它的參數來進行運算，第一個參數Pos1是OriginB，第二個參數Pos2是 OriginB在模擬運行一秒以后的位置，第三個參數Pos3是到達_TargetB前一秒的位置，第四個參數pos4是_TargetB的位置。

Struct pos {
Coordinate X;
Coordinate Y;
}
Pos1 = OriginB
Pos2 = OriginB + V
Pos3 = _TargetB – V
Pos4 = _TargetB
運動軌跡中(x, y)的坐標。
x = At^3 + Bt^2 + Ct + D
y = Et^3 + Ft^2 + Gt + H
（其中時間t的取值范圍為0-1，在Pos1的時候為0，在Pos4的時候為1）
x(0-3)代表Pos1-Pos4中x的值，y(0-3)代表Pos1-Pos4中y的值
A = x3 – 3 * x2 +3 * x1 – x0
B = 3 * x2 – 6 * x1 + 3 * x0
C = 3 * x1 – 3 * x0
D = x0
E = y3 – 3 * y2 +3 * y1 – y0
F = 3 * y2 – 6 * y1 + 3 * y0
G = 3 * y1 – 3 * y0
H = y0

上面是公式，那么下面我們來看看如何獲得Pos1-Pos4：首先，Pos1和 Pos2的取值會比較容易獲得，根據OriginB配合當前的速度和方向可以獲得，然而Pos3和Pos4呢，怎么獲得呢？如果在從Pos1到Pos4的 過程中有新的PDU到達，那么我們定義它為NewPackage。

Pos3 = NewPackage.X + NewPackage.Y * t + 1/2 * NewPackage.a * t^2
Pos4 = Pos3 – (NewPackage.V + NewPackage.a * t)

如果沒有NewPackage的情況下,則Pos3和Pos4按照開始所規定的方法獲得。

至此，關于導航推測的算法大致介紹完畢。

原文來自：http://xinsync.xju.edu.cn/index.php/archives/4079

http://canremember.com/?p=8

http://canremember.com/?p=10

過去一年中，花了很多時間在考慮服務器架構設計方面的問題。看了大量文章、也研究了不少開源項目，眼界倒是開闊了不少，不過回過頭來看，對網游架構設計方面的幫助卻是不多。老外還是玩兒console game的多，MMO Games方面涉及的還是不如國內廣泛。看看 Massively Multiplayer Games Development 1 & 2 這兩本書吧，質量說實話很一般，幫助自然也很有限。當然這也是好事，對國內的研發公司/團隊來說，在網游服務器技術方面當然就存在超越老外的可能性，而且在這方面技術超越的機會更大，當然前提是要有積累、要舍得投入，研發人員更要耐得住寂寞、經得起誘惑，在平均每天收到超過3個獵頭電話的時候——依然不動心。

上面有點兒扯遠了，下面聊聊無縫世界架構（Seamless world server architecture）設計方面的一點兒看法。

先說架構設計的目標——我的看法，服務器組架構設計的目標就是確定各服務器拓補關系和主要的業務邏輯處理方法。主要要解決的問題就是在滿足游戲內容設計需要的前提下，如何提高帶負載能力的問題。

最簡單的架構就是基本的C/S架構，一臺Server直接構成一個Cluster，所有Client直接連接這個Server，這個Server完成所有邏輯和數據處理。這架構其實很好，最大的好處就是它架構上的 Simplicity ，Cluster內部的跨進程交互完全被排除，復雜度立刻就降下來了，而且——完全可以實現一個無縫（Seamless world）的游戲世界。但是即使我不說，大家也知道這種單Server架構會有什么問題。不過我們不妨以另外一個角度來看這個Server——一個黑盒子。從系統外部的角度來看，什么樣的系統都可以看成一個整體、一個黑盒，而不管系統內部的拓補關系和實現復雜度方面的問題。在不考慮這個系統的實現的前提下，理論上Cluster的處理能力就是由硬件的數量和能力決定的，也就是說一個Server Cluster內包含越多的服務器、服務器越‘快’，那么這個Cluster的處理能力越好、帶負載能力越好。那么我們要面對的帶負載能力的問題，就是如何高效的利用這些Server的問題，基本上也可以理解為如何提高玩家請求的并發處理能力的問題。

CPU廠商在很久以前就在考慮這方面的問題了，CPU其實也可以看成個黑盒?？纯此麄冇眠^的技術——流水線（pipeline）技術、多CPU/多核（multicore）技術，以及這些技術的衍生技術。我想了很久讓 Server Cluster 內部處理并行的方法、并且有了比較清晰的思路之后，才發現其實早就可以參照CPU廠商的方法。流水線的方法就是把一個指令處理拆分成很多個步驟，這樣指令的處理被分解之后就可以部分重疊（相當于變成并發的了）執行。我們的Server Cluster一樣可以用這種方法來拆分，我想了個名字——

Services-based Architecture——基于服務的架構。在這種架構內部，我們根據處理數據、邏輯的相關性來劃分組內各個服務器的工作任務。例如：位置服務提供物體可見性信息、物品服務處理所有物品相關的邏輯、社會關系服務提供行會家族等等方面的邏輯、戰斗服務器只處理戰斗相關的邏輯，等等。這樣劃分的話、邏輯處理的并發就有了可能性。舉例來說：A砍B一刀這件事情與C從奸商手里買到一件武器這個事情是完全不相干的，而且這2個請求本來就在不同的服務器上被處理，他們是被不同的Service Server并發處理的。這就是 Services-based Architecture 的并發方法。

基本上，把游戲邏輯的處理拆分成一個個的service，就和設計cpu的時候把機器指令的具體處理拆分，然后設計出一個個流水線單元是一個道理。

Cells-based Architecture——基于cell的架構。每個cell都在不同的物理 server上面運行著完全一樣的應用程序服務器，但是他們負責承載不同的游戲場景區域的游戲邏輯。和 services-based arch. 明顯不同的就是，每個cell都是個‘在邏輯上完整的’服務器。它得處理物品操作、人物移動、戰斗計算等等幾乎所有的游戲邏輯。盡管這么做會帶來一些（可能是很復雜）的問題，但是它完全是可行的。舉例來說：在吳國A砍B一刀顯然地和千里之外在越國的C砍D一刀不搭界，他們完全可以被不同的Cell并發地處理。

基本上，這就相當于一個主板上面插多個CPU或者一個CPU但是有多個內核，每個CPU能做的事情都是一樣的，而且能一起做。

從一組服務器的角度來看，一般來說，我們的服務器組（Cluster）內都會有登陸驗證服務器（Login Server）、持久性數據服務器（DB及DB Proxy）、連接代理服務器（Gate Server、FEP Server、Client Proxy等）以及Auto Patch Server、還有用于集中管理及控制組的服務器等等，由于這些服務器基本上什么樣的架構設計都會用到，所以——現在不考慮以上這些服務器，只考慮具體處理游戲邏輯、游戲規則的各個服務器。以此為前提來分析一下 Services-based Architecture 和 Cells-based Architecture 的優缺點。

對Services-based Architecture 的分析
 

基于服務的架構，顧名思義這種架構的實現（程序）會是和服務的具體內容（策劃）相關的，這是因為——各種【服務】內容的確定是建立于項目的【需求分析】基礎上的，【需求分析】的前提是基本確定了【策劃設計】，至少是項目的概要設計。

我想多數做過游戲項目的人都應該對需求變更有很深的感觸，每個人都說“開始想做的那個和最后實際做出來的那個不一樣”。特別是在項目的早期階段，團隊的不同成員對項目做完之后的樣子有相當不同的看法（很可能大家互相都不知道對方怎么看的），這很容易理解，誰也不可能從幾頁紙幾張圖就確切地知道這個游戲做完了什么樣子，即使不考慮需求變更。涉及到項目開發方法方面的東西這里就不多說了，總之我的看法就是——盡管我們不大可能設計出一個架構能夠適應任何的游戲設計，但是不同開發任務間的耦合度顯然還是越低越好，基于服務的架構適應需求變更的能力較差。

關于服務耦合
不管如何劃分service，不同 service之間都一定存在不同程度的耦合（coupling）關系，不同的 service 之間會有相互依賴關系。而你們的策劃設計可能會讓這種關系復雜到程序在運行時的狀態很難以琢磨的程度。

假設：
服務器組內的戰斗處理和物品處理分別由兩個不同的服務（器）提供
游戲規則：
人物被攻擊后自己攜帶的物品可能掉落到地上
某些物品掉落后會爆炸
物品在地上爆炸可能傷及周圍（半徑10米內）人物
人物之間的‘仇恨度’影響戰斗數值計算
被攻擊時掉落的物品爆炸后傷及的人物，會增加對‘被攻擊人’的‘仇恨度’

我想我還能想出很多很多“看上去不算過分”的規則來讓這個事情變得復雜無比，很可能你們的策劃也在無意中，已經擁有我這種能力 :) 而且他們在寫文檔時候的表達還多半不如我上面寫的清楚，另外，他們還會把這些規則分到很多不同的文檔里面去寫。好吧，你肯定會想“把這兩個服務合二為一好了 ”，實際上不管你想把哪兩個（或多個）服務合并為一個服務的時候，都應該先考慮一下當時是為什么把他們獨立為不同服務的？

實際上很多這樣“看上去不算過分”的規則都會導致service間的頻繁交互，所以每個service最好都是stateless service，這樣的話情況會好很多，但是對于游戲來說這很難做到。

請求處理的時序問題
服務耦合的問題在不考慮開發復雜度比較高的情況下，還是可以被搞定的，只要腦袋夠清醒，愿意花夠多的時間，那么還有更難以搞定的么？我看確實還有，如果你對將要面對的問題，了解得足夠多的話:)

 

 

 

上面兩個序列圖描述的是某個玩家做了連續做了兩次同樣的操作但是很可能得到了不同的結果，當然這些請求都是異步地被處理。問題的關鍵在于——盡管兩次玩家執行的命令一樣、順序一樣，甚至時間間隔都一樣，但是結果卻很不同——因為圖（1）里面C2CS::Request_to_attack請求被處理的時候，C2IS::Request_equip_item 這個請求還沒有被處理完，但是圖（2）顯示的情況就不一樣了。因為C2IS::Request_equip_item這個操作很可能會改變游戲人物的屬性，這個屬性又很可能影響attack的結果。這兩幅圖實際上省略了 Combat Server 與 Item Server 之間的交互過程。但是已經足以說明問題了，每個Service處理每個Request時具體會消耗的時間，是無法在設計時確定的!

誰喜歡這類結果上的不確定性？舉個例子：玩家很可能已經裝備上了“只能使用1次的魔獸必殺刀”然后攻擊了一下魔獸，但是它卻沒死！這會導致什么樣的結果？請自行想象。另外，這種不確定性還會表現為“在項目開發期和運營期的行為差異”，或者“出現某些偶然的奇怪現象”。

那還有解決方案么？有的，其實只要序列化玩家請求的處理，使處理有序進行就可以了。但是又一次的，這會帶來新的復雜度——在某個范圍（整個服務器組？一個行會？一個隊伍？）內，以每個玩家為單位，序列化他（們）的（可能是所有）操作，但是也顯而易見，這在某種程度上降低了請求處理的并發性，盡管它對并發性的影響可能只局限于不大（最少是一個玩家）的范圍。

 

對Cells-based Architecture 的分析
 

基于Cell的架構有個明顯的優勢就是Cell如何劃分和你的策劃沒有關系J這是真的。而且Cell間如何交互可以被放到系統的底層，具體有多底層、多隱蔽（實際上可以隱蔽到對開發上層游戲邏輯的程序員都不可見的程度）要看你的實現如何了。如果做到了某個系統的程序設計與游戲設計完全無關的話，顯然，這個系統受到游戲設計變更（需求變更）的影響就會很小很小，甚至會到完全不受影響的程度，當然這是理想情況。

關于跨邊界對象交互
在基于Cell的服務器架構里面，實現無縫世界（Seamless World）的主要難點在于實現跨邊界對象的交互時會出現的一些問題，因為這些對象在不同的Cell進程里面，這些Cell一般來說是在不同的物理服務器上運行。

無縫世界的特點自然就是無縫，并且因為無縫給玩家帶來更好的游戲體驗，所以顯然我們希望“跨邊界對象交互”問題不把事情搞砸，那么這種交互的表現就必須滿足穩定、高效的前提。一般來說，高于300ms的延遲對玩家操作來說就屬于“明顯可見”的程度了，不能讓玩家騎著500塊RMB買來的虛擬馬在一片大草原上面暢快的奔跑的時候，在某個地方突然就被“看不見的墻”給“擋”了一下，因為這“墻”根本看不見，所以會很影響“上帝”的游戲心情。

關于組成整個虛擬世界的Cell之間的關系，下面來分析兩種情況：

<!--[if !supportLists]-->一， <!--[endif]-->Cell 承載的場景不重疊

 

如圖（1），一個連續的虛擬世界場景被分成左右兩塊，分別在不同的Cell Server上面運行。A、B、C分別是3個不同的游戲角色。在這種情況下B與C的交互并不存在任何障礙，因為B和C只不過是同一個物理服務器上同一個進程內的兩塊不同的內存數據而已。但是A與B/C的交互就不那么直接了，盡管他們所在的場景看上去是“連續的、一體的”但是事情不會像表面上那么簡單。A與B發生交互時候會發生什么事情？例如A攻擊了B、A與B交易物品等等，因為在這種結構下做數據同步會帶來很多問題，例如對象狀態不確定性、開發復雜度等等、相對來說兩個Cell Server之間做網絡通訊而帶來的延遲可能反而是最小的問題，這些問題不需要很復雜的分析就可以得出結論，在此不再多說了。

<!--[if !supportLists]-->二，Cell 承載的場景（部分地）重疊

 

如圖（2），一個連續的虛擬世界場景被分成左右兩塊，分別在不用的Cell Server上面運行。A、B、C、D分別是4個不同的游戲角色。這個情況下，中間的區域為2個Cell所共同維護，中間區域的對象同屬于2個Cell所‘擁有’。這有什么好處？現在，任意兩個對象之間，除了A與C之間的交互，都變得更‘直接’了。變得直接肯定是一件好事兒，那么A與C之間呢？他們之間其實也沒有任何問題J 因為雙方都已經超出了對方的Area of Interest（AoI）區域，游戲規則可以限制他們不能直接交互。

上面提到的第二種方案算不上什么魔法，但是肯定是比第一種方案更有效。接下來怎么辦？假設B是個玩家，他站在中間這塊區域上面時，并不會產生“我到底是在哪里”這樣的疑問J 問題的關鍵在于對于Cell Server來說，怎么樣同步那些處于重疊區域對象的狀態。游戲世界內的對象可能同時處于1個、2個、3個或者4個不同的Cell Server。如果你的Cell分隔方法不限于水平線和垂直線、或者有人故意搗亂的話，還可能會更多。需要被同步的對象也不只是玩家本身，還包括怪物、NPC、一顆會走的樹、某玩家在地上吐的痰等等。

由于我們的基于無縫世界的游戲規則不大會直接去限制游戲世界某處玩家的行為，也就是說玩家如果能相互交易物品的話，他們肯定希望在任何地方都能交易，“為什么其他地方都行，但是在某個墻角做交易就會導致物品丟失？”所以比較可靠的方法是建立一套的用于同步的底層機制，來同步這些跨邊界對象。

怎么實現？這個話題很大，恐怕再寫幾篇Blog我也講不完，但是有一些東西可以作為參考，例如：DCOM和CORBA規范，Java的RMI，基于Python的 PYRO，TAO(The ACE ORB)等等。好在分布式處理的問題不止是網絡游戲會涉及到，可以借鑒的東西還是很多的。

總結
很顯然，這篇文章在兩種架構的評價上面存在某些傾向性，但是傾向性本身只是副產品。另外一個副產品就是關于一些技術分析方法。

在考慮采用何種技術的時候，我們往往很容易地就會忽略對程序之外那些事情的影響。上面我提到的關于Services-based架構實現的時候，提到劃分service及數據設計對程序設計能力的挑戰、對策劃設計的制約，對適應需求變更能力的影響，都不會只是空談。這些問題也不是只在實現這種架構的時候才出現。

不要高估自己的智商，Keep It Simple and Stupid :) 應該可以讓我們離成功更近一點兒。

 

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/romandion/archive/2009/04/02/4044368.aspx

由于網游服務器的設計牽涉到太多內容，比如：網絡通信方面、人工智能、數據庫設計等等，所以本文將重點從網絡通信方面的內容展開論述。談到網絡通信，就不能不涉及如下五個問題：
1、 常見的網游服務通信器架構概述
2、 網游服務器設計的基本原則
3、 網游服務器通信架構設計所需的基本技術
4、 網游服務器通信架構的測試
5、 網游服務器通信架構設計的常見問題

下面我們就從第一個問題說起：

常見的網游服務器通信架構概述
　　目前，國內的網游市場中大體存在兩種類型的網游游戲：MMORPG（如：魔獸世界）和休閑網游（如：QQ休閑游戲和聯眾游戲，而如泡泡堂一類的游戲與QQ休閑游戲有很多相同點，因此也歸為此類）。由于二者在游戲風格上的截然不同，導致了他們在通信架構設計思路上的較大差別。下面筆者將分別描述這兩種網游的通信架構。

1．MMORPG類網游的通信架構
　　網游的通信架構，通常是根據幾個方面來確定的：游戲的功能組成、游戲的預計上線人數以及游戲的可擴展性。
　　目前比較通用的MMORPG游戲流程是這樣的：

a. 玩家到游戲官方網站注冊用戶名和密碼。
b. 注冊完成后，玩家選擇在某一個區激活游戲賬號。
c. 玩家在游戲客戶端中登錄進入已經被激活的游戲分區，建立游戲角色進行游戲。

　　通常，在這樣的模式下，玩家的角色數據是不能跨區使用的，即：在A區建立的游戲角色在B區是無法使用的，各區之間的數據保持各自獨立性。我們將這樣獨立的A區或B區稱為一個獨立的服務器組，一個獨立的服務器組就是一個相對完整的游戲世界。而網游服務器的通信架構設計，則包括了基于服務器組之上的整個游戲世界的通信架構，以及在一個服務器組之內的服務器通信架構。

　　我們先來看看單獨的服務器組內部的通信是如何設計的。
　　一個服務器組內的各服務器組成，要依據游戲功能進行劃分。不同的游戲內容策劃會對服務器的組成造成不同的影響。一般地，我們可以將一個組內的服務器簡單地分成兩類：場景相關的（如：行走、戰斗等）以及場景不相關的（如：公會聊天、不受區域限制的貿易等）。為了保證游戲的流暢性，可以將這兩類不同的功能分別交由不同的服務器去各自完成。另外，對于那些在服務器運行中進行的比較耗時的計算，一般也會將其單獨提煉出來，交由單獨的線程或單獨的進程去完成。

　　各個網游項目會根據游戲特點的不同，而靈活選擇自己的服務器組成方案。經常可以見到的一種方案是：場景服務器、非場景服務器、服務器管理器、AI服務器以及數據庫代理服務器。
　　以上各服務器的主要功能是：

　　場景服務器：它負責完成主要的游戲邏輯，這些邏輯包括：角色在游戲場景中的進入與退出、角色的行走與跑動、角色戰斗（包括打怪）、任務的認領等。場景服務器設計的好壞是整個游戲世界服務器性能差異的主要體現，它的設計難度不僅僅在于通信模型方面，更主要的是整個服務器的體系架構和同步機制的設計。

　　非場景服務器：它主要負責完成與游戲場景不相關的游戲邏輯，這些邏輯不依靠游戲的地圖系統也能正常進行，比如公會聊天或世界聊天，之所以把它從場景服務器中獨立出來，是為了節省場景服務器的CPU和帶寬資源，讓場景服務器能夠盡可能快地處理那些對游戲流暢性影響較大的游戲邏輯。

　　服務器管理器：為了實現眾多的場景服務器之間以及場景服務器與非場景服務器之間的數據同步，我們必須建立一個統一的管理者，這個管理者就是服務器組中的服務器管理器。它的任務主要是在各服務器之間作數據同步，比如玩家上下線信息的同步。其最主要的功能還是完成場景切換時的數據同步。當玩家需要從一個場景A切換到另一個場景B時，服務器管理器負責將玩家的數據從場景A轉移到場景B，并通過協議通知這兩個場景數據同步的開始與結束。所以，為了實現這些內容繁雜的數據同步任務，服務器管理器通常會與所有的場景服務器和非場景服務器保持socket連接。

　　AI（人工智能）服務器：由于怪物的人工智能計算非常消耗系統資源，所以我們把它獨立成單獨的服務器。AI服務器的主要作用是負責計算怪物的AI，并將計算結果返回給場景服務器，也就是說，AI服務器是單獨為場景服務器服務的，它完成從場景服務器交過來的計算任務，并將計算結果返回給場景服務器。所以，從網絡通信方面來說，AI服務器只與眾多場景服務器保持socket連接。

　　數據庫代理服務器：在網游的數據庫讀寫方面，通常有兩種作法，一種是在應用服務器中直接加進數據庫訪問的代碼進行數據庫訪問，還有一種方式是將數據庫讀寫獨立出來，單獨作成數據庫代理，由它統一進行數據庫訪問并返回訪問結果。

　　其中，非場景服務器在不同的游戲項目中可能會被設計成不同的功能，比如以組隊、公會或全頻道聊天為特色的游戲，很可能為了滿足玩家的聊天需求而設立單獨的聊天服務器；而如果是以物品貿易（如拍賣等）為特色的游戲，很可能為了滿足拍賣的需求而單獨設立拍賣服務器。到底是不是有必要將某一項游戲功能獨立處理成一個服務器，要視該功能對游戲的主場景邏輯（指行走、戰斗等玩家日常游戲行為）的影響程度而定。如果該功能對主場景邏輯的影響比較大，可能對主場景邏輯的運行造成比較嚴重的性能和效率損失，那么應考慮將其從主場景邏輯中剝離，但能否剝離還有另一個前提：此功能是否與游戲場景（即地圖坐標系統）相關。如果此功能與場景相關又確實影響到了主場景邏輯的執行效率，則可能需要在場景服務器上設立專門的線程來處理而不是將它獨立成一個單獨的服務器。

　　以上是一個服務器組內的各服務器組成情況介紹，那么，各服務器之間是如何通信的呢？它的基本通信構架有哪些呢？
　　MMORPG的單組服務器架構通?？梢苑譃閮煞N：第一種是帶網關的服務器架構；第二種是不帶網關的服務器架構。兩種方案各有利弊。

　　就帶網關的服務器架構而言，由于它對外只向玩家提供唯一的一個通信端口，所以在玩家一側會有比較流暢的游戲體驗，這通常也是那些超大規模無縫地圖網游所采用的方案，但這種方案的缺點是服務器組內的通信架構設計相對復雜、調試不方便、網關的通信壓力過大、對網關的通信模型設計要求較高等。第二種方案會同時向玩家開放多個游戲服務器端口，除了游戲場景服務器的通信端口外，同時還可能提供諸如聊天服務器等的通信端口。這種方案的主要缺點是在進行場景服務器的切換時，玩家客戶端的表現中通常會有一個諸如場景調入的界面出現，影響了游戲的流暢感。基于這種方案的游戲在客戶端的界面處理方面，比較典型的表現是：當要進行場景切換時，只能通過相應的“傳送功能”傳送到另外的場景去，或者需要進入新的場景時，客戶端會有比較長時間的等待進入新場景的等待界面(Loading界面)。

　　從技術角度而言，筆者更傾向于將獨立的服務器組設計成帶網關的模型，雖然這加大了服務器的設計難度，但卻增強了游戲的流暢感和安全性，這種花費還是值得的。
　　筆者在下面附上了帶網關的MMORPG通信架構圖，希望能給業內的朋友們一點有益的啟迪。