Netty

写在最前面 移动时代、5G时代、物联网时代的大幕已经开启，它们对于高性能、高并发的开发知识和技术的要求，抬升了Java工程师的学习台阶和面试门槛。大公司的面试题从某个侧面映射出生产场景中对专项技术的要求。高并发的面试题以前基本是BAT等大公司的专利，现在几乎蔓延至与Java项目相关的整个行业。例如，与Java NIO、Reactor模式、 高性能通信、分布式锁、分布式ID、分布式缓存、高并发架构等技术相关的面试题，从以前的加分题变成了现在的基础题，这也映射出开发Java项目所必需的技术栈:分布式Java框架、Redis缓存、分布式搜索ElasticSearch、分布式协调ZooKeeper、消息队列Kafka、高性能通信框架Netty。 今天分享的这份笔记虽然重在讲解Netty、Redis、 ZooKeeper的使用方法，但是还有一个更大的价值，就是为大家打下Java高并发开发技术的坚实基础。 首先，从操作系统的底层原理开始讲解:浅显易懂地剖析高并发IO的底层原理，并介绍如何让单体Java应用支持百万级的高并发:从传统的阻塞式OIO开始，细致地解析Reactor高性能模式，介绍高性能网络开发的基础知识:从Java的线程Join和线程池开始，介绍Java Future和Guava ListenableFuture两种常用异步回调技术。这些原理方面的基础知识非常重要

Netty解决粘包和拆包问题的四种方案 参考文章： （1）Netty解决粘包和拆包问题的四种方案 （2）https://www.cnblogs.com/AIPAOJIAO/p/10631551.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4428122/blog/4657902

目前的话，已经把 Spring MVC 相关常用的注解比如 @GetMapping 、 @PostMapping 、 @PathVariable 写完了。我也已经将项目开源出来了，地址： https://github.com/Snailclimb/jsoncat 。 原创开源不易，觉得不错的话，欢迎给良心作者 1 个 star 鼓励一下！ 今天是晴天，我像往常一样坐在窗台，看着电脑“发呆”。毕竟是周末，就不分享技术干货了。 简单和小伙伴们聊聊自己最近正在做，已经开始做的事情。 01 重构 JavaGuide 我们经常会对自己早期写的代码感觉恶心，这是导致很多项目烂尾、不好维护很重要的一个原因之一。 写作也是一样，我也经常觉得自己早期写的文章像一坨翔。造成这个现象的原因很简单！我觉得主要可能有两方面原因： 自己沉淀的知识更多，对于某个知识点的理解更加深刻。 不同于其他类型文章，技术类文章本身就需要不断完善，文章内容才会更好。 所以，最近几个月我一直抽空对 JavaGuide 上早期的一些文章进行大篇幅重构，比如 Java基础、Java集合框架、 Zookeeper 、Redis等等。 毕竟，时间有限，自己也还是把主要精力放在写代码上。所以，部分文章还没有开始重构，比如数据结构部分的内容。 就非常期待小伙伴们一起贡献出自己的力量啊！让 Guide哥 能多点时间写代码，嘿嘿！ 02

大家好，我是 「后端技术进阶」 作者，一个热爱技术的少年。 文章目录 还是要从 BIO 说起 传统的阻塞式通信流程 一个简单的 demo 资源消耗严重的问题 线程池虽可以改善，但终究未从根本解决问题 再看 NIO 初识 NIO NIO 核心组件解读 NIO 为啥更好？ 使用 NIO 编写代码太难了 重要角色 Netty 登场 Netty 特点 使用 Netty 能做什么？ 哪些开源项目用到了 Netty？ 后记 觉得不错的话，欢迎 star！ღ( ´･ᴗ･` )比心 Netty 从入门到实战系列文章地址： https://github.com/Snailclimb/netty-practical-tutorial 。 RPC 框架源码地址： https://github.com/Snailclimb/guide-rpc-framework 老套路，学习某一门技术或者框架的时候，第一步当然是要了解下面这几样东西。 是什么？ 有哪些特点？ 有哪些应用场景？ 有哪些成功使用的案例？ … 为了让你更好地了解 Netty 以及它诞生的原因，先从传统的网络编程说起吧！ 还是要从 BIO 说起 传统的阻塞式通信流程 早期的 Java 网络相关的 API( java.net 包) 使用 Socket(套接字)进行网络通信，不过只支持阻塞函数使用。 要通过互联网进行通信，至少需要一对套接字：

用了io这么久，有没有真正的理解了，比如BIO、NIO、AIO是什么，能够在什么场景用到？ BIO是同步阻塞IO，就是传统io，处理方式简单，一次只能读取一个字节流,并发能力低。同步非阻塞，就是咱们干一件事情，比如排队买面包，在买面包的过程中，不能做其他的事情，买完之后才能离开。可以使用在并发要求不高的服务中，但程序简单直观。 NIO是同步非阻塞io，是传统io的升级，客户端和服务端通过Channel通讯，实现了多路复用的情况。同步非阻塞，就是咱们干一件事情，比如排队买面包，在买面包的过程中，通过买票等待，等待的过程中还可以干其他的事情，但是不能离开买面包的地方。可以应用在聊天服务器，多个线程并发短连接的场景，成熟框架netty，使用netty框架解决了jdk的nio空轮询的问题. AIO是异步非阻塞io，是NIO的升级，也叫NIO2,异步的io操作是基于事件和回调机制，可以使用在多线程长连接的创建，比如相册服务器，服务段了，会有一个长连接不断轮询，进行信息同步。 来源： oschina 链接： https://my.oschina.net/u/4412708/blog/4557599

冰眼冷链物流监控平台学习总结 采用的的主要技术有： netty、springboot、springcloud、 kafka、flink、redis、druid/ vue等 资料： https://pan.baidu.com/s/1KZf1Gj4-UGleJjWiLfStSw 提取码：8wyv 解决方案： 监控部分采用分布式微服务架构，同时针对海量物联网数据的统计和查询引入了专门的解决方案。 基于物联网及大数据实时计算技术.... 来源： oschina 链接： https://my.oschina.net/u/4351890/blog/4626607

大家好，我是本期 SOFAChannel 的分享讲师丞一，来自蚂蚁集团，是 SOFABolt 的开源负责人。今天我们来聊一下蚂蚁集团开源的网络通信框架 SOFABolt 的框架解析以及功能介绍。本期分享将从以下四个方面展开： SOFABolt 简介； 基础通信能力解析； 协议框架解析； 私有协议实现解析； SOFABolt 是什么 SOFABolt 产生背景 相信大家都知道 SOFAStack，SOFAStack(Scalable Open Financial Architecture Stack)是一套用于快速构建金融级云原生架构的中间件，也是在金融场景里锤炼出来的最佳实践。 SOFABolt 则是 SOFAStack 中的网络通信框架，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架，他的名字 Bolt 取自迪士尼动画《闪电狗》。他一开始是怎么在蚂蚁集团内部产生的，我们可以类比一下 Netty 的产生原因： 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生； 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生； 这些年，在微服务与消息中间件在网络通信上，蚂蚁集团解决过很多问题

2018 年 3 月 1 号 Spring Boot 2.0.0.RELEASE 正式发布，这是 Spring Boot 1.0 发布 4 年之后第一次重大修订，因此有多新功能和特性值得关注！在 Spring Boot 官方博客中我们了解到：Spring Boot 2.0 版本经历了 17 个月的开发，有 215 个不同的使用者提供了超过 6800 次的提交。 我们将 Spring Boot 2.0 更新的技术分为三类进行解读： 第一类，基础环境升级； 第二类，默认软件替换和优化； 第三类，新技术的引入。 基础环境升级 最低 JDK 8，支持 JDK 9，不再支持 Java 6 和 7 Spring Boot 2.0 要求 Java 8 作为最低版本，许多现有的 API 已更新，以利用 Java 8 的特性。例如，接口上的默认方法，函数回调以及新的 API，如 javax.time。如果你正在使用 Java 7 或更早版本，则在开发 Spring Boot 2.0 应用程序之前，需要升级你的 JDK。 Spring Boot 2.0 通过测试可以在 JDK 9 下正常运行，同时 Spring Boot 2.0 宣布不再支持 Java 6 和 7，据我了解国内绝大部分互联网公司的基本环境还在 JDK 7 或者 6 环境下运行，考虑升级 Spring Boot 2.0

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </exclusion> </exclusions> </dependency> <!-- Jetty as container--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jetty</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-webflux</artifactId> </dependency> 以上依赖就是将默认的tomcat切换为jetty容器 还可以切换为undertow <dependency>

今天我们继续来讨论协议，今天基本就把一对一聊天的协议定制完毕了，上一篇我们讲述了登录的过程，那么登录完毕就是聊天了，首先我们还是以A和B为例子，A发送消息给B，那么这条消息的的协议如下 发送消息协议： {"id":"xxxx","#":"msg","text":"内容","to":"接收用户ID","type":0,"msgid":"消息ID" ｝ id:客户端生成的ID #:不说了，我们之前说过，是对应服务器端的Handler text:消息内容 to:表示发送给谁 type：表示消息类型 msgid：表示消息的ID 肯定有很多人之后看到之后会有一个问题，我们到底需不需要from 也就是说发送者是谁，其实在这里加上也行，但是其实是不需要的，因为如果既然这个人可以发送消息，那么我们可以在这个人对应的回话里边去存储这个人的信息，所以说只要发送消息，服务器就知道这条消息来自谁，故不需要在这里加from，然后服务器端要响应给该用户是否发送成功，返回的协议，我们在上一篇 auth那里讲述了，用同一个就好了，那么现在服务器如果发现B在线该去通知B来收消息了，那么我们看一下服务器通知B的协议 服务器通知B的协议： {"id":"xxxx","#":"psh"} id：服务器生成的id #：我们这里用了一个psh表示，通知该用户你有新的消息，要获取了，那么B解析到