Netty

java nio模型理解

只谈情不闲聊 提交于 2021-02-18 01:56:25
1、tcp信道,具体参数详情参考api ServerSocketChannel:创建、接收、关闭、读写、阻塞 SocketChannel:创建、连接、关闭、读写、阻塞(测试连接性) 2、Selector:创建、关闭选择器 案例一: NIOAccepter服务端线程 package com.warehouse.data.nio; import java.io.IOException; import java.net.InetSocketAddress; import java.nio.channels.SelectionKey; import java.nio.channels.Selector; import java.nio.channels.ServerSocketChannel; import java.nio.channels.SocketChannel; import java.util.Set; import javax.imageio.IIOException; /** * ${DESCRIPTION} * package com.warehouse.data.nio * * @author zli [liz@yyft.com] * @version v1.0 * @create 2017-03-28 9:55 **/ public class NIOAcceptor

锁和分布式锁

余生颓废 提交于 2021-02-17 01:59:24
锁的由来 : 多线程环境中,经常遇到多个线程访问同一个 共享资源 ,这时候作为开发者必须考虑如何维护数据一致性,这就需要某种机制来保证只有满足某个条件(获取锁成功)的线程才能访问资源,而不满足条件(获取锁失败)的线程只能等待,在下一轮竞争中来获取锁才能访问资源。 两个知识点: 1.高级缓存Cache CPU为了提高处理速度,不和内存直接进行交互,而是使用Cache。 可能引发的问题: 如果多个处理器同时对共享变量进行读改写操作 (i++就是经典的读改写操作),那么共享变量就会被多个处理器同时进行操作,这样读改写操作就不是原子的了,操作完之后共享变量的值会和期望的不一致。 造成此结果的原因: 多个处理器同时从各自的缓存中读取变量i,分别进行加1操作,然后分别写入 系统内存中。 处理器层面的解决方案: 处理器使用总线锁就是来解决这个问题的。所谓总线锁就是使用处理器提供的一个 LOCK#信号,当一个处理器在总线上输出此信号时,其他处理器的请求将被阻塞住,那么该处理器可以独占共享内存。 2.CAS(Compare And Swap)+volatile CAS 操作包含三个操作数 —— 内存位置(V)、预期原值(A)和新值(B)。执行CAS操作的时候,将内存位置的值与预期原值比较,如果相匹配,那么处理器会自动将该位置值更新为新值。否则,处理器不做任何操作。

分布式事务框架 seata-golang 通信模型详解

不问归期 提交于 2021-02-14 13:41:07
简介: Java 的世界里,大家广泛使用的一个高性能网络通信框架 netty,很多 RPC 框架都是基于 netty 来实现的。在 golang 的世界里,getty 也是一个类似 netty 的高性能网络通信库。getty 最初由 dubbogo 项目负责人于雨开发,作为底层通信库在 dubbo-go 中使用。随着 dubbo-go 捐献给 apache 基金会,在社区小伙伴的共同努力下,getty 也最终进入到 apache 这个大家庭,并改名 dubbo-getty 。 作者 | 刘晓敏 于雨 一、简介 Java 的世界里,大家广泛使用的一个高性能网络通信框架 netty,很多 RPC 框架都是基于 netty 来实现的。在 golang 的世界里, getty 也是一个类似 netty 的高性能网络通信库。getty 最初由 dubbogo 项目负责人于雨开发,作为底层通信库在 dubbo-go 中使用。随着 dubbo-go 捐献给 apache 基金会,在社区小伙伴的共同努力下,getty 也最终进入到 apache 这个大家庭,并改名 dubbo-getty 。 18 年的时候,我在公司里实践微服务,当时遇到最大的问题就是分布式事务问题。同年,阿里在社区开源他们的分布式事务解决方案,我也很快关注到这个项目,起初还叫 fescar,后来更名 seata

从普通Java程序员到阿里高级架构师,他用了6年!

我怕爱的太早我们不能终老 提交于 2021-02-14 09:35:52
6年间,一位架构师待过四大门户中的两户,已完成了工程师到架构师的蜕变。经手几款从零到一产品的开发和增涨,也亲身经历国內最大社交网络平台亿级数据流量和用户的架构设计及优化工作。在工作中思路清晰、尽职尽责,是同事们心目中出色 Problem Solver。 参加工作时间:8 年 服务公司:4 家(含四大门户中的两户) 近期岗位:Java 架构师 职场关键词:社交网络平台、高并发系统架构设计、技术团队管理、多款从零到一的产品城市! 问: 介绍一下下你自身 答: 我 2007 年本科大学毕业,前 2 年在一家传统式 it互联网 企业,近期 6 年在互联网企业,现任 Java 开发工程师、高级工程师、架构师等职位。工作内容上,经历过多款产品从零到一的诞生开发过程,也经手过国內用户、內容和数据流量最大的社交/社区产品的架构改造优化工作,有丰富的社交产品的研发经验,目前在一家创业公司担任技术合伙人。 问: 你擅长的技术各个领域是啥? 答: 擅长的开发语言是 Java、Golang、Scala,熟悉程度依次递减。专注于高性能、高并发系统架构设计和实现。 问: 平常如何向亲戚朋友解释你的工作是干什么的? 答: 通常不详细解释,即便解释了也是白费力气。所以她们会按照自身的了解来描述我的工作,例如维修电脑的,例如买手机的。 问: 你认为程序猿能否当一辈子吗?有木有想像过自个 45 岁时在做什么工作? 答

netty : NioEventLoopGroup 源码分析

穿精又带淫゛_ 提交于 2021-02-13 14:00:12
NioEventLoopGroup 源码分析 1. 在阅读源码时做了一定的注释,并且做了一些测试分析源码内的执行流程,由于博客篇幅有限。为了方便 IDE 查看、跟踪、调试 代码,所以在 github 上提供 netty 的源码、详细的注释及测试用例。欢迎大家 star、fork ! 2. 由于个人水平有限,对源码的分析理解可能存在偏差或不透彻的地方还请大家在评论区指出,谢谢!    从今天开始,就准备进军 ne tty 了,主要的想法是看看 netty4 中一些比较重要的实现,也就是能经常出现在我们面前的东西。主要是: 线程池、通道、管道、编解码器、以及常用的工具类。    然后现在看源码应该不会像之前的 jdk 那么细致了,主要是看了一个类以后就发现 netty 对代码封装太强了,基本一个功能可能封装了七八个类去实现,很多的抽象类但是这些抽象类中的功能还非常的多。所以说主要看这个流程,以及里面写的比较好的代码或者比较新的思想会仔细的去看看。具体的子字段,每个方法不可能做到那么细致。 <!-- more -->    好,正式开始 netty 源码征战 ! 1. 基本思路    这里首先讲一下结论,也就是先说我看这个类的源码整理出来的思路,主要就是因为这些类太杂,一个功能在好几个类中才完全实现。    我们在 new 一个 worker/boss

8086汇编语言学习(一) 8086汇编介绍

ぃ、小莉子 提交于 2021-02-13 05:31:02
1. 学习汇编的心路历程    进行8086汇编的介绍之前,想先分享一下我学习汇编的心路历程 。 rocketmq的学习   其实我并没有想到这么快的就需要进一步学习汇编语言,因为汇编对于我的当前的工作内容来说太过底层。   但在几个月前,当时我正尝试着阅读rocketmq的源码。和许多流行的java中间件、框架一样,rocketmq底层的网络通信也是通过netty实现的。但由于我对netty并不熟悉,在工作中使用spring-cloud-gateway的时候甚至写出了一些导致netty内存泄漏的代码,却不太明白个中原理 。出于我个人的习惯,在学习源码时,抛开整体的程序架构不论,希望至少能对其中涉及到的底层内容有一个大致的掌握,能让我像黑盒子一样去看待它们。   趁热打铁,我决定先学习netty,这样既能在工作时更好的定位、解决netty相关的问题,又能在研究依赖netty的开源项目时更加得心应手。 netty的学习   随着对netty学习的深入,除了感叹netty统一规整的api接口设计,内部交互灵活可配置、同时又提供了足够丰富的开箱即用组件外;更进一步的,netty或者说java nio涉及到了许多更底层的东西,例如:io多路复用,零拷贝,事件驱动等等。而这些底层技术在redis,nginx,node-js等以高效率io著称的应用中被广泛使用。   扪心自问

从源码上理解Netty并发工具-Promise

╄→尐↘猪︶ㄣ 提交于 2021-02-12 19:34:07
前提 最近一直在看 Netty 相关的内容,也在编写一个轻量级的 RPC 框架来练手,途中发现了 Netty 的源码有很多亮点,某些实现甚至可以用 苛刻 来形容。另外, Netty 提供的工具类也是相当优秀,可以开箱即用。这里分析一下个人比较喜欢的领域,并发方面的一个 Netty 工具模块 - Promise 。 环境版本: Netty:4.1.44.Final JDK1.8 <!-- more --> Promise简介 Promise,中文翻译为承诺或者许诺,含义是人与人之间,一个人对另一个人所说的具有一定憧憬的话,一般是可以实现的。 io.netty.util.concurrent.Promise 在注释中只有一句话: 特殊的可写的 io.netty.util.concurrent.Future ( Promise 接口是 io.netty.util.concurrent.Future 的子接口)。而 io.netty.util.concurrent.Future 是 java.util.concurrent.Future 的扩展,表示 一个异步操作的结果 。我们知道, JDK 并发包中的 Future 是不可写,也没有提供可监听的入口(没有应用观察者模式),而 Promise 很好地弥补了这两个问题。另一方面从继承关系来看, DefaultPromise

What is the most optimal way to make an API on apache camel to have (SSL) implemented for HTTPS?

帅比萌擦擦* 提交于 2021-02-11 12:36:42
问题 I am looking to make my API created with Apache-Camel be HTTPS enabled. I have conducted some reading into the various ways (using Jetty, Netty etc.) but I'm wanting to know what the simplest and most efficient way to implement SSL to my camel based API is. Here is my current configuration, I would prefer (for simplicity's sake if I could use netty4-http) public void configure() { restConfiguration() .component("netty4-http")//Specifies the Camel component to use as the REST transport .host(

Where will the data been queued if Netty channel isWritable return false

与世无争的帅哥 提交于 2021-02-11 07:20:07
问题 From the Netty api, it shows the request will be queued if isWritable return false. Could I know where will the request be queued? In what case, the queue could be full and cause OOM issue? Following is the document for isWritable() Returns true if and only if the I/O thread will perform the requested write operation immediately. Any write requests made when this method returns false are queued until the I/O thread is ready to process the queued write requests. https://netty.io/4.1/api/io

Netty HTTPProxyHandler always sends a CONNECT

吃可爱长大的小学妹 提交于 2021-02-10 15:58:57
问题 Is it right that HTTPProxyHandler always sends a CONNECT request? Isn't this only applicable when you want to do tunneling? 回答1: HTTPProxyHandler does not know if you only want to tunnel http data, or want to make http request at the moment of connection, therefore, it guesses the option that works in both cases, since a standard complements HTTP proxy supports both the CONNECT and the old http proxy method call. If you need to implement a HTTP proxy using GET and other methods, just thread