• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 119  文章 - 290  trackbacks - 0

            博客搬家了哦,請移步
            叫我abc

            常用鏈接

            留言簿(12)

            隨筆分類

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 304391
            • 排名 - 84

            最新評論

            閱讀排行榜

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

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

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

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

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

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

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

            posted on 2009-07-05 18:46 LOGOS 閱讀(5130) 評論(8)  編輯 收藏 引用 所屬分類: month-flow

            FeedBack:
            # re: 服務(wù)器間異步事務(wù)處理 2009-07-07 22:14 懶人
            lua thread用在處理服務(wù)器的對話框機制不錯,等待一個用戶輸入,開啟下一段文字  回復(fù)  更多評論
              
            # re: 服務(wù)器間異步事務(wù)處理 2009-07-08 17:44 developer
            博主 能詳細介紹一下服務(wù)器異步事務(wù)的部分嗎,我剛好也在做相關(guān)的內(nèi)容,希望可以學習一下,謝謝了  回復(fù)  更多評論
              
            # re: 服務(wù)器間異步事務(wù)處理 2009-07-08 19:44 LOGOS
            @developer
            我覺得我把重點的地方都說出來了。
            不知道你指的是什么內(nèi)容
              回復(fù)  更多評論
              
            # re: 服務(wù)器間異步事務(wù)處理 2009-07-09 18:28 developer
            是這樣,多服務(wù)器間的異步事務(wù)會存在并行處理的情況,這時候可能需要多次分別提交,這樣狀態(tài)就會比較難控制.

            比如,Server A做了一些數(shù)據(jù)庫操作(沒有提交),然后更新master的msg 1狀態(tài),等待server B的處理結(jié)果;Server B被觸發(fā)后也執(zhí)行了一些數(shù)據(jù)庫操作(沒有提交),然后更新master的msg 1狀態(tài)去告訴Server A自己的執(zhí)行結(jié)果;
            那么,問題出現(xiàn)了,A和B如何相互確定對方已經(jīng)成功獲取了狀態(tài)然后提交呢?

            場景1: A獲得了B的更新狀態(tài),于是繼續(xù)執(zhí)行并提交數(shù)據(jù)庫,然后再更新通知B也提交,但B獲取狀態(tài)失敗并超時回滾了,A卻無法回滾數(shù)據(jù)庫了;
            場景2:A獲得了B的更新狀態(tài),于是繼續(xù)執(zhí)行,然后再更新通知B提交;B提交后A提交卻失敗了,而B無法回滾了;

            我感覺這種場景下,不管如何處理,總會存在一種場景造成整體事務(wù)無法完全回滾的現(xiàn)象!不知道你是如何處理的?

            另外,對于狀態(tài)控制部分,你使用的什么方式?DB還是消息中間件還是。。。?
              回復(fù)  更多評論
              
            # re: 服務(wù)器間異步事務(wù)處理 2009-07-09 22:37 LOGOS
            A或者B的提交操作一旦執(zhí)行,就無法回滾,是一個非常讓人為難的情形。我大概會這么做
            場景1:AB合并成一個服務(wù)器。不過這可能是現(xiàn)實情況下最做不到的事情。
            場景2:事務(wù)中,把A需要對數(shù)據(jù)庫進行的操作傳給B,由B完成A和B的操作并提交。這在一些情況下還是可以做到的吧。
            場景3:事務(wù)中,A和B都只是修改臨時表,最后由A或者B將臨時表的修改寫入真表。這也只是針對某些情況。

            ”另外,狀態(tài)控制部分,使用什么方式“
            這是指什么?是master等待A或者B的某個操作嗎?  回復(fù)  更多評論
              
            # re: 服務(wù)器間異步事務(wù)處理 2009-07-10 09:57 99讀書人
            不錯哦  回復(fù)  更多評論
              
            # re: 服務(wù)器間異步事務(wù)處理 2009-07-10 11:48 developer
            因為是多服務(wù)器的分布式事務(wù),所以必然會涉及多個運行在不同主機上的進程和多個DB的數(shù)據(jù)操作,這種情況下,合并服務(wù)器或者不同DB的操作實際應(yīng)用中都不可行,我覺得唯一的出路還是通過服務(wù)器間消息通信來控制各主機的行為,但這個方式的難點就在于,采用何種方式或技巧才能保證消息及時可靠的傳遞以及如何保證事務(wù)完整性。

            目前我使用的是Tuxedo的消息中間件來在服務(wù)器間傳遞消息,但易用性和可靠性都不理想,以至于必須得考慮任何一次通信中對方?jīng)]有接收到消息的情況,這實際又造成任何一方都無法最終確認對方的執(zhí)行結(jié)果;
            你文中說的master通過狀態(tài)機來調(diào)度,我覺得也可以算作是通過狀態(tài)來傳遞消息,這個機制你具體是如何實現(xiàn)的呢?

            我對協(xié)程的應(yīng)用不熟悉,感覺好像是一個比較優(yōu)雅的解決辦法,但它應(yīng)該是不可以跨服務(wù)器遠程調(diào)用吧?你是如何應(yīng)用lua的協(xié)程呢?  回復(fù)  更多評論
              
            # re: 服務(wù)器間異步事務(wù)處理 2009-07-10 16:09 LOGOS
            通信總是不可靠的,所以發(fā)出一條消息后等待回執(zhí)無非就3種情況
            1.超時
            2.回執(zhí)
            3.發(fā)出回執(zhí)的服務(wù)器崩潰
            如果能處理到這三種消息,基本上就沒什么疏漏了。
            比較微妙的是回執(zhí)服務(wù)器崩潰的情況,需要去檢查操作是否真的被執(zhí)行了。

            事務(wù),被稱為transaction,必須能做到在任何一點上rollback。
            在我的想法里,只有master知曉事務(wù)的狀態(tài),并確認ABCD的執(zhí)行結(jié)果。ABCD只負責do-echo。
            狀態(tài)機和協(xié)程只是用來在master上維護事務(wù)狀態(tài)和步驟的一種方案,也許還有別的方案的。

            狀態(tài)機就是設(shè)計模式里的那個。
            協(xié)程很優(yōu)雅,不可以遠程調(diào)用。
            這兩個東西,往細里說就大了。  回復(fù)  更多評論
              
            # re: 服務(wù)器間異步事務(wù)處理 2012-05-29 13:40 Midnight
            我覺得樓主光說理論沒用  回復(fù)  更多評論
              
            51久久夜色精品国产| 国产精品99久久久久久董美香| 色婷婷噜噜久久国产精品12p | 久久久久亚洲?V成人无码| 久久久久亚洲爆乳少妇无| 欧美久久久久久| 久久精品国产亚洲77777| 久久久中文字幕| 国内精品伊人久久久久777| 狠狠色丁香婷婷久久综合不卡| 免费精品久久久久久中文字幕| 欧美亚洲色综久久精品国产| 精品国产青草久久久久福利| 一本色道久久99一综合| 久久精品国产精品亚洲人人| 久久丫精品国产亚洲av| 亚洲精品无码久久毛片| 久久综合狠狠综合久久激情 | 国产偷久久久精品专区| 久久亚洲天堂| 久久精品免费大片国产大片| 国内精品九九久久久精品| 国产一区二区久久久| 久久亚洲国产成人影院网站| 国产精品欧美久久久天天影视| 久久精品人人做人人爽电影| 久久综合亚洲色HEZYO国产| 亚洲精品高清国产一久久| 久久精品www人人爽人人| 亚洲综合伊人久久综合| 热99RE久久精品这里都是精品免费| 91久久精品视频| 国产精品熟女福利久久AV| 激情综合色综合久久综合| 麻豆精品久久精品色综合| 久久99精品国产99久久| 99久久成人国产精品免费| 久久久久久a亚洲欧洲aⅴ| 久久这里只精品国产99热| 精品综合久久久久久97超人| 伊人久久大香线蕉影院95|