• <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>

            網絡服務器軟件開發/中間件開發,關注ACE/ICE/boost

            C++博客 首頁 新隨筆 聯系 聚合 管理
              152 Posts :: 3 Stories :: 172 Comments :: 0 Trackbacks
                     之前考慮服務端架構時,將數據庫服務器單獨作為一個服務DbServer,其他服務不能直接訪問數據庫,只能通過DbServer間接訪問,這樣不會造成短時間內對數據庫訪問的驟增,安全性提高了。現在遇到的問題是,游戲邏輯復雜,導致了大量的數據庫相關的操作,對于每一個訪問,都必須有一對DB_**_REQ,和DB_**_RES,如果不需要數據庫的返回值,比如delete操作,或者update操作,工作量還小一些,但對于select操作,需要異步處理DB_**_RES,這樣一次數據庫訪問,游戲邏輯需要處理2個消息,而且目前只能是異步處理,對于同步訪問的方式不支持,調試代碼比較費事。另一個問題,對于比較復雜的消息結構也不方便處理,比如多個變長字段,需要在邏輯服務器和數據庫服務器都處理,指針操作很多,對于邏輯服務器由于面向client,無法避免,但數據庫服務器應該采用更簡潔,更直觀的方案,以最大程度的維持穩定性?,F在公司準備調研ICE了,我力薦,也符合和C#交互的需求,初步試用了ICE中的AMI,很強大,對于slice的接口,既支持同步調用,也支持異步調用,另一個推薦的原因是,ICE天生是一個分布式系統的框架,由于其自身的穩定性,方便后期在數據庫前端添加緩沖系統。
            posted on 2010-09-18 17:32 true 閱讀(1216) 評論(1)  編輯 收藏 引用 所屬分類: ICE

            Feedback

            # re: 試用了ICE的AMI 2012-02-14 22:18 qq:1510914311
            支持!  回復  更多評論
              

            无码伊人66久久大杳蕉网站谷歌| 久久国产精品久久精品国产| 热综合一本伊人久久精品| 99久久99久久精品国产片| 性高湖久久久久久久久AAAAA| 无码AV中文字幕久久专区| 久久精品a亚洲国产v高清不卡| 久久综合久久综合九色| 无夜精品久久久久久| 国内精品久久久久影院薰衣草| 精品久久久久久无码人妻热| 伊人久久精品无码av一区 | 99久久精品国产高清一区二区| 精品综合久久久久久888蜜芽| 亚洲综合久久综合激情久久| 亚洲国产成人久久综合碰| 日本三级久久网| 久久香蕉超碰97国产精品| 久久久久成人精品无码| 亚洲欧美日韩精品久久| 精品熟女少妇av免费久久| 久久久一本精品99久久精品88| 国产精品青草久久久久福利99 | 91精品国产91久久久久久青草| 久久久久亚洲AV无码专区桃色| 97超级碰碰碰久久久久| 精品久久久久久国产| 久久99精品久久久久久噜噜| 伊人色综合久久天天| 久久综合综合久久97色| 久久99国产精品久久99| 日韩亚洲欧美久久久www综合网| 狠狠色丁香婷婷久久综合不卡 | 精品国产乱码久久久久久1区2区| 最新久久免费视频| 精品欧美一区二区三区久久久| 久久综合久久性久99毛片| 国内精品伊人久久久久网站| 国内精品久久久久影院网站| 无码任你躁久久久久久久| 亚洲精品久久久www|