Netty为什么这么火？

Netty已经有了成百上千的分布式中间件、各种开源项目以及各种商业项目的应用。例如火爆的Kafka、RocketMQ等消息中间件、火热的ElasticSearch开源搜索引擎、大数据处理Hadoop的RPC框架Avro、主流的分布式通信框架Dubbo，它们都使用了Netty。总之，使用Netty开发的项目，已经有点数不过来了……

Netty之所以受青睐，是因为Netty提供异步的、事件驱动的网络应用程序框架和工具。作为一个异步框架，Netty的所有IO操作都是异步非阻塞的，通过Future-Listener机制，用户可以方便地主动获取或者通过通知机制获得IO操作结果。与JDK原生NIO相比，Netty提供了相对十分简单易用的API，因而非常适合网络编程。Netty主要是基于NIO来实现的，在Netty中也可以提供阻塞IO的服务。Netty之所以这么火，与它的巨大优点是密不可分的，大致可以总结如下：

• API使用简单，开发门槛低。
• 功能强大，预置了多种编解码功能，支持多种主流协议。
• 定制能力强，可以通过ChannelHandler对通信框架进行灵活扩展。
• 性能高，与其他业界主流的NIO框架对比，Netty的综合性能最优。
• 成熟、稳定，Netty修复了已经发现的所有JDK NIO中的BUG，业务开发人员。
• 不需要再为NIO的BUG而烦恼。

高并发利器Redis

任何高并发的系统，不可或缺的就是缓存。Redis缓存目前已经成为缓存的事实标准！

分布式利器ZooKeeper

突破了单体瓶颈之后的高并发，就必须靠集群了，而集群的分布式架构和协调，一定少不了可靠的分布式协调工具，ZooKeeper就是目前极为重要的分布式协调工具！

 

今天为大家分享的就是字节跳动内部的近600页Netty+Redis+ZooKeeper笔记，一份综合性十分高的笔记，同时这份笔记也是为了解决字节跳动内部三高而产生的一份笔记！今天免费开源！（共12章节）

第1章高并发时代的必备技能

 

第2章高并发IO的底层原理

本章聚焦的主题：一是底层IO操作的两个阶段，二是最为基础的四种IO模型，三是操作系统对高并发的底层的支持。

四种IO模型，基本上概况了当前主要的IO处理模型，理论上来说，从阻塞IO到异步IO，越往后，阻塞越少，效率也越优。在这四种IO模型中，前三种属于同步IO，因为真正的IO操作都将阻塞应用线程。

只有最后一种异步IO模型，才是真正的异步IO模型，可惜目前Linux操作系统尚欠完善。不过，通过应用层优秀框架如Netty，同样能在IO多路复用模型的基础上，开发出具备支持高并发（如百万级以上的连接）的服务器端应用。

 

第3章Java NIO通信基础详解

高性能的Java通信，绝对离不开Java NIO技术，现在主流的技术框架或中间件服务器，都使用了Java NIO技术，譬如Tomcat、Jetty、Netty。学习和掌握NIO技术，已经不是一项加分技能，而是一项必备技能。不管是面试，还是实际开发，作为Java的“攻城狮”（工程师的谐音），都必须掌握NIO的原理和开发实践技能。

 

第4章鼎鼎大名的Reactor反应器模式

Reactor反应器模式是高性能网络编程在设计和架构层面的基础模式。为什么呢？只有彻底了解反应器的原理，才能真正构建好高性能的网络应用，才能轻松地学习和掌握Netty框架。同时，反应器模式也是BAT级别大公司必不可少的面试题。

 

第5章并发基础中的Future异步回调模式

随着高并发系统越来越多，异步回调模式也越来越重要。在Netty源代码中，大量地使用了异步回调技术，所以，在开始介绍Netty之前，开辟整整一章，非常详细地、由浅入深地为大家介绍了异步回调模式。

本章首先为大家介绍了Java的join合并线程时“闷葫芦式”的异步阻塞，然后介绍了Java的FutureTask阻塞式的获取异步任务结果，最后介绍了Guava和Netty的异步回调方式。

Guava和Netty的异步回调是非阻塞的，而Java的join、FutureTask都是阻塞的。

 

第6章Netty原理与基础

Netty的目标之一，是要使开发可以做到“快速和轻松”。除了做到“快速和轻松”的开发TCP/UDP等自定义协议的通信程序之外，Netty经过精心设计，还可以做到“快速和轻松”地开发应用层协议的程序，如FTP，SMTP，HTTP以及其他的传统应用层协议。

Netty的目标之二，是要做到高性能、高可扩展性。基于Java的NIO，Netty设计了一套优秀的Reactor反应器模式。后面会详细介绍Netty中反应器模式的实现。在基于Netty的反应器模式实现中的Channel（通道）、Handler（处理器）等基类，能快速扩展以覆盖不同协议、完成不同业务处理的大量应用类

 

第7章Decoder与Encoder重要组件

在Netty中，解码器有ByteToMessageDecoder和MessageToMessageDecoder两大基类。如果要从ByteBuf到POJO解码，则可继承ByteToMessageDecoder基类；如果要从某一种POJO到另一种POJO解码，则可继承MessageToMessageDecoder基类。

Netty提供了不少开箱即用的Decoder解码器，能满足很多解码的场景需求，几个比较基础的解码器如下：

• 固定长度数据包解码器——FixedLengthFrameDecoder。
• 行分割数据包解码器——LineBasedFrameDecoder。
• 自定义分隔符数据包解码器——DelimiterBasedFrameDecoder。
• 自定义长度数据包解码器——LengthFieldBasedFrameDecoder。

在Netty中的编码器有MessageToByteEncoder和MessageToMessageEncoder两大重要的基类。如果要从POJO到ByteBuf编码，则可继承MessageToByteEncoder基类；如果要从某一种POJO到另一种POJO编码，则可继承MessageToMessageEncoder基类

 

需要免费领取这份字节跳动内部近600页三高时代利器笔记的朋友麻烦帮忙转发一下这篇文章（为了让更多的人学习到这份笔记）+关注文末公众号获取！

第8章JSON和ProtoBuf序列化

ESTful进行远程交互的应用开发中使用得非常多。一般来说，在实际开发中使用较多的JSON开发包是阿里的FastJson、谷歌的Gson。

Protobuf格式是非直观的二进制序列化方式，效率比较高，主要用于高性能的通信开发。

 

第9章基于Netty的单体IM系统的开发实践

本章是Netty应用的综合实践篇：将综合使用前面学到的编码器、解码器、业务处理器等知识，完成一个聊天系统的设计和实现。

 

第10章ZooKeeper分布式协调

在分布式系统中，ZooKeeper是一个重要的协调工具。本章介绍了分布式命名服务、分布式锁的原理以及基于ZooKeeper的参考实现。

本章的那些实战案例，建议大家自己去动手掌握，无论是开始应用实际、还是大公司的面试，都是非常有用的。

 

第11章分布式缓存Redis

缓存是一个很简单的问题，为什么要用缓存？主要原因是数据库的查询比较耗时，而使用缓存能大大节省数据访问的时间。举个例子，假如表中有2千万个用户信息，在加载用户信息时，一次数据库查询大致的时间在数百毫秒级别。这仅仅是一次查询，如果是频繁多次的数据库查询，效率就会更低。

提升效率的通用做法是把数据加入缓存，每次加载数据之前，先去缓存中加载，如果为空，再去查询数据库并将数据加入缓存，这样可以大大提高数据访问的效率

 

第12章亿级高并发IM架构的开发实践

本章介绍了支撑亿级流量的高并发IM架构以及高并发架构下的技术选型。然后，集中介绍了Netty集群所涉及的分布式IM的命名服务、Worker集群的负载均衡、即时通信消息的路由和转发、分布式的在线用户统计等技术实现。

 

需要免费领取这份字节跳动内部近600页三高时代利器笔记的朋友麻烦帮忙转发一下这篇文章（为了让更多的人学习到这份笔记）+关注下方公众号获取！