《Netty实战NettyINACTION》pdf下载在线阅读，求百度网盘云资源

《Netty实战》（诺曼·毛瑞尔（Norman Maurer））电子书网盘下载免费在线阅读

资源链接：

链接：https://panbaiducom/s/1I_pRuzDQjR54_70rit_-7Q

书名：Netty实战

作者：诺曼·毛瑞尔（Norman Maurer）

译者：何品

豆瓣评分：75

出版社：人民邮电出版社

出版年份：2017-5-1

页数：276

内容简介：编辑推荐

- Netty之父”Trustin Lee作序推荐

- 阿里巴巴中间件高级技术专家为本书中文版作序推荐

- 系统而详细地介绍了Netty的各个方面并附带了即用型的优质示例

- 附带行业一线公司的案例研究

- 极实用的Netty技术书

无论是构建高性能的Web、游戏服务器、推送系统、RPC框架、消息中间件还是分布式大数据处理引擎，都离不开Netty，在整个行业中，Netty广泛而成功的应用，使其成为了Java高性能网络编程的卓绝框架。

Netty的现Tech Lead Norman在本书中循序渐进地讲解了Netty的各个关键部分，在看完本书后，你不但可以熟练地使用Netty来构建以上系统，并且还可以避免很多常见的陷阱。

无论是想要学习Spring 5 、Spark、Cassandra等这样的系统，还是通过学习Netty来构建自己的基于Java的高性能网络框架，或者是更加具体的高性能Web或者游戏服务器等，本书都将是你的超强拍档。

本书中文版基于Netty419做了修订，希望本书能够给你带来一个接近完美的阅读体验，并能帮到你。

内容提要

本书是为想要或者正在使用Java从事高性能网络编程的人而写的，循序渐进地介绍了Netty各个方面的内容。

本书共分为4个部分：第一部分详细地介绍Netty的相关概念以及核心组件，第二部分介绍自定义协议经常用到的编解码器，第三部分介绍Netty对于应用层高级协议的支持，会覆盖常见的协议及其在实践中的应用，第四部分是几个案例研究。此外，附录部分还会简单地介绍Maven，以及如何通过使用Maven编译和运行本书中的示例。

阅读本书不需要读者精通Java网络和并发编程。如果想要更加深入地理解本书背后的理念以及Netty源码本身，可以系统地学习一下Java网络编程、NIO、并发和异步编程以及相关的设计模式。

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。

作者简介：Norman Maurer，是苹果公司的资深软件工程师，同时也是Netty的核心开发人员。

Marvin Allen Wolfthal，是Dell Services的顾问，他使用Netty实现了多个任务关键型的企业系统。

何品，目前是淘宝的一名资深软件工程师，热爱网络、并发、异步相关的主题以及函数式编程，同时也是Netty、Akka等项目的贡献者，活跃于Scala社区，目前也在从事GraphQL相关的开发工作。

Java最强书单推荐抓紧学习

01、入门

《Java 核心技术卷 1》

《Head First Java》

《鸟哥的 Linux 私房菜》

为什么要学 Linux 呢因为在实际的开发工作中项目基本上都要部署到 Llilux 环境下。Windows作为服务器的很少，除了慢没别的原因。

假如能够提前掌握一些 Linux 基本操作的话，不仅简历上是加分项，工作中更能快人一步。

《Maven 实战》

《Git 权威指南》

02、进阶

《Java 编程思想》

《Java编程思想》这本书确实没得说，质量很高，但需要放在 Java 入门后再去读，这样才能真正地去理解思想。

《Netty 实战》

无论是构建高性能的 Web、游戏服务器、推送系统、RPC 框架、消息中间件还是分布式大数据处理引擎，都离不开Netty，在整个行业中，Netty 广泛而成功的应用，使其成为了 Java 高性能网络编程的卓绝框架。

《代码整洁之道》

软件的质量，不仅依赖于架构，更与代码质量息息相关。而代码的质量与其整洁度成正比关系，越整洁的代码，其质量毫无疑问的就会越高。

03、深入

《重构，改善既有代码的设计》

《重构，改善既有代码的设计》

《深入理解 Nginx》

《深入剖析 Tomcat》

《JDK 里的设计模式》

《深入浅出设计模式》

《设计模式之禅》

《Head First 设计模式》

《算法》

《大型网站系统与 Java 中间件实践》

《大型网站技术架构: 核心原理与案例分析》

《亿级流量网站架构核心技术》

04、学习方法

第一，善用搜索引擎。平常需要找资料，需要解决问题，如果自己一时半会没有方法的话，就去搜。

第二，学会提问。如果搜索引擎找不到答案的话，不要直接把问题抛到群里，抛给同事、领导，或者大牛，要先对问题梳理一下。

第三，善干总结和归纳。很多同学给我反馈，“二哥，怎么总是感觉记不住啊，学完就忘啊，有什么好的办法吗

C语言基础知识的方法:

了解数据结构和算法:C 语言是一种基础的编程语言，很多算法和数据结构都是通过 C 语言实现的。因此，学习数据结构和算法可以帮助加深对 C 语言的理解，并提高编程能力。

参加在线课程或培训班: 可以参加一些在线课程或培训班来系统地学习 C 语言的基础知识。例如在 Coursera、Udemy或者网易云课堂等平台上可以找到相关的课程。

学习示例代码:

阅读代码:首先需要仔细地阅读示例代码，了解代码的功能和实现方法。可以分析代码结构，查看变量和函数的命名规范、注释说明和代码格式等。

理解代码逻辑:在阅读代码的过程中，需要尝试理解代码的逻辑。可以通过画流程图或者思维导图来帮助理解代码的实现思路和算法。

实际运行代码:在阅读完示例代码之后，可以尝试将代码运行起来，并且对代码进行调试，了解代码的具体执行过程。可以通过调试器等工具来帮助理解代码的运行过程。

修改代码:尝试修改示例代码，添加新的功能或者改进原有的代码。通过修改代码来深入理解代码的实现思路和功能特性并且可以提高自己的编程能力。

参考其他资源:如果在阅读示例代码的过程中遇到了困难，可以通过查阅相关的资料来帮助理解。例如可以参考官方文档博客文章或者在线教程等。

1 应用在netty建连接的过程中做了耗时的事；

因此我先dump了应用的线程，看到一切正常，boss线程看起来非常空闲；

2 backlog太小；

首先问了下开发代码里有没有设置过backlog，开发告诉我没设置过，于是我翻了下netty的源码确认下默认值，看到backlog的默认值为读取自系统的/proc/sys/net/core/somaxconn，于是查了下系统的这个值，确认系统的这个值已经是调整过的，设置为了2048，然后确认了系统上的tcp_max_syn_backlog是4096，也就是最后work的会是2048（为什么是这样具体可见 这篇文章 ），也就是说应该是够的。

用ss -s观察连接的状况，看到的是synrecv是0，也印证了上面的不是backlog的问题。

到这一步就彻底傻眼了，不知道该用什么方法排查了，于是开始一堆的google，看到的各种说解决新建连接并发低的解决办法，除了调整backlog外，主要是以下两种：

1 关闭tcp_tw_recycle，尝试了（话说这里充分体现了”病急乱投医“的心态，其实我自己都不相信改这参数有用，但想着只是改下参数这种小代价的事，还是试试吧），没任何作用；

2 关闭window scaling ，也尝试了，一样没任何作用；

查到这个阶段觉得自己已经无法理解了，于是求助了厂内内核团队对网络这块比较精通的同学，然后又求助了“神”，“神“帮忙看了会后，说主要的问题是现在是每epollWait唤醒一次，只建了一个连接，这导致在大量新建连接请求并发的时候，效率不够高，因此我翻了下代码，发现我本机上看到的代码不是这样的，我本机上看到的netty代码在epollWait唤醒后，是会尝试一直去accept的，但这个应用使用的netty确实不是这样，于是查了下应用的jar包库，发现里面有两个版本的netty（一个是321Final，一个是363Final），321确实是每次epollWait后就处理一个，于是通知开发同学把321去掉，满心期待的认为应该是好了，等开发更新好了后，自己也确认了一次epollWait唤醒后会连续处理很多个建立连接的请求，但悲催的还是没解决问题，具体的netty在这块的改造感兴趣的同学可以看看NioServerSocketPipelineSink这个类（重点看select唤醒后）…

到这步，就彻底郁闷了，话说其实到这步的时候我已经被这个问题困扰了2天多了，于是只好继续google，发现又有提到打开syn cookies的建议，于是尝试了下，竟然真的work了，打开了这个参数后新建连接的并发请求轻松超过100+了。

到此以为已经解决了，但很快开发给我反馈，整个集群开启了这个参数后，连接确实是能建上了，但客户端出现了发了请求后，等不到任何响应的现象，当时还不确定服务器端到底有没有收到请求，于是只好又先关闭了这个参数（话说这个我到现在都不明白为什么这个参数打开后，会出现发请求没响应的现象，求高人解答）。

尽管还是没解决，但毕竟有进展，有的进展就是打开了syn cookies后连接就能建上，而syn cookies只有在backlog满了后才会生效，那也就是说还是backlog满了，从kern的日志也能确认syn cookies确实是work了，到这步就觉得诡异了，明明netty用的默认值就是somaxconn，而每秒新建40多个连接，且boss线程还很空闲的情况下显然不应该出现backlog满的现象，这个时候仔细看了下本机查看的netty代码，才发现我看的是netty 4的代码，而应用用的是netty 363，悲催，赶紧把netty 363的代码捞下来看了，才发现在363里backlog的默认值处理时不一样的，在363里默认值是50，不是netty写的默认值，是java本身，50那估计真的不一定够，于是就通知开发在代码里先强制设置下backlog为1000。

在开发改代码的过程中，还有一个怀疑点想确认，就是既然是backlog满了，为什么看到的synrecv会是0呢，于是再用netstat -na | grep [port] | grep SYN_RECV -c统计了下，结果发现值基本一直是64，java层面默认设置的是50，linux会将这个值调整为大于这个值的2的n次幂的值，那也就是64，好吧，看到这就彻底可以确定真的是因为backlog太小了造成的（只是话说我不明白为什么ss -s统计出来的synrecv会是0呢，求高人解答）。

等开发改完代码重新发布后，稍微增加了点引流测试了下，轻松支撑每秒200+，客户端建立连接后发请求获取响应也完全ok，问题到此宣告解决。

题外话: 这应用之所以会比较容易出现较多的synrecv，主要是因为手机网络通常是不太稳定的，另外一个原因是这种对外的都很容易带来攻击，而当时刚好这个应用前面的一个用来防syn flood的由于有bug临时关闭了，所以问题暴露的比较明显。

从这个折腾了4天的case的排查过程，大家可以看到其实如果一开始我仔细确认过应用用的netty版本和我本机看的代码是不一致的话，估计很快就会排查出原因就是backlog值太小造成的，所以说折腾了这么多天其实也是自己造成的，这个告诉自己，以后排查问题的时候一定要对出现问题的应用所在的环境更加清楚的确认。

ps: 最后再多啰嗦几句，从这个case还能看到的是netty的版本其实在细节上是一直在改进的，就像这个case里的不同版本的netty在处理连接事件唤醒上，还有backlog的默认值上，所以我一直很强调，对于需要存活很多年的软件而言，选择一个使用范围较广的开源软件是非常重要的，如果自己开发，也许短期能超越，但放到三年、五年这样的范围来看，通常是很难和开源软件去抗衡的（原因是商业公司没多少人会专注在一个领域做三五年的，而开源界这样的人实在是多，说实话，这种case看过太多），所以如果觉得你能做的比开源软件好，还不如去帮助已有的（当然，如果这个领域目前完全没有什么使用面较广的、靠谱的，那自己做一个开源是挺好的），软件的可持续发展能力（除非是一次性软件、做的玩的或就玩个一两年的）是非常非常重要的。

主要逻辑 ：

使用netty实现长连接，主要靠心跳来维持服务器端及客户端连接。

主要的实现逻辑如下：

服务器端 ：（HeartBeatRespHandler）

1， 服务器在网络空闲操作一定时间后，服务端失败心跳计数器加1。

2， 如果收到客户端的ping心跳包，则清零失败心跳计数器，如果连续n次未收到客户端的ping心跳包，则关闭链路，释放资源，等待客户端重连。

客户端 ：（HeartBeatReqHandler）

1， 客户端网络空闲在一定时间内没有进行写操作时，则发送一个ping心跳包。

2， 如果服务器端未在发送下一个心跳包之前回复pong心跳应答包，则失败心跳计数器加1。

3， 如果客户端连续发送n（此处根据具体业务进行定义）次ping心跳包，服务器端均未回复pong心跳应答包，则客户端断开连接，间隔一定时间进行重连操作，直至连接服务器成功。