本书是为想要或者正在使用Java从事高性能网络编程的人而写的,循序渐进地介绍了Netty各个方面的内容。
阅读全文
‘ Netty ’ 目录归档
基于一致性哈希的分布式内存键值存储——CHKV
Consistent Hashing based Key-Value Memory Storage
基于一致性哈希的分布式内存键值存储——CHKV。
系统设计
- NameNode : 维护key与节点的映射关系(Hash环),用心跳检测DataNode(一般被动,被动失效时主动询问三次),节点增减等系统信息变化时调整数据并通知Client;
- DataNode : 存储具体的数据,向NameNode主动发起心跳并采用请求响应的方式来实现上下线,便于NameNode挪动数据
- Client : 负责向NameNode请求DataNode数据和Hash算法等系统信息并监听其变化,操纵数据时直接向对应DataNode发起请求就行,暂时只包含set,get,delete三个操作
《Netty 实战》Netty In Action中文版 第2章——你的第一款Netty应用程序
《Netty实战》样章由人民邮电出版社授权并发编程网发布,本书的中文版已经由人民邮电出版社引进并出版。
京东预售链接(优先发货):《Netty实战》([美]诺曼·毛瑞尔(Norman Maurer),马文·艾伦·沃尔夫泰尔(Marvin Allen Wolfthal))
第2章 你的第一款Netty应用程序
本章主要内容
- 设置开发环境
- 编写Echo服务器和客户端
- 构建并测试应用程序
《Netty实战》Netty In Action中文版——文前内容
《Netty实战》样章由人民邮电出版社授权并发编程网发布,本书的中文版已经由人民邮电出版社引进并出版。
京东预售链接(优先发货):《Netty实战》([美]诺曼·毛瑞尔(Norman Maurer),马文·艾伦·沃尔夫泰尔(Marvin Allen Wolfthal))
内容提要
《Netty实战》Netty In Action中文版 第1章——Netty——异步和事件驱动
《Netty实战》样章由人民邮电出版社授权并发编程网发布,本书的中文版已经由人民邮电出版社引进并出版。
京东预售链接(优先发货):《Netty实战》([美]诺曼·毛瑞尔(Norman Maurer),马文·艾伦·沃尔夫泰尔(Marvin Allen Wolfthal))
Netty框架中的@Skip使用说明
最近在学习Netty框架,对着教程上写了个简单的netty应用,可是死活调试不成功,对着程序跟教程上看了几遍也找不到原因,后来又重新写了一遍,服务端程序终于调试成功,原因出在了那个@Skip注释上了,代码如下:
阅读全文
Netty源码注释翻译-Channel类
定义为一个通往网络socket或者一个由I/O读写能力的组件。
通道提供:
1,通道的当前状态,打开?已连接?
2,跟通道关联的配置信息ChannelConfig,包括buffer大小等。
3,通道支持的I/O操作,如读、写、连接、绑定等。
4,跟通道关联的ChannelPipeline,用来处理通道的I/O事件和请求。
Netty 5用户指南
原文地址:http://netty.io/wiki/user-guide-for-5.x.html 译者:光辉勇士 校对:郭蕾
前言
问题
现如今我们使用通用的应用程序或者类库来实现系统之间地互相访问,比如我们经常使用一个HTTP客户端来从web服务器上获取信息,或者通过web service来执行一个远程的调用。
然而,有时候一个通用的协议和他的实现并没有覆盖一些场景。比如我们无法使用一个通用的HTTP服务器来处理大文件、电子邮件、近实时消息比如财务信息和多人游戏数据。我们需要一个合适的协议来处理一些特殊的场景。例如你可以实现一个优化的Ajax的聊天应用、媒体流传输或者是大文件传输的HTTP服务器,你甚至可以自己设计和实现一个新的协议来准确地实现你的需求。
《Netty 权威指南》—— 选择Netty的理由
声明:本文是《Netty 权威指南》的样章,感谢博文视点授权并发编程网站发布样章,禁止以任何形式转载此文。
在开始本节之前,我先讲一个亲身经历的故事:曾经有两个项目组同时用到了NIO编程技术,一个项目组选择自己开发NIO服务端,直接使用JDK原生的API,结果2个多月过去了,他们的NIO服务端始终无法稳定,问题频出。由于NIO通信是它们的核心组件之一,因此,项目的进度受到了严重的影响,领导对此非常恼火。另一个项目组直接使用Netty作为NIO服务端,业务的定制开发工作量非常小,测试表明,功能和性能都完全达标,项目组几乎没有在NIO服务端上花费额外的时间和精力,项目进展也非常顺利。
这两个项目组的不同遭遇提醒我们:开发出高质量的NIO程序并不是一件简单的事情,除去NIO固有的复杂性和BUG不谈,作为一个NIO服务端需要能够处理网络的闪断、客户端的重复接入、客户端的安全认证、消息的编解码、半包读写等等,如果你没有足够的NIO编程经验积累,一个NIO框架的稳定往往需要半年甚至更长的时间。更为糟糕的是一旦在生产环境中发生问题,往往会导致跨节点的服务调用中断,严重的可能会导致整个集群环境都不可用,需要重启服务器,这种非正常停机会带来巨大的损失。
从可维护性角度看,由于NIO采用了异步非阻塞编程模型,而且是一个IO线程处理多条链路,它的调试和跟踪非常麻烦,特别是生产环境中的问题,我们无法有效调试和跟踪,往往只能靠一些日志来辅助分析,定位难度很大。