• <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>
            @true
            你說的這種模式也是使用較廣的,而且比較適合使用在賬號代理角色代理上,比如玩家的定時保存信息,完全是無序不需要保證先后順序的,則可以在邏輯層直接轉(zhuǎn)空閑線程處理,而玩家退出登錄這類要保證先后順序的操作就必須要由一個線程單獨處理。在邏輯模塊的開發(fā)上我個人還沒成功使用過,有序和無序的分開解決,是解決了安全問題,但是無形中進一步加大了開發(fā)上手度和難度,而且各邏輯模塊間也再也不能直接交互了,只能以消息棒的形式交互了。
            @expter
            你說的這個就是文里面一開始提到的主流線程的架構(gòu)模式了。網(wǎng)絡(luò)層一個,邏輯層一個。安全性等等肯定都是可以做到非常好的,但是效率上肯定就差了,其實各個場景本來就是獨立,完全可以單獨開線程,這個文討論的就是如何用安全高效的方式來解決多線程
            10:27 不知道 在回復(fù)中所提到的也是一種主流方式,在消息的邏輯處理模塊為各個場景單獨開線程,但是網(wǎng)絡(luò)層收發(fā)消息的處理上仍然還是一個,所以我這里提出的就是可以依據(jù)游戲服務(wù)器的特殊性,以場景為單位來管理本場景內(nèi)的LINK,在網(wǎng)絡(luò)收發(fā)處為每個場景開線程來收發(fā)。
            也有一種情況可以是直接在網(wǎng)絡(luò)層為link分組各個線程管理,比如預(yù)生成的1000個Link,0--499號Link是A線程管理,500--999是B線程管理,但是這樣會在消息同步等方面出現(xiàn)問題,比如A玩家和B玩家打架 A砍了B一刀,B砍了A一刀,這時候在先后順序上就有可能出現(xiàn)問題了,A的Link在A線程,B的Link在B線程,有可能是A的操作是先做,但是B線程先Tick了,導(dǎo)致B的砍一刀比A的砍一刀先處理了。。所以我這里提出是以場景為單位來管理Link 則這種問題就會避免了。。
            我這里提出的模式就是網(wǎng)絡(luò)層以場景為單位線程管理本場景內(nèi)LINK,而后是各個場景再來各個的邏輯處理線程處理各個場景的消息隊列
            我覺得開發(fā)中還是需要在必要的地方結(jié)合特項目的特殊情況做特殊考慮與處理,
            這也就是一種構(gòu)思了,還需要一些具體實施
            從設(shè)計模式角度來說,肯定是不夠好的了,要不怎么叫異變呢。。。
            不過從性能上來說,個人認為還是提高的。。。
            @keror
            通用完全獨立模塊和效率必然要選擇其一了。
            @不知道
            缺點的確有,從架構(gòu)上來說,層次互饒的確不好,但是具備了一定的好處,而且可以從設(shè)計模式的角度做好層次互分,我是這么認為的
            1:首先 如果還是在網(wǎng)絡(luò)層一個線程對所有SOCKET做處理 再轉(zhuǎn)發(fā)至各個場景消息隊列 由各個場景的消息處理線程對其做處理,也的確可實現(xiàn)消息處理的多線程,但是不可避免的,在SOCKET對LINK的管理上任然會出現(xiàn)性能瓶頸,因為在進出口上只有一條路(如果進出口這里直接用多線程,則會出現(xiàn)無法知道與控制與為什么是這個線程管理這個Link 而另一個線程管理另幾個Link)
            2:如果將LINK的管理層次上到場景級別,缺點是一定層度上與架構(gòu)第二層次互饒,但是優(yōu)點是對各個LINK的管理也不再是一條路了,由各個場景LINK管理線程對各個場景內(nèi)的LINK做管理,也是多條路了,而后再發(fā)至各個場景消息隊列,又各個場景消息處理線程對消息做邏輯層次處理,可解決瓶頸
            3:從模式角度來解決耦合度的問題,制造SceneLinkManager 掛接各個場景,制造各個SceneLinkManager線程,服務(wù)器啟動根據(jù)場景來生成,而SceneLogic與PlayerLogic仍在上一層次,消息進入隊列從Link找到Player,并且再制造每個場景的消息邏輯處理線程,消息隊列的邏輯處理只在這里面進行,因而我們?nèi)匀徽J為此Manager還是屬于網(wǎng)絡(luò)層次,對于上層邏輯無需關(guān)注SceneLinkManager的操作。
            A*是最垃圾的,實際開發(fā)中肯定不會用了 哈
            BLOG玩的不熟,其實這方面我OUT了。。。。晚上研究下。。。。。。。俺本來是準(zhǔn)備畫圖的,然后一打字就顯麻煩就直接打字畫了。。然后還自認為格式弄的很好,而后發(fā)出來成這樣了。。。。。。
            謝謝支持。力求最淺的表達出所應(yīng)了解度
            。。。。。。。。。。。。。。。。。。。
            一到晚上就精神了、、、、、、、不到個幾點睡不著啊
            拍磚就好 本來就是新手看啦
            "籃子"。。。。。。。。。。剛才讀樓上評論歪音了
            昨晚還漏了模塊,晚上在2里補

            導(dǎo)航

            <2025年6月>
            25262728293031
            1234567
            891011121314
            15161718192021
            22232425262728
            293012345

            統(tǒng)計

            常用鏈接

            留言簿(2)

            隨筆分類

            隨筆檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            亚洲乱码精品久久久久..| 久久国产精品久久| 久久久久国产精品麻豆AR影院 | 久久久噜噜噜久久| 久久久久久久97| 久久精品一本到99热免费| 狠狠狠色丁香婷婷综合久久五月| 精品久久久久久亚洲| 欧美久久久久久精选9999| 精品人妻伦九区久久AAA片69| 久久狠狠高潮亚洲精品| 国产成人99久久亚洲综合精品 | 久久久99精品成人片中文字幕| 武侠古典久久婷婷狼人伊人| 99久久久精品免费观看国产| 97久久国产露脸精品国产| 热久久视久久精品18| 久久久久国色AV免费看图片| 色妞色综合久久夜夜| 天堂久久天堂AV色综合| 久久精品亚洲欧美日韩久久| 国产成人精品久久一区二区三区| 久久久精品人妻一区二区三区四 | 久久久久人妻一区精品| 狠狠色婷婷综合天天久久丁香| 久久久久久久精品妇女99| 免费一级做a爰片久久毛片潮| 久久99热国产这有精品| 国产亚洲色婷婷久久99精品| 亚洲AV无码久久精品成人| 亚洲色欲久久久综合网| 久久午夜夜伦鲁鲁片免费无码影视 | 久久99国产一区二区三区| 四虎亚洲国产成人久久精品| 色综合久久88色综合天天| 深夜久久AAAAA级毛片免费看| 中文字幕成人精品久久不卡| 久久婷婷五月综合色99啪ak| 久久精品国产亚洲一区二区三区 | 久久青青草视频| 久久天天躁夜夜躁狠狠|