聊聊t-io和netty的差異
引言
t-io和netty的差異,這是個被大量問及的問題,在此,作為t-io作者,列一些差異化的東西
t-io的最大優勢
API設計易懂,儘量避免引入自創概念——最大限度降低學習成本
接管了大量業務資源的繫結與自動解綁,開發人員只需要無腦地呼叫 API即可完成繫結與解綁功能,這個處理如果丟給業務開發人員是 極其複雜易錯的 :
-
多執行緒環境下的集合管理都是要同步安全的,同步的設計既要安全又要高效
-
一是容易忘記釋放資源從而導致 OOM,二是容易忘記加鎖或是加了死鎖從而導致系統假死
-
其它同類框架為何以各種理由逃避實現這些功能?
-
和業務掛鉤的都不好抽象
-
會消耗框架效能
-
複雜易錯
內建了豐富的易用的 API,開發人員一個方法就能搞定很多業務事情
提供了生產級別的 showcase示範工程
-
有經驗的開發人員稍事修改即可用在生產環境
-
沒經驗的開發人員可以當作入門的示範程式碼
文件集中在官網,使用者不需要到處學習無用的、錯誤的文件 ——進一步降低學習成本和試錯成本
netty的最大優勢
大量公有協議的實現
大量基於 netty的高層框架
其它對比
netty有大量公有協議的實現,t-io官方目前提供的僅有http和websocket
netty用到了零複製,這一點t-io在均衡再三之後,放棄了零複製,原因如下 :
-
零複製只是改善效能的手段(或叫演算法),對使用者而言,框架採用什麼演算法並不重要,重要的是最終的目的是否達成 —— netty用零複製來改善效能,t-io自創同步安全執行緒池來改善效能,都是手段,殊途同歸。
-
零複製在減少複製過程的同時,也消耗了計算機其它資源
-
堆外資源的管理勢必增加 t-io程式碼的複雜度,使t-io使用者難以在原始碼層駕馭t-io
-
部分同類框架引入堆外資源管理後,在某些場景的確是提升了效能,但這個過程也增加了很多嚴重 BUG
-
t-io的效能已經足夠好,把精力花在服務業務上,而不是效能PK場上
t-io自創了同步執行緒池, 正是有了這個, t-io內部排程執行緒時就顯得尤為簡單,與netty的零複製一樣,這也是改善效能與簡化程式設計的手段,而不是最終目的。
t-io內建了業務資料管理能力 , 這是個非常重要的能力,網路程式設計資料繫結和釋放是件極其考驗開發人員水平的功能,哪怕是經驗豐富的資深開發工程師也極容易死鎖和 OOM,甚至因此導致整個專案的失敗 。
-
舉例一:你做 im,你要做群組與群員關係對映吧?在t-io中,您只需要Tio.bindGroup()即可完成tcp連線和這個群組關係的繫結
-
舉例二:點對點訊息,你要針對使用者 id發訊息吧?在t-io中,您只需要Tio.bindUser()即可完成tcp連線和user的關係繫結
-
透過 Tio.bindXxx()繫結的業務資源,不用擔心TCP連線斷開後資源釋放不掉,t-io擁有嚴格的演算法保證這些資源得到快速有序地釋放(不得不提醒:釋放資源涉及到多執行緒操作,極易出錯)!
netty有大量書籍可供查閱;t-io提供了擁有即戰力的showcase工程( 付費文件使用者可下載最新版 ),使用者並不需要太多時間即可完成可用於生產專案的網路程式設計腳手架
t-io和netty的程式設計模型和API差異極大
-
t-io的API設計更多的是讓工程師用起來舒服,所以特意增加了一個Tio.java,專門放置常用的API,這樣使用者找起來就非常方便,不用滿大街找方法呼叫
-
netty的部分API是把設計模式暴露出來了,讓內行人一看就知道這是個什麼設計模式做的
在效能測試上的差異
-
在 TFB平臺上,netty的效能遠超t-io,當然t-io的效能排名依然十分靠前,排在t-io後面的大有人在(t-io現在的效能比剛出來時的t-io差了很多,因為業務資料管理能力、阻塞傳送能力、同步傳送能力、流量監控與回撥,是比較消耗效能的),請參考:TFB效能PK平臺
-
帶上業務進行 PK時,t-io效能經常優於netty, 這其中的原因大概就是:用 netty需要自己寫程式碼完成業務資料的管理、流量監控等工作,而這些工作拖了裸netty的後腿,而這些工作已經被t-io內建了,所以給t-io帶來的效能損耗就很有限,請參考 netty和t-io對比測試結果
t-io提供了極其便捷的 阻塞傳送、同步傳送 ,這些能力在 netty中貌似沒有,需要使用者寫較多的程式碼才能實現
-
阻塞傳送: 訊息傳送到對方後,才往下執行程式碼
-
同步傳送: 對方收到訊息,並回了同樣的 synSeq訊息,才往下執行程式碼
易學程度: 從市場反饋來看, t-io設計的概念似乎更容易被工程師們所理解與接受,2014年老闆想讓我用netty,所以簡單地看過《netty權威指南》,這本書是我放棄netty的最後一根稻草,真的看不太懂,提供的示例我很難將其用在生產專案中(真實感受,當然也許是我太菜,我另一個非常優秀且年輕的同事也看過這本書,同樣表示雲裡霧裡)
不少使用者在抉擇時,覺得 t-io文件沒有netty多,轉而投netty,實際上,一個好框架,並不需要太多的文件,t-io在剛出來時,只有幾個showcase工程,第一批t-io使用者用這些showcase就完成了自己的專案,並且口碑迅速散開。現在t-io官方已經提供了相對完整的文件,再配上含金量十足的showcase工程,使用t-io已經很容易了
如果曾經使用過 netty或mina,再來使用t-io,也許你會感覺到前所未有的爽!
具體請參考:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70006579/viewspace-2794727/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 聊聊TCP Keepalive、Netty和DockerTCPNettyDocker
- UDP和TCP的差異UDPTCP
- 聊聊netty的maxDirectMemoryNetty
- 線上json差異比較工具--遞迴比較兩個json的節點和值的差異,並支援差異數預覽和逐個檢視差異JSON遞迴
- Akka 和 Storm 的設計差異ORM
- Oracle中exists和in的效能差異Oracle
- 聊聊reactor-netty的AccessLogReactNetty
- Bootstrap和Tailwind CSS之間的差異?bootAICSS
- mac和windows執行maven命令的差異MacWindowsMaven
- 談談 mysql和oracle的使用感受 -- 差異MySqlOracle
- 工作流和BPM之間的差異
- MariaDB 和 GreatSQL 效能差異背後的真相SQL
- Linux和Windows的差異?0基礎需知!LinuxWindows
- IRequiresSessionState和IReadOnlySessionState應用上的一些差異UISession
- [譯]React函式元件和類元件的差異React函式元件
- Spark和Hadoop之間的主要技術差異和選擇SparkHadoop
- 聊聊reactor-netty的PoolResources的兩種模式ReactNetty模式
- IaC 管理新思路:Walrus 和 Terraform 的差異化探索ORM
- 詳解爬蟲與RPA的工作原理和差異爬蟲
- 想不到WhaleStudio和Talend的差異竟如此之大!
- python:dis包中dis()和Bytecode()函式的差異Python函式
- Linux系統中Ubuntu和Redhat的差異有哪些?LinuxUbuntuRedhat
- Standard ABAP Debugger 和 Classic ABAP Debugger 的實現差異
- 聊聊 Netty 那些事兒之 Reactor 在 Netty 中的實現(建立篇)NettyReact
- MySQL中myisam和innodb有什麼差異?MySql
- PostgreSQL與Oracle的sql差異SQLOracle
- 【譯】框架與庫的差異框架
- 企微SCRM和CRM系統的差異有哪些呢
- 【底層】 C++和C#的編譯方式差異 / AOT和JITC++C#編譯
- 瀏覽器極速模式和相容模式差異瀏覽器模式
- BeanPostProcessor 介面和@PostConstruct 在使用姿勢上差異BeanStruct
- list對比差異
- 示例解讀 Python 2 和 Python 3 之間的主要差異Python
- MySQL和PostgreSQL在多表連線演算法上的差異MySql演算法
- SAP 電商雲 Accelerator 和 Spartacus UI 的工作機制差異UI
- 如何打造差異化和個性化的夜遊專案
- CentOS/RHEL 7:Chrony vs NTP(ntpd和chronyd之間的差異)CentOS
- ISO27001:2013和ISO27001:2005的差異對比