该命令启动Redis服务，并指定了配置文件/path/to/redis.conf，给出了两个启动配置项：port、protected-mode。

Redis由于速度快、性能高，常常作为MySQL等传统数据库的缓存数据库。但由于Redis是远程服务，查询Redis需要通过网络请求，在高并发查询情景中难免造成性能损耗。所以，高并发应用通常引入本地缓存，在查询Redis前先检查本地缓存是否存在数据。假如使用MySQL存储数据，那么数据查询流程下图所示。

Redis通常使用字典结构存储用户散列数据。 字典是Redis的重要数据结构。除了散列类型，Redis数据库也使用了字典结构。 Redis使用Hash表实现字典结构。分析Hash表，我们通常关注以下几个问题： （1）使用什么Hash算法？ （2）Hash冲突如何解决？ （3）Hash表如何扩容？

在上一篇文章《Redis列表实现原理之ziplist结构》，我们分析了ziplist结构如何使用一块完整的内存存储列表数据。同时也提出了一个问题：如果链表很长，ziplist中每次插入或删除节点时都需要进行大量的内存拷贝，这个性能是无法接受的。本文分析quicklist结构如何解决这个问题，并实现Redis的列表类型。

Redis内部使用该链表保存运行数据，如主服务下所有的从服务器信息。 但Redis并不使用该链表保存用户列表数据，因为它对内存管理不够友好： （1）链表中每一个节点都占用独立的一块内存，导致内存碎片过多。 （2）链表节点中前后节点指针占用过多的额外内存。 读者可以思考一下，用什么结构可以比较好地解决上面的两个问...

Redis中的数据对象server.h/redisObject是Redis对内部存储的数据定义的抽象类型，在深入分析Redis数据类型前，我们先了解redisObject，它的定义如下：

大家好，今天给大家介绍一下我的新书 —— 《Redis核心原理与实践》。 后端开发的同学应该对Redis都不陌生，Redis由于性能极高、功能强大，已成为业界非常流行的内存数据库。

Spring Data R2DBC项目是Spring提供的数据库响应式编程框架。R2DBC是Reactive Relational Database Connectivity的首字母缩写词。 R2DBC是一个API规范倡议，它声明了一个响应式API，由驱动程序供应商实现，并以响应式编程的方式访问他们的关系数据库。实现数据库的响应式编程并不是容易的，传统的JDBC协议是一个完全阻塞...

我们知道，Kafka使用Zookeeper负责为kafka存储broker，Consumer Group等元数据，并使用Zookeeper完成broker选主等操作。虽然使用Zookeeper简化了Kafka的工作，但这也使Kafka的部署和运维更复杂。

本文分享Spring中如何实现Redis响应式交互模式。本文将模拟一个用户服务，并使用Redis作为数据存储服务器。本文涉及两个java bean，用户与权益 {代码...} 启动引入依赖 {代码...} 添加Redis配置 {代码...} SpringBoot启动 {代码...} 应用启动后，Spring会自动生成ReactiveRedisTemplate（它的底层框架是Lettuce）。React...

WebFlux是Spring 5提供的响应式Web应用框架。它是完全非阻塞的，可以在Netty，Undertow和Servlet 3.1+等非阻塞服务器上运行。本文主要介绍WebFlux的使用。

Reactor是Spring提供的非阻塞式响应式编程框架，实现了Reactive Streams规范。 它提供了可组合的异步序列API，例如Flux（用于[N]个元素）和Mono（用于[0 | 1]个元素）。

Netty源码分析系列文章已接近尾声，本文再来分析Netty中两个常见组件：FastThreadLoca与HashedWheelTimer。源码分析基于Netty 4.1.52

由于在Java中创建一个实例的消耗不小，很多框架为了提高性能都使用对象池，Netty也不例外。本文主要分析Netty对象池Recycler的实现原理。

前面文章已经分享了Netty如何引用jemalloc 4算法管理内存。本文主要分享Netty 4.1.52之前版本中，PoolChunk如何使用jemalloc 3算法管理内存。感兴趣的同学可以对比两种算法。源码分析基于Netty 4.1.29

前面文章说了PoolChunk如何管理Normal内存块，本文分享PoolSubpage如何管理Small内存块。源码分析基于Netty 4.1.52

首先说明PoolChunk内存组织方式。PoolChunk的内存大小默认是16M，Netty将它划分为2048个page，每个page为8K。PoolChunk上可以分配Normal内存块。Normal内存块大小必须是page的倍数。

我们知道，Netty使用直接内存实现Netty零拷贝以提升性能，但直接内存的创建和释放可能需要涉及系统调用，是比较昂贵的操作，如果每个请求都创建和释放一个直接内存，那性能肯定是不能满足要求的。这时就需要使用内存池。即从系统中申请一大块内存，再在上面分配每个请求所需的内存。

在学习Netty内存池之前，我们先了解一下Netty的内存对齐类SizeClasses，它为Netty内存池中的内存块提供大小对齐，索引计算等服务方法。源码分析基于Netty 4.1.52

Netty中零拷贝机制主要有以下几种1.文件传输类DefaultFileRegion#transferTo，调用FileChannel#transferTo，直接将文件缓冲区的数据发送到目标Channel，减少用户缓冲区的拷贝(通过linux的sendfile函数)。使用read 和 write过程如下

前面文章说了，ChannelHandlerContext#write只是将数据缓存到ChannelOutboundBuffer，等到ChannelHandlerContext#flush时，再将ChannelOutboundBuffer缓存的数据写到Channel中。本文分享Netty中ChannelOutboundBuffer的实现以及Flush过程。源码分析基于Netty 4.1

客户端启动过程比较简单，主要是Connect操作。Netty客户端启动引导类是Bootstrap，同样继承了AbstractBootstrap，它只有一个EventLoopGroup，下文称为ConnectGroup。

Eureka分为Eureka Client，Eureka Server，多个Eureka Server节点组成一个Eureka集群，服务通过Eureka Client注册到Eureka Server。

本文分享spring cloud sleuth如何构建请求调用链路，并上报zipkin。如果大家在使用spring cloud sleuth时遇到traceId丢失，上报zipkin失败等问题，希望本文可以给大家一个思路。源码分析基于Spring Cloud Hoxton，Spring Cloud Sleuth版本为2.2.0.RELEASE

Zuul通过ZuulFilter对请求进行拦截，过滤，转发等操作。ZuulFilter也是提供给我们扩展的接口。ZuulFilter有四种类型pre：在请求被路由之前调用，主要负责过滤，request请求处理等工作route：负责请求路由，转发工作post：负责发送响应到客户端error：上面流程发生错误时被调用，做一些异常善后工作

本文通过阅读源码，分享Spring Cloud Config与@RefreshScope的实现原理。源码分析基于Spring Cloud Hoxton

Netty中的ChannelPipeline可以理解为拦截器链，维护了一个ChannelHandler链表，ChannelHandler即具体拦截器，可以在读写过程中，对数据进行处理。ChannelHandler也可以分为两类。ChannelInboundHandler，监控Channel状态变化，如channelActive，channelRegistered，通常通过重写ChannelOutboundHandler#channelRead方法...

前面分享服务端和客户端启动过程的文章中说过，Netty通过事件循环机制(EventLoop)处理IO事件和异步任务，简单来说，就是通过一个死循环，不断处理当前已发生的IO事件和待处理的异步任务。示例如下

Netty是一个高性能的网络通信框架，支持NIO，OIO等多种IO模式。通常，我们都是使用NIO模式，该系列文章也是解析Netty下NIO模式的实现。首先，看一个NIO网络通信示意图Netty中NIO网络通信过程在此基础上实现，下面来看一下具体实现。

本文主要分享SpringCloud中RestTemplate与@LoadBalanced的实现原理。源码分析基于Spring Cloud Hoxton