众所周知， Jemalloc 作为很多对内存敏感的系统/中间件的主要内存分配工具，以优良的性能从一开始取代了 malloc，比如 Redis 从 4.0 开始引用 Jemalloc；前两年在调试 Redis 代码的时候发现一个问题，同样是 malloc(1024); 这样一个普通的语句，引入了 Jemalloc 的时候，分配的内存空间地址类似 0x7f5c1d923010，从样子上看非常像是属于栈地址的高位空间 0x7fffbc500084，而 标准库里的 malloc 分配的内存地址为明显的低位地址 0xf94330，一看就属于堆地址空间，当时就疑惑了，Jemalloc 到底用了啥技术可以让 栈地址空间在方法间传来传去，完全不科学嘛…

当时一直认为是 Jemalloc 方面的手脚，花了一两天翻了 Jemalloc 源码，二话不说就 gdb 起来，相信无论是哪个地方的问题，在我单步调试下一定能无所遁形，当时调试到最后还是返回的高位地址（劳资信了你的鞋 ~~~!!!），奈何产品经理上门催任务了，暂时搁置，最近刚好有空，心痒痒，再来瞅瞅，这一瞅，还真发现问题了…

『敲黑板』，这次我们就来分析一下具体原因，顺便说说 malloc 和 Jemalloc 的实现方式

就在 2019 年 12 月 20 号这天，众所期待的 Redis 新版 6.0 rc1 发布了（Redis 6 RC1 is out today）肯定很多关注的同学都进行了试用，虽然因为引入了 c11 的 _Atomic 导致相当多的环境都无法直接编译成功，但是对于想一探究竟的粉丝们来说，这是完全阻挡不了的热情，当然我也不例外~<狗头>~~

新版除了增加 ACLS 权限控制模块、支持更为广泛的新协议 RESP3、客户端缓存、无磁盘同步、Cluster Proxy 等十来个相当实用的新特性外，还对 长久以来 社区筒子们 呼声比较高的 多线程 进行了支持，当然也带来 性能提升了一倍 的好处

这次我们的任务有两个：

• 剖析 Redis6 多线程的实现方式
• 与 Memcached 的多线程模型（个人认为这是一个极其经典的多线程网络编程案例）进行对比

Nginx 作为 多进程网络编程的 巅峰之作（那么请问 多线程巅峰、单进程巅峰是？），也是当前最流行的 HTTP Server，其优秀之处毋容置疑；一直到 2011 年左右，Nginx 还仅仅是 反向代理的 首选，后来随着 HTTP 核心的成熟 慢慢用来 替代 Apache 单独作为 HTTP Server；当然这中间也离不开 第三方扩展模块 的日益丰富；从最初的 nginx_lua_module 支持 lua 嵌入，到后来 春来大神 的 OpenResty，集成 LuaJIT，使得 Nginx 生态再次丰富起来

说到第三方扩展，就不得不说一下 Nginx 的 高扩展特性，它从设计上完全就由多个不同功能、不同层次、不同类型且耦合度极低的模块构成，因此，当对某一个模块修复 Bug 或 进行升级的时候，可以专注于模块本身，无需在意其他。而且在 HTTP 模块中，还设计了 HTTP 过滤器模块，也就是说一个正常的 HTTP 模块在处理完成 request 后，会有一串 HTTP 过滤器模块对请求结果进行再处理，这样，当我们开发一个新的 HTTP 模块时，当然也可以复用诸如 HTTP 核心模块、events 模块、log 模块 等不同层次不同类型的模块，这种低耦合度的优秀设计，也给我们 定制模块开发 提供了很大便利

Kong 是一款基于 OpenResty（Nginx + Lua模块）编写的高可用、易扩展的，由 Mashape 公司开源的 API Gateway 项目。Kong 是基于 Nginx 和 Apache Cassandra 或 PostgreSQL 构建的，能提供易于使用的 RESTful API 来操作和配置 API 管理系统，所以它可以水平扩展多个 Kong 服务器，通过前置的负载均衡配置把请求均匀地分发到各个 Server，来应对大批量的网络请求

Kong 采用插件机制进行功能定制，插件集（可以是0或N个）在 API 请求响应循环的生命周期中被执行。插件使用 Lua 编写，目前已有一些基础功能：HTTP基本认证、密钥认证、CORS（Cross-Origin Resource Sharing，跨域资源共享）、TCP、UDP、文件日志、API请求限流、请求转发以及Nginx监控。

推荐查看 官网文档，详细了解，这里不再赘述，我们这次还是以 Kong 网关插件开发为主题，定制一个 Signature验签 插件

刚好紧接上一章 的主从架构，我们这次来分享另外一种 原生高可用方案，就是 sentinel 哨兵 架构

主从架构优势比较明显，可以 保障数据的高可用，从服务器可以扩展主服务器的读能力，有效应对大并发操作

但是，如果主服务器发生故障的时候，需要手动将一个从服务器升级为主服务器，同时需要通知业务方变更配置，并且需要让其它从服务器去复制新主服务器节点，整个过程需要人为干预，比较繁琐；另外还有一个就是，如果没有升级 Redis 到 2.8 以上，则 可能因为 全量同步问题 造成大量资源消耗

所以 Redis 社区推出了一种原生的高可用解决方案，就是 Redis sentinel 架构，由一个或多个 sentinel 实例 组成的 sentinel 系统可以监控任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监控的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务，实现 Redis 架构的 监控、通知 以及 自动故障转移

复制 作为现代数据服务基本必备的功能，保证 数据的冗余备份，从而保障服务高可用和高可靠性，当然 Redis 这么伟大的服务也不例外

本章可能有点儿绕，做好心理准备… _￣ω￣=

Redis 复制( replicate ) 流程的核心在于 状态机 中状态的流转，连接各个逻辑运算，我根据 Redis ver4.0.11 的源码逻辑画了一个简单的 master-slave 状态机流转示意图，由于一般 从库的挂载都是由 slave 发起的，所以 slave 放在左边，大家可以先看一眼，我们后续进行每个步骤的详细讲解

Redis 的高可用 很大程度上要归功于其 为 事件驱动服务工具，采用 Reactor 模式 使得其 拥有高性能 IO 操作

首先我们先科普一下什么叫 Reactor 模式，即 事件驱动机制，应用程序提供相应的接口并注册到 Reactor 上，如果相应的事件发生，Reactor 将主动调用之前注册的接口，而这些接口又称为 回调函数

上次我们主要讲解的是 RDB 机制，这次我们着重对 AOF 持久化进行详细说明，另外后续我们也会针对 RDB-AOF 混合模式（Redis 4 开始）进行分享…

AOF（Append Only File）顾名思义 只进行追加操作的文件，通过保存 Redis 服务器所执行的 命令来记录数据库的状态，命令数据都是以 Redis 的请求协议格式（RESP 协议）保存在文本中的，协议详情可以参考之前的文章 RESP 协议

• 优势：AOF 提供了多种策略进行 数据持久化，即使是 默认的 每秒钟 fsync 一次，也能保障最多丢失一秒的数据（fsync 是在后台使用 另外的线程进行执行，不影响 业务线程的处理）；AOF 采用 append 的形式，即使服务器在一瞬间宕机，也不会对之前数据造成影响，即使宕机瞬间产生数据格式问题，也可以通过 redis-check-aof 工具进行 一致性修复；另外，AOF 采用了 RESP 协议，具有很强的可读性
• 劣势：AOF 由于保存了所有数据处理命令集，在同样大小数据规模的情况下，AOF文件 比 RDB文件 会大很多；同样道理，在数据恢复方面，AOF 会慢一些