全文來源: http://m.shnenglu.com/darkdestiny/

1.服務器間的異步事務
上個月，最有收獲的事情，大概就是這個了吧。
幾個不同功能的服務器相互協(xié)作以實現(xiàn)一個角色登錄場景的需求。這是一個異步的過程，異步令人討厭的地方就是，他不是一個服務器能夠順序完成的事情，而你卻不知道什么時候什么服務器會因為太陽風的異常活動而崩潰。如果你假設所有服務器都是穩(wěn)定的，他們最多只有80％的時間如你所愿，剩下的就是boss的咆哮(2/8原則)。

一開始我并不了解異步事務的概念，所以角色登錄場景的流程寫得非常松散。用A，B，C，D合作烤蘋果比方的話，就是
*A抓起一個蘋果，交給B
*B把蘋果切開，交給C
*C在蘋果片抹上胡椒，交給D
*D把蘋果烤熟
以人類的眼光看這個流程，是一個完美的流水線，而且中途誰因為天熱而蒸發(fā)掉的話，大家也都很清楚的知道而作出恰當?shù)姆答?暫停流水線，等待信春哥的某人滿血滿buff原地復活等等)。
但是這樣的流程卻完全不適合映射到程序上——多個服務器之間對彼此行為和狀態(tài)的詳細跟蹤，是一件多么困難，復雜，不通用，吃力不討好的事情。那么在程序上，烤蘋果的工人之間就不是在一個大開間暢聊，而是被關在一個小黑屋里孤獨的工作，彼此不能看到，并且傳遞蘋果的空間非常不穩(wěn)定，工人必須時刻用一只手等蘋果，否則蘋果就會變成香蕉。工頭Master(M)為節(jié)省成本沒有開空調，所以偶爾有人蒸發(fā)又復活什么的，但是流水線不會停下來，100個蘋果也就烤出80個左右。

M覺得虧20個蘋果沒什么，但是因為吃不上蘋果而流失的顧客是一個極大的損失。M決定改進流水線，親自參加烤蘋果。
*顧客想吃烤蘋果，M向A索要蘋果
*A抓起一個蘋果，交給M
*M檢查蘋果，把蘋果交給B
*B把蘋果切開，交給M
*M把蘋果片交給C
*C在蘋果片抹上胡椒，交給M
*M把蘋果交給D
*D把蘋果烤熟，交給M
此時，M把熱騰騰的烤蘋果交給了顧客，顧客因為熱騰騰引起了不好的聯(lián)想，走掉了。
這一次，M對顧客要吃的每一個蘋果都貼上一個唯一標簽，設置一個5秒超時，如果超時則重新為顧客烤蘋果，原來烤了一半的直接扔掉。

前面鋪墊了那么多，其實就是想說明一件事情：處理服務器間的異步事務，最好設置一個master服務器，集中控制每一個步驟的運作，為每一個事務設置一個超時；在事務失敗或者超時后作出反饋。

2.異步事務的實現(xiàn)方式
2.1狀態(tài)機
第一次我是用狀態(tài)機實現(xiàn)的，master等待每個worker反饋的過程作為一個狀態(tài)，worker的反饋作為一個trigger，迫使master跳轉到下個事務狀態(tài)，執(zhí)行step，接著等待新的反饋，直到事務結束。
基于狀態(tài)機的形式聽起來很直觀，但實際上用起來并非如此順手，總是覺得有些違和，修改的時候總會遭遇一些復雜情景，特別是在中間修改事務步驟的時候。
其中我所犯的一個錯誤就是給予每一個步驟設置設置步驟超時的機制，這非常不好做，容易出bug，最后才意識到一個事務一個超時的規(guī)則。

2.2C協(xié)程
協(xié)程可以認為是需要手動進行調度的線程，協(xié)程不像線程那樣由OS調度，協(xié)程何時運行何時掛起都是由程序員控制的。
C的體系下是沒有協(xié)程的，雖然找到了一些C協(xié)程的庫，可是接口和實現(xiàn)都相當不雅。唯一一個我認可的，是一個基于少量多線程來實現(xiàn)協(xié)程功能的庫，可是在服務器上使用多線程是謹慎事項之一。
其他語言體系下的同學，如果有好的協(xié)程支持(最好是基于多堆棧的)，大可放心使用。

2.3lua協(xié)程
這是最后實現(xiàn)并決定的方式，如果今后不改變的話。lua支持多堆棧，所以lua有協(xié)程是理所當然的了。
用協(xié)程實現(xiàn)事務有哪些好處呢？可以將整個異步事務的代碼寫在一個函數(shù)中，就像一個程序內的同步操作一樣，這是一件多么美好而具有可讀性的事情，相比狀態(tài)機而言。
如何用協(xié)程實現(xiàn)事務呢？執(zhí)行一個事務時，協(xié)程函數(shù)運行，執(zhí)行step，然后在等待反饋的時候掛起；master收到反饋以后，resume協(xié)程，在上次掛起的地方繼續(xù)往下運行，執(zhí)行下一個step，等待新反饋而掛起；如此反復，直至完成。