全文來(lái)源: http://m.shnenglu.com/darkdestiny/

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

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

M覺(jué)得虧20個(gè)蘋果沒(méi)什么，但是因?yàn)槌圆簧咸O果而流失的顧客是一個(gè)極大的損失。M決定改進(jìn)流水線，親自參加烤蘋果。
*顧客想吃烤蘋果，M向A索要蘋果
*A抓起一個(gè)蘋果，交給M
*M檢查蘋果，把蘋果交給B
*B把蘋果切開(kāi)，交給M
*M把蘋果片交給C
*C在蘋果片抹上胡椒，交給M
*M把蘋果交給D
*D把蘋果烤熟，交給M
此時(shí)，M把熱騰騰的烤蘋果交給了顧客，顧客因?yàn)闊狎v騰引起了不好的聯(lián)想，走掉了。
這一次，M對(duì)顧客要吃的每一個(gè)蘋果都貼上一個(gè)唯一標(biāo)簽，設(shè)置一個(gè)5秒超時(shí)，如果超時(shí)則重新為顧客烤蘋果，原來(lái)烤了一半的直接扔掉。

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

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

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

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