学习Docker，首先需要了解Docker基本概念，然后就开始“动手”了（也就是敲Docker命令）。Docker命令较多，这里笔者总结下常用的Docker命令，方便小伙伴们查阅。
Docker是基于go语言开发，底层技术（Linux下）主要基于cgroups、namespace以及联合文件技术实现的一种进程级别的轻量级虚拟化解决方案。由于Docker进程隔离独立于宿主机上其他进程，因此也称为容器，Docker在容器的基础上，进行了更进一步的封装，从文件系统、网络到进程隔离等，极大简化了容器的创建管理维护工作，降低了开发者使用门槛，因此才在近几年流行开来（毕竟Docker的底层技术在Docker出现之前就已经存在了）。
很多小伙伴所在的公司是基于Dubbo来构建技术栈的，日常开发中必不可少要写dubbo单测（单元测试），如果单测数据依赖已有的外部dubbo服务，一般是mock数据，如果数据比较复杂，其实mock数据也是一个不小的工作量。那有没有更好的单测方式来代替我们完成”mock“数据功能呢，这时可以借助dubbo telnet功能，获取真实数据用在单测中使用。
缓冲区在计算机世界中随处可见，内存中的多级缓冲区，io设备的缓冲区等等，还有我们经常用的内存队列，分布式队列等等。缓冲区，平衡了数据产生方和数据消费方的处理效率差异，提高了数据处理性能。
JDK为了解决网络通信中的数据缓冲问题，提供了ByteBuffer（heap或者直接内存缓存）来解决缓存问题，通过缓冲区来平衡网络io和CPU之间的速度差异，等待缓冲区积累到一定量的数据再统一交给CPU去处理，从而提升了CPU的资源利用率。
学习netty处理黏包和拆包，首先要知道什么是黏包和拆包问题？
黏包和拆包的产生是由于TCP拥塞控制算法（比如angle算法）和TCP缓冲区机制导致的，angle算法简单来说就是通过一些规则来尽可能利用网络带宽，尽可能的发送足够大的数据。TCP（发送/接收）缓冲区会暂缓数据，并且是有最大容量的。
Netty的启动流程(ServerBootstrap)，就是创建NioEventLoopGroup（内部可能包含多个NioEventLoop，每个eventLoop是一个线程，内部包含一个FIFO的taskQueue和Selector）和ServerBootstrap实例，并进行bind的过程（bind流程涉及到channel的创建和注册），之后就可以对外提供服务了。
Netty是Java领域有名的开源网络库，特点是高性能和高扩展性，因此很多流行的框架都是基于它来构建的，比如我们熟知的Dubbo、Rocketmq、Hadoop等，针对高性能RPC，一般都是基于Netty来构建，比如sock-bolt。总之一句话，Java小伙伴们需要且有必要学会使用Netty并理解其实现原理。
Netty一个主要的目标就是促进“关注点分离”：使业务逻辑从网络基础设施应用程序中分离。不仅仅是Netty框架，其他框架的设计目的也大都是为了使业务程序和底层技术解耦，使程序员更加专注于业务逻辑实现，提高开发质量和效率。Netty为什么性能如此之高，主要是其内部的Reactor模型机制。
Netty的连接处理就是IO事件的处理，IO事件包括读事件、ACCEPT事件、写事件和OP_CONNECT事件。
IO事件的处理是结合ChanelPipeline来做的，一个IO事件到来，首先进行数据的读写操作，然后交给ChannelPipeline进行后续处理，ChannelPipeline中包含了channelHandler链（head + 自定义channelHandler + tail）。
使用channelPipeline和channelHandler机制，起到了解耦和可扩展的作用。一个IO事件的处理，包含了多个处理流程，这些处理流程正好对应channelPipeline中的channelHandler。如果对数据处理有新的需求，那么就新增channelHandler添加到channelPipeline中，这样实现很6，以后自己写代码可以参考。
Pipeline和ChannelHandler是Netty处理流程的重要组成部分，ChannelHandler对应一个个业务处理器，Pipeline则是负责将各个ChannelHandler串起来的“容器”，二者结合起来一起完成Netty的处理流程。
要学习netty线程模型，先了解下NIO和AIO、reactor和proactor模型，这样理解netty线程模型和IO模型更轻松。
IO模型
epoll机制是Linux下一种高效的IO复用方式，相较于select和poll机制来说。其高效的原因是将基于事件的fd放到内核中来完成，在内核中基于红黑树+链表数据结构来实现，链表存放有事件发生的fd集合，然后在调用epoll_wait时返回给应用程序，由应用程序来处理这些fd事件。
使用IO复用，Linux下一般默认就是epoll，Java NIO在Linux下默认也是epoll机制，但是JDK中epoll的实现却是有漏洞的，其中最有名的java nio epoll bug就是即使是关注的select轮询事件返回数量为0，NIO照样不断的从select本应该阻塞的Selector.select()/Selector.select(timeout)中wake up出来，导致CPU 100%问题。如下图所示：
本文主要讨论Netty NioEventLoop原理及实践，关于Netty NioEventLoop，首先要知道NioEventLoop是什么，为什么它会是Netty核心Reactor处理器，实现原理是什么，进而再讨论Netty对其的实现及使用上我们可以学到哪些。
高并发系统设计的3个利器：缓存、限流、降级，本文就限流相关算法，分析其设计与实现。
从分布式角度来看，限流可分为分布式限流（比如基于Sentinel或者Redis的集群限流）和单机限流。从算法实现角度来看，限流算法可分为漏桶算法、令牌桶算法和滑动时间窗口算法。下面主要分析这3种限流算法和分布式限流实现方案。
sentinel针对目前常见的主流框架都做了适配，比如dubbo、Web Servlet、Spring Cloud、Spring WebFlux等。sentinel的适配做到了开箱即用，那么它是通过什么机制来实现的呢？这里大家可以思考下，如果一个框架本身没有扩展机制（这只是举个极端的例子，一般开源框架都是有自身的扩展机制的），那么sentinel是无法进行适配的，更谈不上开箱即用，除非更改框架源码。所以说，如果明白了框架的扩展机制，那么理解sentinel的适配机制就很easy了，比如dubbo 本身有Filter机制（consumer端和provider端都有），Web servlet也有自己的Filter机制可进行自定义扩展。
为什么需要集群流控呢？假设需要将某个API的总qps限制在100，机器数可能为50，这时很自然的想到使用一个专门的server来统计总的调用量，其他实例与该server通信来判断是否可以调用，这就是基本的集群流控方式，sentinel的实现就是这样的。
如果服务调用使用轮训或者随机路由方式，理论上可以通过在各个单机上设置流控规则即可（单机qps上限=总qps上限 / 机器数）。集群流控可以解决流量分配不均的问题导致总体流控效果不佳的问题，其可以精确地控制整个集群的调用总量，结合单机限流兜底，可以更好地发挥流量控制的效果，不过由于会与server进行通信，所以性能上会有一定损耗。
sentinel的滑动窗口统计机制就是根据当前时间，获取对应的时间窗口，并更新该时间窗口中的各项统计指标（pass/block/rt等），这些指标被用来进行后续判断，比如限流、降级等；随着时间的推移，当前时间点对应的时间窗口是变化的，这时会涉及到时间窗口的初始化、复用等。可以说，sentinel上的功能所用到的数据几乎都是滑动窗口统计机制来维护和更新的。
前段时间笔者在团队内部分享了sentinel原理设计与实现，主要讲解了sentinel基础概念和工作原理，工作原理部分大家听了基本都了解了，但是对于sentinel的几个概念及其之间的关系还有挺多同学有点模糊的，趁着这几天比较空，针对sentinel的几个核心概念，做了一些总结，希望能帮助一些sentinel初学者理清这些概念之间的关系。
以下ConcurrentHashMap以jdk8中为例进行分析，ConcurrentHashMap是一个线程安全、基于数组+链表(或者红黑树)的kv容器，主要特性如下：
Redis用到的底层数据结构有：简单动态字符串、双端链表、字典、压缩列表、整数集合、跳跃表等，Redis并没有直接使用这些数据结构来实现键值对数据库，而是基于这些基础数据结构创建了一个对象系统，这写对象包括字符串对象、列表对象、哈希对象、集合对象和有序集合对象等。