소스 코드를보고 그물코와 바닥을 발견했을 때 전 Rocketmq는 조금 배울 수있는 방법은 실수에 대해 이야기 많은 온라인 블로그이 있고, 같은 대부분, 그들 중 대부분은 다른 사람의를 복사 추정된다. 오도하지 않기 위해, 나는 특별히 밖으로 정렬 후,이 공유는 "인 Netty 확실한 가이드",주의 깊게 읽고, 읽고, (LILIN 펭)를 마이크로 채널 펭 형제에게 샀다.
나는 원칙을 준수되었습니다 오히려, 쓰기 덜 쓰기, 또한 잘못된 지식을하지 않으려 고하지! 수 있도록하는 것은 젊은 세대를 해하지!
학생들를 다시 인쇄하고 싶 원래 링크를 표시했다. 감사합니다! 아주 그런 실수를 환영하는 동안, 나는 즉시 수정!
흔적
Netty3는 (3.X) 버전은 이전 버전입니다.
Netty4 (4.x의) 버전은 현재 유지 보수하고있다, 현재 공식 추천입니다. 버전 3.x에 비해 변화는 특히 API 상대적으로 크다.
Netty5 (5.x를가) 버전을 폐기, 공식 권장하지 않습니다!
공식 설명을 포기 Netty5 :
1. netty5 ForkJoinPool는 코드의 복잡성을 증가, 사용되지만, 크게 성능이 향상되지 않습니다
2. 여러 지점 코드 동기화 과중한 업무
3. 저자는 순간 시간의 새로운 버전을 출시하지 않는 것입니다 느낌
4. 릴리스 버전 이전에, 등등 EventExecutorChooser 노출 여부 등 exceptionCaught을 폐기 여부 등을 조사 더 많은 문제가 있습니다.
참조 : https://github.com/netty/netty/issues/4466
1. 기본 개념 인 Netty
의 Netty 비동기 NIO 프레임 워크로 TCP, UDP 및 파일 전송에 대한 지원을 제공하는 고성능, 비동기 이벤트 중심의 NIO 프레임 워크, 인 Netty 모든 IO 작업이 미래 리스너 메커니즘에 의해 비동기 비 차단은, 사용자가 쉽게 검색하거나 활성 IO 작업 결과 알림 메커니즘을 얻을 수 있습니다.
같은 광범위한 애플리케이션에 대한 액세스로 가장 인기있는 NIO 프레임 워크 인 Netty 인터넷 분야에서 빅 데이터는 분산 컴퓨팅, 게임 산업, 통신 산업으로서, 업계 선도적 인 오픈 소스 구성 요소 중 일부는 NIO 프레임 워크 인 Netty 건물을 기반으로합니다. 예를 들면 : 두보, RocketMQ, 하둡 브로처럼 불꽃.
등등 ByteBuf, 채널 및 안전하지 않은, ChannelPipeline 및 ChannelHandler, EventLoop 및 EventLoopGroup, 미래 및 코덱, 어떻게 패키지 TCP를 스틱 / 포장을 풀의 Netty가 해결 : 인 Netty 콘텐츠를 배울 수 있습니다.
코덱 :
자바 직렬화 두 가지 목적이 있습니다 :
- 네트워크 전송
- 개체 지속성
자바 자바 직렬화 하나 개의 코덱 기술로 인해 다양한 코덱 기술과 프레임에서 파생 된 자신의 단점,의.
자바 직렬화의 단점 :
- 교차 언어 없습니다
- 너무 직렬화 스트림
- 직렬화 성능이 너무 낮습니다
산업 주류 코덱 프레임 워크 :
- 구글 Protobuf : 자바, C ++, 파이썬 3 개 국어, 효율적인 코딩 성능을 지원, 구조화 된 데이터 저장 형식 (XML, JSON 등)
- 페이스 북 드리프트는 정적 데이터 교환을 위해, 우리는 좋은에게 데이터 구조를 결정해야합니다. 구조적인 변화는 드리프트의 약점 인 IDL 파일을 다시 컴파일해야 후.
- JBoss의 마샬링은 : 직렬화 API는 자바 객체 인 JDK는 패킷의 순서와 함께 제공됩니다 많은 문제를 해결하지만, java.io.Serializable을 인터페이스와 호환 남아있다.
- 헤센 : 도구 onhttp 경량의 원격, 간단한 방법으로는, RMI 기능을 제공하는 바이너리 RPC 프로토콜을 사용합니다.
TCP 스틱 패키지 / 개봉 :
TCP는 "흐름"계약, 소위 흐름이며, 데이터의 문자열에는 제한이 없습니다. 상기 서비스에 대한 전체 패키지가 송신 TCP 패킷을 복수로 분할 할 수 있도록 TCP가 있고, 실제 TCP 패킷 버퍼에 의하면, 분할 될 기본 상층 서비스 데이터의 구체적인 의미를 알지 못한다 복수의 패킷은 큰 패킷 전송으로 캡슐화하고,이 접착 문제를 언 패킹 TCP 패킷이다.
몇 가지 경우가 있습니다 :
일반적으로
스틱 패키지
그리고 동시에 풀고 패키지를 스틱
2.의 Netty 스레딩 모델
원자로 패턴에 자바 NIO 선택기 존중 기초, 인 Netty 조합 선택기 및 원자로 모델 설계 효율적인 스레딩 모델을 제공합니다.
차단 PPT가 Reator 모드가 설명 될 것이다 달성하기 위해 자바 NIO 건설 Reator 모드, 아주 좋은 박람회에서 "자바 확장 IO"의 더그 레아, 소개.
(1) 반응기 단일 스레드 모델
이는 비동기 비 차단 IO를, 모든 IO 작업이 차단되지 않습니다 이론적으로, 스레드가 독립적으로 처리 할 수있는 모든 IO 작업을 사용하여 원자로 패턴, 원자로 단일 스레드 모델의 간단합니다. 그리고 원자로 스레드 프로세싱 체인에 요청을 새 연결을 승인, 배포, 소켓을 역 다중화에 대한 책임, 다목적이다.
일부 소용량 시나리오의 경우, 단일 스레드 모델을 사용할 수 있습니다. 그러나 높은 부하, 대형 동시 응용 프로그램은 주로 다음에, 부적절 :
1. 쓰레드 NIO이없는 동시에 CPU 부하 NIO 스레드 100 % 완전히 메시지를 처리 할 수없는 경우에도, 링크 성능 수백지지 처리하면.
NIO 스레드가 과부하되는 경우 2. 처리 속도가 종종 더 무거운 부하 NIO 스레드 후 클라이언트 연결 시간 초과, 재전송 타임 아웃의 큰 숫자로 이어질 것입니다, 느려집니다.
3. 낮은 신뢰성, 스레드 루프의 예기치 않은 죽음은 전체 통신 시스템을 사용할 수없는 원인이됩니다.
이러한 문제를 해결하기 위해 원자로 멀티 스레딩 모델이되고있다.
(2) 반응기 다중 스레드 모델
모델, 멀티 스레드 체인 부분 (스레드 풀)의 처리에 이용되는 모델에 비해.
대부분의 경우, 모델은 성능 요구 사항을 충족 할 수 있습니다. 그러나, 악수 메시지 서버와 같은 특별한 상황에서 클라이언트의 보안을 인증합니다. 이러한 시나리오에서, 별도의 스레드 채택이 부족 성능 문제가있을 수 있습니다. 이러한 문제를 해결하기 위해 세 번째 원자로 스레딩 모델을 생성합니다.
마스터 모델 (3) 반응기
该模型相比第二种模型，是将Reactor分成两部分，mainReactor负责监听server socket，accept新连接；并将建立的socket分派给subReactor。subReactor负责多路分离已连接的socket，读写网络数据，对业务处理功能，其扔给worker线程池完成。通常，subReactor个数上可与CPU个数等同。
利用主从NIO线程模型，可以解决一个服务端监听线程无法有效处理所有客户端连接的性能不足问题，因此，在Netty的官方Demo中，推荐使用该线程模型。
(4)Netty模型
Netty的线程模型并不是一成不变，它实际取决于用户的启动参数配置。通过设置不同的启动参数，Netty可以同时支持Reactor单线程模型、多线程模型和主从模型。
前面介绍完 Netty 相关一些理论，下面从功能特性、模块组件来介绍 Netty 的架构设计。
3. Netty功能特性
下图是Netty的功能特性：
4. Netty模块组件
Netty主要有下面一些组件：
- Selector
- NioEventLoop
- NioEventLoopGroup
- ChannelHandler
- ChannelHandlerContext
- ChannelPipeline
Selector
Netty 基于 Selector 对象实现 I/O 多路复用，通过 Selector 一个线程可以监听多个连接的 Channel 事件。
NioEventLoop
其中维护了一个线程和任务队列，支持异步提交执行任务，线程启动时会调用 NioEventLoop 的 run 方法，执行 I/O 任务和非 I/O 任务。
NioEventLoopGroup
主要管理 eventLoop 的生命周期，可以理解为一个线程池，内部维护了一组线程，每个线程(NioEventLoop)负责处理多个 Channel 上的事件，而一个 Channel 只对应于一个线程。
ChannelHandler
是一个接口，处理 I/O 事件或拦截 I/O 操作，并将其转发到其 ChannelPipeline(业务处理链)中的下一个处理程序。
ChannelHandlerContext
保存 Channel 相关的所有上下文信息，同时关联一个 ChannelHandler 对象。
ChannelPipeline 是保存 ChannelHandler 的 List，用于处理或拦截 Channel 的入站事件和出站操作。实现了一种高级形式的拦截过滤器模式，使用户可以完全控制事件的处理方式，以及 Channel 中各个的 ChannelHandler 如何相互交互。
ChannelPipeline对事件流的拦截和处理流程：
Netty中的事件分为Inbond事件和Outbound事件。
Inbound事件通常由I/O线程触发，如TCP链路建立事件、链路关闭事件、读事件、异常通知事件等。
Outbound事件通常是用户主动发起的网络I/O操作，如用户发起的连接操作、绑定操作、消息发送等。
在 Netty中，Channel 、ChannelHandler、ChannelHandlerContext、 ChannelPipeline的关系如下图：
一个 Channel 包含了一个 ChannelPipeline，而 ChannelPipeline 中又维护了一个由 ChannelHandlerContext 组成的双向链表，并且每个 ChannelHandlerContext 中又关联着一个 ChannelHandler。
入站事件和出站事件在一个双向链表中，入站事件会从链表 head 往后传递到最后一个入站的 handler，出站事件会从链表 tail 往前传递到最前一个出站的 handler，两种类型的 handler 互不干扰。
以上是Netty的主要原理介绍，Netty源码分析的话，后续有时间会继续分享出来。