登录
首页 >  数据库 >  MySQL

聊聊t-io和netty的差异

来源:SegmentFault

时间:2023-02-24 10:03:52 298浏览 收藏

编程并不是一个机械性的工作,而是需要有思考,有创新的工作,语法是固定的,但解决问题的思路则是依靠人的思维,这就需要我们坚持学习和更新自己的知识。今天golang学习网就整理分享《聊聊t-io和netty的差异》,文章讲解的知识点主要包括MySQL、Java、数据库、html5、android,如果你对数据库方面的知识点感兴趣,就不要错过golang学习网,在这可以对大家的知识积累有所帮助,助力开发能力的提升。

引言
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,也许你会感觉到前所未有的爽!
具体请参考: https://www.tiocloud.com/doc/...

到这里,我们也就讲完了《聊聊t-io和netty的差异》的内容了。个人认为,基础知识的学习和巩固,是为了更好的将其运用到项目中,欢迎关注golang学习网公众号,带你了解更多关于mysql的知识点!

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表