从一次netty分享漫谈

1.前言

上周五,笔者所在的开发小组,组织了一场分享,内容是netty的入门。笔者所在的团队,基本上就是在各条业务线中活蹦乱跳,有经验的看官,到这里已经可以给出分享效果的总体预测:“上次面试完就不记得了”;“好像用过,记不起来”;“这图有点复杂”。。。
所以,今天本博客有了第三篇netty入门

2. 高质量的分享可能长这样

从前言的吐槽,可以感受,分享的效果大概率就是呵呵;绝大部分开发同学上台开讲,多少都会有这味道,why?
主观臆断原因1:真正有壁垒,有内容的部分,分享的时长不足以完全掰碎讲明白;
主观臆断原因2:开发同学大部分情商偏低,基本上组织文档,以自己能提供啥为导向,不以效果为导向。

笔者倾向的高质量分享:
1 以听众为中心梳理内容、结构;在自洽之余,帮助听众,构建该知识点的知识地图/建立索引;
2 难度和门槛,要和听众能力相对匹配(给一年级上6年纪的,那是学而思)
3 控制篇幅,仅对一两个核心点拆解掰碎

3. netty知识地图

笔者尝试结构化netty相关知识,从是什么,怎么运行,能干啥几个角度看netty

netty是什么

Netty 是由 JBOSS 提供的一个 Java 开源框架,现为 Github上的独立项目。

Netty 是一个 异步的、基于事件驱动 的 网络应用框架,用以快速开发高性能、高可靠性的 网络 IO 程序。相当于简化和流程化了 NIO 的开发过程。

Netty主要针对在 TCP协议下,面向Clients端的高并发应用,或者Peer-to-Peer场景下的 大量数据持续传输 的应用。
从一次netty分享漫谈_第1张图片
Netty本质是一个 NIO框架,适用于 服务器通讯 相关的多种应用场景。

netty怎么运行-线程模型

于框架而言,线程模型是重中之重,线程模型图一出,系统如何work则一目了然。

Reactor 模式

Reactor模式 是一种「事件驱动」模式。

「Reactor线程模型」就是通过 单个线程 使用Java NIO包中的Selector的select()方法,进行监听。当获取到事件(如accept、read等)后,就会分配(dispatch)事件进行相应的事件处理(handle)。

基于 I/O 复用模型:多个连接共用一个阻塞对象,应用程序只需要在一个阻塞对象等待,无需阻塞等待所有连接。当某个连接有新的数据可以处理时,操作系统通知应用程序,线程从阻塞状态返回,开始进行业务处理

基于线程池复用线程资源:不必再为每个连接创建线程,将连接完成后的业务处理任务分配给线程进行处理,一个线程可以处理多个连接的业务。
Reactor 模式使用 IO复用 监听事件,收到事件后,分发给某个线程(进程),这点就是网络服务器高并发处理关键
从一次netty分享漫谈_第2张图片
Reactor:Reactor 在一个单独的线程中运行,负责监听和分发事件,分发给适当的处理程序来对 IO 事件做出反应。 它就像公司的电话接线员,它接听来自客户的电话并将线路转移到适当的联系人;

Handlers:处理程序执行 I/O 事件要完成的实际事件,类似于客户想要与之交谈的公司中的实际官员。Reactor 通过调度适当的处理程序来响应 I/O 事件,处理程序执行非阻塞操作。

单 Reactor 单线程

代表选手:redis
从一次netty分享漫谈_第3张图片

单 Reactor 多线程

从一次netty分享漫谈_第4张图片

主从 Reactor 多线程

从一次netty分享漫谈_第5张图片
Netty 主要基于 主从 Reactors 多线程模型 做了一定的 改进,其中主从 Reactor 多线程模型有多个 Reactor。

相关知识点

  • 零拷贝
  • BIO,NIO,AIO

netty能干啥

  • Http的server和client
  • Websocket的server和client
  • RPC框架

4. 总结

1 开发同学通常过于在意自己能输出啥,思路偏向供给;实际工作中,我们更多的是协作,协作必然要在意相关利益方的诉求,即需求侧;两者之间要达到平衡,才能实现最大价值。
2 换个角度看,分享也是一次项目,花费了团队参会者人均1小时,+分享者N个小时的准备时间,要达到该项目的最大价值,组织者需要考虑,如何让参会者所有人的利益最大化(涉众利益)

参考:https://www.51cto.com/article/666816.html
参考:https://lish98.blog.csdn.net/article/details/124232377

你可能感兴趣的:(java,经验分享)