Posted on 2012-05-15 17:09
steven.cui 閱讀(13457)
評(píng)論(7) 編輯 收藏 所屬分類:
java
NIO的理解，請(qǐng)參照：http://www.goldendoc.org/category/java-nio/
Netty的一些理解，請(qǐng)參照：
http://www.kafka0102.com/2010/06/167.html
http://rdc.taobao.com/team/jm/archives/423
Netty的高可靠性，可伸縮性，以及效率的確讓人著迷，為什么Netty這么快呢？
Netty高效的原因：
- 實(shí)現(xiàn)了多路Selector用于讀和注冊(cè)，線程數(shù)量是cpu*2，reactor都是這么做的，自己處理寫(xiě)事件，這個(gè)我在自己框架中也是這么做的，nio的selector處理注冊(cè)和讀，并且也優(yōu)化了wakeup，Netty中的wakeup也是優(yōu)化過(guò)的，本身一次wakeup對(duì)Nio并不大，但是大批量并發(fā)的時(shí)候就需要進(jìn)行優(yōu)化處理了，只有當(dāng)selector堵塞的時(shí)候進(jìn)行wakeup，或者說(shuō)需要下次立刻返回的時(shí)候wakeup。
- Netty在開(kāi)啟多路讀寫(xiě)的時(shí)候，用的是DirectBuffer，并用了SoftReferrence來(lái)做緩存優(yōu)化，減少傳輸數(shù)據(jù)的內(nèi)存移動(dòng)和GC。還有預(yù)測(cè)數(shù)據(jù)算法，這個(gè)具體能不能提高有待討論
- 并發(fā)的控制，基于SEDA的設(shè)計(jì)理論構(gòu)建的高效事件模型，真正的異步處理，吞吐量和伸縮性都可以得到保證。
nio的實(shí)現(xiàn)并不復(fù)雜，但想讓你的底層通訊，效率，以及可伸縮性和高可靠性做好，還是極具挑戰(zhàn)性的。
目前有個(gè)項(xiàng)目是自己寫(xiě)的nio，但效率比起netty來(lái)，小了幾個(gè)數(shù)量級(jí)，當(dāng)然以本人一己之力能做到目前這個(gè)情況，還算自己滿意，也用到生產(chǎn)環(huán)境中了，一個(gè)web game，及時(shí)性要求很高，一臺(tái)server，5000人沒(méi)問(wèn)題。同時(shí)廣播消息在10000人以內(nèi)，當(dāng)然有些優(yōu)化是在業(yè)務(wù)邏輯層面的。當(dāng)然比起netty的效率來(lái)講還是差了幾個(gè)數(shù)量級(jí)。
除了高效，Netty在擴(kuò)展性方面做的不錯(cuò)：
- 豐富的decoder/encoder實(shí)現(xiàn)，你可以輕松的繼承一個(gè)類實(shí)現(xiàn)自己的邏輯，例如游戲中，直接繼承FiledLengthBaseFrameDecoder即可。
- 自行添加decoder或者encoder，自由的控制事件流向順序，通過(guò)這個(gè)，可以實(shí)現(xiàn)一些協(xié)議加密解密，協(xié)議過(guò)濾器，統(tǒng)計(jì)工具等等
- 提供很多工具類：Timeout的一些實(shí)現(xiàn)，還有ChannelBuffers的一些工具，通常情況下，我們?yōu)榱藴p少對(duì)Netty的依賴，會(huì)自己再封裝一層，以完全達(dá)到脫離Netty的目的，都會(huì)再次封裝一層ChannelBuffer，這樣目的是不要讓上層邏輯跟底層通訊有任何關(guān)聯(lián)，降低耦合，當(dāng)然也在為考慮更換底層通訊而不影響上層邏輯。
- 提供監(jiān)聽(tīng)底層消息的ChannelFuture，例如發(fā)送完消息可以斷開(kāi)連接等等
- 可調(diào)控的通訊架構(gòu)，可以根據(jù)業(yè)務(wù)的吞吐量來(lái)調(diào)整，Netty的各項(xiàng)參數(shù)不只有socket的一些設(shè)置，還能控制事件流順序和吞吐量的大小等等。
最后，基于Netty我簡(jiǎn)單封裝了一個(gè)web game所具備的一些GameBuffer，目前比較簡(jiǎn)陋，后續(xù)可能加入一些別的功能。
項(xiàng)目在:https://github.com/cuixin/XGameEnginee/