Netty

现在我们已经基本了解了netty底层使用的组件，就明白了netty为什么是事件驱动模型：(netty极简教程（四）： netty极简教程（五）：Netty的Reactor模型演进及JDK nio聊天室实现 ， 接下来追踪下netty的启动源码，验证reactor模型在netty的实现 示例源码： https://github.com/jsbintask22/netty-learning 示例 我们以第一节打印客户端信息的代码为例： NioEventLoopGroup bossLoopGroup = new NioEventLoopGroup ( 1 ) ; // 1 NioEventLoopGroup workLoopGroup = new NioEventLoopGroup ( ) ; // 2 try { ServerBootstrap serverBootstrap = new ServerBootstrap ( ) ; serverBootstrap . group ( bossLoopGroup , workLoopGroup ) . channel ( NioServerSocketChannel . class ) // 3 . childHandler ( new ChannelInitializer < SocketChannel > ( ) {

cloud全家桶中有个很重要的组件就是网关，在1.x版本中都是采用的Zuul网关；但在2.x版本中，zuul的升级一直跳票，springcloud最后自己研发了一个网关代替Zuul，那就是SpringCloud Gateway。 概述 gateway是在spring生态系统之上构建的API网关服务，基于Spring 5, Spring Boot 2和Project Reactor等技术。gateway旨在提供一种简单而有效的方式来对API进行路由，以及提供一些强大的过滤器功能，例如：熔断、限流、重试等。 SpringCLoud Gateway 使用的Webflux中的reactor-netty响应式编程组件，底层使用了Netty通讯框架。 作用 • 反向代理 • 鉴权 • 流量控制 • 熔断 • 日志监控 微服务架构中网关的位置 特性 • 基于spring Framework 5, Project Reactor 和 spring boot 2.0 进行构建； • 动态路由：能够匹配任何请求属性； • 可以对路由指定 Predicate（断言） 和 Filter（过滤器）； • 集成Hystrix的断路器功能； • 集成SPringCloud服务发现功能； • 易于编写的 Predicate（断言） 和 Filter（过滤器）； • 请求限流功能； • 支持路径重写。

JAVA互联网架构师专题/分布式/高并发/微服务【第三期】 下载地址： 百度云盘 全新打造60W年薪架构师课程，4年磨一剑，10次课程升级改版 课程内容涉及Java互联网一线大厂技术、源码框架 性能调优 （Tomcat Nginx JVM） 分布式框架（并发编程 Zookeeper Netty dubbo Redis） 微服务框架（ Spring Cloud Docker虚拟化 微服务架构 ） 章节目录 J AVA架构课开班典礼 【录播】致新加入同学的学习计划-诸葛(34分钟) 【回放】IOC容器设计理念与核心注解的使用(6月5日 20:10-22:00) 源码框架专题 【回放】Spring Ioc容器源码解析(上)(6月12日 20:10-22:00) 【回放】Spring Ioc容器源码解析(下)(6月14日 20:10-22:00) 【回放】Spring Ioc容器解决循坏依赖(6月16日 20:10-22:00) 【回放】Spring AOP 源码深度解析（一）(6月19日 20:10-22:00) 【回放】Spring AOP 源码深度解析（二）(6月21日 20:10-22:00) 【回放】Spring事务管理源码深度解析(6月23日 20:10-22:00) 【回放】Spring 5新特性剖析(6月26日 20:10-22:00) 源码框架专题 【回放

引言 作者：黄青石 链接： https://www.cnblogs.com/huangqingshi/p/13336648.html?utm_source=tuicool&utm_medium=referral 周末了，觉得我还有很多作业没有写，针对目前大家对OOM的类型不太熟悉，那么我们来总结一下各种OOM出现的情况以及解决方法。 　　我们把各种OOM的情况列出来，然后逐一进行代码编写复现和提供解决方法。 　　1. 堆溢出-java.lang.OutOfMemoryError: Java heap space。 　　2. 栈溢出-java.lang.OutOfMemorryError。 　　3. 栈溢出-java.lang.StackOverFlowError。 　　4. 元信息溢出-java.lang.OutOfMemoryError: Metaspace。 　　5. 直接内存溢出-java.lang.OutOfMemoryError: Direct buffer memory。 　　6. GC超限-java.lang.OutOfMemoryError: GC overhead limit exceeded。 　　 第一种 ，堆溢出异常，相信大家很常见。即堆内对象不能进行回收了，堆内存持续增大，这样达到了堆内存的最大值，数据满了，所以就出来了。我们直接放溢出的代码样例

首先技术实力可以分为两层 ： 对技术知识和框架本身的掌握程度，比如你熟悉redis、memcached等的用法。 运用技术知识和框架解决实际问题的能力。 很多人觉得，我熟悉这种技术，了解API，会做一些小例子，就有技术实力了。但实际上，一个人的技术实力，练不到第二层，都是瞎扯淡。 所以我们接下来要讨论的是运用技术知识和框架解决实际问题的能力 。 提升技术实力，关键的是实践、实践、实践 。 通常有两种靠谱的方法 ： 找一个能够频繁给你高强度刺激的工作环境，你可以不断去实践，想停下来都不行 主动的、有意识的去做专项练习和综合练习 先说第一个，比如你在一个朝九晚五相对悠闲的公司，节奏缓慢，半年出一个版本，那就换到 996 的公司、一周一个版本的那种，Ok，自然你的技术实力就提高得快，HIGH得你不要不要的。 不过很多人是叶公好龙，不会为了提升技术实力而这么残害自己的。然而说实话，这几乎是唯一靠谱的方法。 再说第二种方法，有意练习。这是对一种方法的补充哦。注意，是补充。 因为 大部分的人，没有主动、有意的练习的能力 。 简单讲，就是不愿意为了获得某种实力而积极主动给自己加压，总想着哎呀是不是有什么方法、捷径，我照着一学，技术实力就上去了。 我可以坦白讲，没有的事！别做梦了。 所以，这第二种方法，只适用于那些愿意给自己压力、愿意逼迫自己前进的人。而且，它的目的，也是给自己创造实践的机会。

RPC 模块是我最初研究 Seata 源码开始的地方，因此我对 Seata 的 RPC 模块有过一些深刻研究，在我研究了一番后，发现 RPC 模块中的代码需要进行优化，使得代码更加优雅，交互逻辑更加清晰易懂，本着 “ 让天下没有难懂的 RPC 通信代码 ” 的初衷，我开始了 RPC 模块的重构之路。 这里建议想要深入了解 Seata 交互细节的，不妨从 RPC 模块的源码入手，RPC 模块相当于 Seata 的中枢，Seata 所有的交互逻辑在 RPC 模块中表现得淋漓尽致。 这次 RPC 模块的重构将会使得 Seata 的中枢变得更加健壮和易于解读。 重构继承关系 在 Seata 的旧版本中，RPC 模块的整体结构有点混乱，尤其是在各个类的继承关系上，主要体现在： 直接在 Remoting 类继承 Netty Handler，使得 Remoting 类与 Netty Handler 处理逻辑耦合在一起； 客户端和服务端的 Reomting 类继承关系不统一； RemotingClient 被 RpcClientBootstrap 实现，而 RemotingServer 却被 RpcServer 实现，没有一个独立的 ServerBootstrap，这个看起来关系非常混乱； 有些接口没必要抽取出来，比如 ClientMessageSender

clone 并导入源码 本地启动 NameServer 本地启动 Broker 本地运行生产者与消费者代码 完成上述步骤之后，RocketMQ的源码环境就搭建完毕了，之后就可以在本地启动以及收发消息，调试和分析RocketMQ的源码了。 clone 并导入源码 在 github 上选择对应的的代码 https://github.com/apache/rocketmq/tree/rocketmq-all-4.7.0，将其 clone 下来，再切出 4.7.0 版本的源码。Clone 到本地之后，用 IDEA 打开项目。 项目结构 模块 作用 broker Broker 相关代码 client Producer、Consumer 客户端代码，用于生产消息、消费消息 common 公共代码 dev 开发相关的信息 distribution 部署相关，比如配置文件 example 例子 filter 过滤器 logappender 日志相关 logging 日志相关 namesvr NameServer openmessaging 开放消息标准 remoting 远程网络通信，基于 netty 实现 srvutil 工具类 store 消息如何在 Broker 中进行存储相关代码 style 代码检查 test 测试 tools 命令行监控 本地启动 NameServer

1、引言 好久没写技术文章了，今天这篇不是原理性文章，而是为大家分享一下由笔者主导开发实施的IM即时通讯聊天系统，针对大量离线消息（包括消息漫游）导致的用户体验问题的升级改造全过程。 文章中，我将从如下几个方面进行介绍： 1）这款IM产品的主要业务及特点； 2）IM系统业务现状和痛点； 3）升级改造之路； 4）消息ACK逻辑的优化。 下述内容都是根据笔者开发IM的亲身经历总结下来的宝贵经验，干货满满，期待你的点赞。 本文已同步发布于“即时通讯技术圈”公众号。 2、此IM产品的主要业务及特点 和传统互联网行业有所不同，笔者所在的公司（名字就不透露了）是一家做娱乐社交app的公司，包括小游戏、聊天、朋友圈feed等。 大家应该都有体会： 游戏业务在技术上和产品形态上与电商、旅游等行业有着本质上的区别。 大部分做后端开发的朋友，都在开发接口。客户端或浏览器h5通过HTTP请求到我们后端的Controller接口，后端查数据库等返回JSON给客户端。大家都知道，HTTP协议有短连接、无状态、三次握手四次挥手等特点。而像游戏、实时通信等业务反而很不适合用HTTP协议。 原因如下： 1）HTTP达不到实时通信的效果，可以用客户端轮询但是太浪费资源； 2）三次握手四次挥手有严重的性能问题； 3）无状态。 比如说，两个用户通过App聊天，一方发出去的消息，对方要实时感知到消息的到来

SerialPortPlus项目地址 Android串口开发，基于谷歌官方的 android-serialport-api 增加支持设置奇偶校验、数据位和停止位 使用步骤 第一步： app/build.gradle 进行依赖 implementation 'com.azhon:serialport:1.0.0' 第二步：打开串口 1.打开串口 try { SerialPortPlus serialPortPlus = new SerialPortPlus ( "/dev/ttyMT2" , 9600 ) ; //如果你需要设置奇偶校验、数据位和停止位 //SerialPortPlus serialPortPlus = new SerialPortPlus("/dev/ttyMT2", 9600, 0, 1, 8, 1); } catch ( Exception e ) { e . printStackTrace ( ) ; } 2.设置串口数据回调 serialPortPlus . setReceiveDataListener ( this ) ; 第三步：发送数据 serialPortPlus . writeAndFlush ( data ) ; 第四步：处理数据 @Override public void receiveData ( ByteBuf byteBuf ) { /

public class PulsarProducer { private static PulsarClient client; private static Producer<String> producer; public static void main(String[] args) throws Exception { try { client = PulsarClient.builder().serviceUrl("pulsar://mypulsar.test.com:6650") .build(); producer = client.newProducer(Schema.STRING) // .topic("public/dominos/coupon3") .enableBatching(false) //.batcherBuilder(BatcherBuilder.KEY_BASED) .topic("my-topic").create(); startProducer3(); }catch (Exception e) { // TODO: handle exception e.printStackTrace(); } // System.exit(1); } private static void startProducer3() throws