在开始前 咱们先来做个调研~

有哪些朋友们自己亲自换过（或者安装过）电脑上的内存条，无论 台式机、笔记本 亦或是 刀片机 都行

一、为什么有这么一个话题

这两年一直有个很热的话题，就是 芯片这个被卡脖子的领域，所以年初在筹备课程话题的时候就想着跟大家一起聊聊这方面的东西；

那么大家可能想着芯片不应该说 CPU 吗，为啥聊内存啊？？？ 额，主要是我手头没有多的 CPU，储藏室倒是有几个当年去科技市场买零件 “攒（cuan)” 电脑时候淘换的古董内存条，索性咱们就一起聊聊内存条吧，毕竟内存条也是芯片的重要应用场景。

MD5 是一个特别古老的知识：

• 老到我们都认为它的一切都是理所当然的；
• 老到我们看到这个名称仿佛看到的就是老掉牙的代名词。

直到前段时间我遇到了一些案例，才想起来，也许可以跟大家聊聊这个特别 “平常” 的小玩意儿～

一、为什么有这么一个话题

前几个月在处理小朋友日常视频的时候，发现视频工具提供了一个 MD5 更改的工具，下意识心说这么简单的一个功能咋还搞了个工具出来，不过转念一想，这也许就是个思维陷阱，其实听说过 MD5 的人本来就不多（只是我们身处这个行业才觉得很平常）

好奇看了一下搜索结果（是不是发现也许一个小东西也是商机）：

众所周知， 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验签 插件

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

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

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

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

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

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

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