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