redis学习记录

淩亂°似流年 2022-12-01 01:20 337阅读 0赞

### redis基础知识汇总 ###

*  缓存的基本知识
 *   *  缓存的思想
     *  缓存的优势与代价
     *  缓存读写的模式
     *  缓存分类及常用缓存
     *  缓存的七大经典问题
     *   *  缓存失效
         *  缓存穿透
         *  缓存雪崩
         *  缓存数据不一致
         *  数据并发竞争
         *  Hot Key
         *  Big key
 *  redis 基础知识
 *   *  什么是Redis？
     *  redis的优缺点?
     *  redis为什么是单线程的？
     *  redis比memcached的优势在哪里？以及两者的区别？
     *  redis的基本数据结构
     *  redis底层的数据结构
     *   *  redisObject
         *  字符串对象
         *   *  Sds
         *  列表对象
         *   *  ziplist
             *  quicklist
         *  哈希对象
         *   *  dict
         *  集合对象
         *  有序集合对象
         *  hyperloglog
         *  GEO
         *  bitmap
     *  Redis的协议模式
     *   *  设计原则
         *  两种特殊模式
         *  响应格式
         *  协议分类
     *  Redis事件处理机制
     *   *  Redis 事件驱动模型
         *  文件事件处理
     *  redis的持久化策略？
     *  Redis过期键的删除策略
     *  数据淘汰策略
     *  Redis崩溃后，如何进行数据恢复的？
     *  redis的事务？
 *  redis 高并发和高可用
 *   *  Redis的高并发是如何实现的？
     *  Redis的高可用是如何实现的？
 *  redis多机架构
 *   *  redis集群
     *   *  Redis 的集群管理有 3 种方式。
         *   *  Client 端分区
             *  Proxy 端分区
             *  Redis Cluster 分区
             *  Redis cluster集群的通信方式
             *  集群分片的原理是什么?
             *  集群扩容和收缩是怎么实现的？
     *  Redis主从复制
 *  Redis的应用
 *   *  大任务的处理机制
     *  提升性能
 *  Redis的应用场景

# 缓存的基本知识 #

## 缓存的思想 ##

缓存构建的基本思想是利用时间局限性原理，通过空间换时间来达到加速数据获取的目的，同时由于缓存空间的成本较高，在实际设计架构中还要考虑访问延迟和成本的权衡问题.

*  一是时间局限性原理，即被获取过一次的数据在未来会被多次引用。
 *  二是以空间换时间，因为原始数据获取太慢，所以我们开辟一块高速独立空间，提供高效访问，来达到数据获取加速的目的。
 *  三是性能成本 Tradeoff，构建系统时希望系统的访问性能越高越好，访问延迟越低小越好。但维持相同数据规模的存储及访问，性能越高延迟越小，成本也会越高，所以在系统架构设计时，你需要在系统性能和开发运行成本之间做取舍

## 缓存的优势与代价 ##

**优势**

*  提升访问性能
 *  降低网络拥堵
 *  减轻服务负载
 *  增强可扩展性

**引入缓存的缺陷**

*  首先，服务系统中引入缓存，会增加系统的复杂度。
 *  其次，由于缓存相比原始 DB 存储的成本更高，所以系统部署及运行的费用也会更高。
 *  最后，由于一份数据同时存在缓存和 DB 中，甚至缓存内部也会有多个数据副本，多份数据就会存在一致性问题，同时缓存体系本身也会存在可用性问题和分区的问题。这就需要我们加强对缓存原理、缓存组件以及优秀缓存体系实践的理解，从系统架构之初就对缓存进行良好设计，降低缓存引入的副作用，让缓存体系成为服务系统高效稳定运行的强力基石。

## 缓存读写的模式 ##

业务系统读写缓存有 3 种模式：

*  Cache Aside（旁路缓存）
 *  Read/Write Through（读写穿透）
 *  Write Behind Caching（异步缓存写入）

1）Cache Aside（旁路缓存）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center]

Cache Aside 模式中，业务应用方对于写，是更新 DB 后，直接将 key 从 cache 中删除，然后由 DB 驱动缓存数据的更新；而对于读，是先读 cache，如果 cache 没有，则读 DB，同时将从 DB 中读取的数据回写到 cache。

2）Read/Write Through（读写缓存）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 1]

如上图，对于 Cache Aside 模式，业务应用需要同时维护 cache 和 DB 两个数据存储方，过于繁琐，于是就有了 Read/Write Through 模式。在这种模式下，业务应用只关注一个存储服务即可，业务方的读写 cache 和 DB 的操作，都由存储服务代理。存储服务收到业务应用的写请求时，会首先查 cache，如果数据在 cache 中不存在，则只更新 DB，如果数据在 cache 中存在，则先更新 cache，然后更新 DB。而存储服务收到读请求时，如果命中 cache 直接返回，否则先从 DB 加载，回种到 cache 后返回响应。

这种模式的特点是，存储服务封装了所有的数据处理细节，业务应用端代码只用关注业务逻辑本身，系统的隔离性更佳。另外，进行写操作时，如果 cache 中没有数据则不更新，有缓存数据才更新，内存效率更高。

3） Write Behind Caching （异步缓存写入）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 2]  
Write Behind Caching 模式与 Read/Write Through 模式类似，也由数据存储服务来管理 cache 和 DB 的读写。不同点是，数据更新时，Read/write Through 是同步更新 cache 和 DB，而 Write Behind Caching 则是只更新缓存，不直接更新 DB，而是改为异步批量的方式来更新 DB。该模式的特点是，数据存储的写性能最高，非常适合一些变更特别频繁的业务，特别是可以合并写请求的业务，比如对一些计数业务。

## 缓存分类及常用缓存 ##

**按宿主层次分类的话，缓存一般可以分为本地 Cache、进程间 Cache 和远程 Cache。**

*  本地 Cache 是指业务进程内的缓存，这类缓存由于在业务系统进程内，所以读写性能超高且无任何网络开销，但不足是会随着业务系统重启而丢失。
 *  进程间 Cache 是本机独立运行的缓存，这类缓存读写性能较高，不会随着业务系统重启丢数据，并且可以大幅减少网络开销，但不足是业务系统和缓存都在相同宿主机，运维复杂，且存在资源竞争。
 *  远程 Cache 是指跨机器部署的缓存，这类缓存因为独立设备部署，容量大且易扩展，在互联网企业使用最广泛。不过远程缓存需要跨机访问，在高读写压力下，带宽容易成为瓶颈。

本地 Cache 的缓存组件有 Ehcache、Guava Cache 等，开发者自己也可以用 Map、Set 等轻松构建一个自己专用的本地 Cache。进程间 Cache 和远程 Cache 的缓存组件相同，只是部署位置的差异罢了，这类缓存组件有 Memcached、Redis、Pika 等。

**按存储介质分类分的话，以分为内存型缓存和持久化型缓存：**

*  内存型缓存将数据存储在内存，读写性能很高，但缓存系统重启或 Crash 后，内存数据会丢失。
 *  持久化型缓存将数据存储到 SSD/Fusion-IO 硬盘中，相同成本下，这种缓存的容量会比内存型缓存大 1 个数量级以上，而且数据会持久化落地，重启不丢失，但读写性能相对低 1～2 个数量级。Memcached 是典型的内存型缓存，而 Pika 以及其他基于 RocksDB 开发的缓存组件等则属于持久化型缓存。

## 缓存的七大经典问题 ##

### 缓存失效 ###

**缓存第一个经典问题是缓存失效**。业务访问时，如果大量的 key 同时过期，很多缓存数据访问都会 miss，进而穿透到 DB，DB 的压力就会明显上升，由于 DB 的性能较差，只在缓存的 1%~2% 以下，这样请求的慢查率会明显上升。这就是缓存失效的问题。

**失效的原因：**  
系统会一次性将大量数据加载到缓存，如果缓存写入时，过期时间按照预先设置的过期值，那过期时间到期后，系统就会因大量数据缓存失效出现变慢的问题。

**解决方法：**  
对于批量 key 缓存失效的问题，原因既然是预置的固定过期时间，那解决方案也从这里入手。设计缓存的过期时间时，使用公式：过期时间=baes 时间+随机时间。即相同业务数据写缓存时，在基础过期时间之上，再加一个随机的过期时间，让数据在未来一段时间内慢慢过期，避免瞬时全部过期，对 DB 造成过大压力

### 缓存穿透 ###

缓存穿透，则意味着有特殊访客在查询一个不存在的 key，导致每次查询都会穿透到 DB，如果这个特殊访客再控制一批肉鸡机器，持续访问你系统里不存在的 key，就会对 DB 产生很大的压力，从而影响正常服务。

缓存穿透存在的原因，就是因为我们在系统设计时，更多考虑的是正常访问路径，对特殊访问路径、异常访问路径考虑相对欠缺。

缓存穿透的业务场景很多，比如通过不存在的 UID 访问用户，通过不存在的车次 ID 查看购票信息。用户输入错误，偶尔几个这种请求问题不大，但如果是大量这种请求，就会对系统影响非常大。

那么如何解决这种问题呢？

第一种方案就是，查询这些不存在的数据时，第一次查 DB，虽然没查到结果返回 NULL，仍然记录这个 key 到缓存，只是这个 key 对应的 value 是一个特殊设置的值。

第二种方案是，构建一个 BloomFilter 缓存过滤器，记录全量数据，这样访问数据时，可以直接通过 BloomFilter 判断这个 key 是否存在，如果不存在直接返回即可，根本无需查缓存和 DB。

对于方案一，如果特殊访客持续访问大量的不存在的 key，这些 key 即便只存一个简单的默认值，也会占用大量的缓存空间，导致正常 key 的命中率下降。所以进一步的改进措施是，对这些不存在的 key 只存较短的时间，让它们尽快过期；或者将这些不存在的 key 存在一个独立的公共缓存，从缓存查找时，先查正常的缓存组件，如果 miss，则查一下公共的非法 key 的缓存，如果后者命中，直接返回，否则穿透 DB，如果查出来是空，则回种到非法 key 缓存，否则回种到正常缓存。

对方案二、BloomFilter 要缓存全量的 key，这就要求全量的 key 数量不大，10亿 条数据以内最佳，因为 10亿 条数据大概要占用 1.2GB 的内存。也可以用 BloomFilter 缓存非法 key，每次发现一个 key 是不存在的非法 key，就记录到 BloomFilter 中，这种记录方案，会导致 BloomFilter 存储的 key 持续高速增长，为了避免记录 key 太多而导致误判率增大，需要定期清零处理。

> BloomFilter 是一个非常有意思的数据结构，不仅仅可以挡住非法 key 攻击，还可以低成本、高性能地对海量数据进行判断.BloomFilter 的目的是检测一个元素是否存在于一个集合内。它的原理，是用 bit 数据组来表示一个集合，对一个 key 进行多次不同的 Hash 检测，如果所有 Hash 对应的 bit 位都是 1，则表明 key 非常大概率存在，平均单记录占用 1.2 字节即可达到 99%，只要有一次 Hash 对应的 bit 位是 0，就说明这个 key 肯定不存在于这个集合内。

### 缓存雪崩 ###

缓存雪崩是指部分缓存节点不可用，导致整个缓存体系甚至甚至服务系统不可用的情况。缓存雪崩按照缓存是否 rehash（即是否漂移）分两种情况：**缓存不支持 rehash 导致的系统雪崩不可用，缓存支持 rehash 导致的缓存雪崩不可用。**  
缓存不进行 rehash 时产生的雪崩，一般是由于较多缓存节点不可用，请求穿透导致 DB 也过载不可用，最终整个系统雪崩不可用的。而缓存支持 rehash 时产生的雪崩，则大多跟流量洪峰有关，流量洪峰到达，引发部分缓存节点过载 Crash，然后因 rehash 扩散到其他缓存节点，最终整个缓存体系异常。  
预防缓存雪崩，这里给出 3 个解决方案。

方案一，对业务 DB 的访问增加读写开关，当发现 DB 请求变慢、阻塞，慢请求超过阀值时，就会关闭读开关，部分或所有读 DB 的请求进行 failfast 立即返回，待 DB 恢复后再打开读开关，如下图  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 3]

方案二，对缓存增加多个副本，缓存异常或请求 miss 后，再读取其他缓存副本，而且多个缓存副本尽量部署在不同机架，从而确保在任何情况下，缓存系统都会正常对外提供服务。

方案三，对缓存体系进行实时监控，当请求访问的慢速比超过阀值时，及时报警，通过机器替换、服务替换进行及时恢复；也可以通过各种自动故障转移策略，自动关闭异常接口、停止边缘服务、停止部分非核心功能措施，确保在极端场景下，核心功能的正常运行。

### 缓存数据不一致 ###

同一份数据，可能会同时存在 DB 和缓存之中。那就有可能发生，DB 和缓存的数据不一致。如果缓存有多个副本，多个缓存副本里的数据也可能会发生不一致现象。

**原因分析**  
不一致的问题大多跟缓存更新异常有关。比如更新 DB 后，写缓存失败，从而导致缓存中存的是老数据。另外，如果系统采用一致性 Hash 分布，同时采用 rehash 自动漂移策略，在节点多次上下线之后，也会产生脏数据。缓存有多个副本时，更新某个副本失败，也会导致这个副本的数据是老数据。

**解决方案**  
要尽量保证数据的一致性。这里也给出了 3 个方案，可以根据实际情况进行选择。

第一个方案，cache 更新失败后，可以进行重试，如果重试失败，则将失败的 key 写入队列机服务，待缓存访问恢复后，将这些 key 从缓存删除。这些 key 在再次被查询时，重新从 DB 加载，从而保证数据的一致性。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 4]

第二个方案，缓存时间适当调短，让缓存数据及早过期后，然后从 DB 重新加载，确保数据的最终一致性。

第三个方案，不采用 rehash 漂移策略，而采用缓存分层策略，尽量避免脏数据产生。

### 数据并发竞争 ###

数据并发竞争，是指在高并发访问场景，一旦缓存访问没有找到数据，大量请求就会并发查询 DB，导致 DB 压力大增的现象。主要是由于多个进程/线程中，有大量并发请求获取相同的数据，而这个数据 key 因为正好过期、被剔除等各种原因在缓存中不存在，这些进程/线程之间没有任何协调，然后一起并发查询 DB，请求那个相同的 key，最终导致 DB 压力大增

要解决并发竞争，有 2 种方案：

方案一是使用全局锁。如下图所示，即当缓存请求 miss 后，先尝试加全局锁，只有加全局锁成功的线程，才可以到 DB 去加载数据。其他进程/线程在读取缓存数据 miss 时，如果发现这个 key 有全局锁，就进行等待，待之前的线程将数据从 DB 回种到缓存后，再从缓存获取。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 5]  
方案二是，对缓存数据保持多个备份，即便其中一个备份中的数据过期或被剔除了，还可以访问其他备份，从而减少数据并发竞争的情况，如下图。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 6]

### Hot Key ###

Hot key 引发缓存系统异常，主要是因为突发热门事件发生时，超大量的请求访问热点事件对应的 key，比如微博中数十万、数百万的用户同时去吃一个新瓜。数十万的访问请求同一个 key，流量集中打在一个缓存节点机器，这个缓存机器很容易被打到物理网卡、带宽、CPU 的极限，从而导致缓存访问变慢、卡顿。

解决方案  
要解决这种极热 key 的问题，首先要找出这些 Hot key 来。对于重要节假日、线上促销活动、集中推送这些提前已知的事情，可以提前评估出可能的热 key 来。而对于突发事件，无法提前评估，可以通过 Spark，对应流任务进行实时分析，及时发现新发布的热点 key。而对于之前已发出的事情，逐步发酵成为热 key 的，则可以通过 Hadoop 对批处理任务离线计算，找出最近历史数据中的高频热 key。

找到热 key 后，就有很多解决办法了。首先可以将这些热 key 进行分散处理，比如一个热 key 名字叫 hotkey，可以被分散为 hotkey\#1、hotkey\#2、hotkey\#3，……hotkey\#n，这 n 个 key 分散存在多个缓存节点，然后 client 端请求时，随机访问其中某个后缀的 hotkey，这样就可以把热 key 的请求打散，避免一个缓存节点过载，如下图所示。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 7]  
其次，也可以 key 的名字不变，对缓存提前进行多副本+多级结合的缓存架构设计。

再次，如果热 key 较多，还可以通过监控体系对缓存的 SLA 实时监控，通过快速扩容来减少热 key 的冲击。

最后，业务端还可以使用本地缓存，将这些热 key 记录在本地缓存，来减少对远程缓存的冲击。

### Big key ###

大 key，是指在缓存访问时，部分 Key 的 Value 过大，读写、加载易超时的现象。  
**解决方法：**  
第一种方案，如果数据存在 Mc 中，可以设计一个缓存阀值，当 value 的长度超过阀值，则对内容启用压缩，让 KV 尽量保持小的 size，其次评估大 key 所占的比例，在 Mc 启动之初，就立即预写足够数据的大 key，让 Mc 预先分配足够多的 trunk size 较大的 slab。确保后面系统运行时，大 key 有足够的空间来进行缓存。  
第二种方案时，如下图所示，将大 key 分拆为多个 key，尽量减少大 key 的存在。同时由于大 key 一旦穿透到 DB，加载耗时很大，所以可以对这些大 key 进行特殊照顾，比如设置较长的过期时间，比如缓存内部在淘汰 key 时，同等条件下，尽量不淘汰这些大 key。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 8]

# redis 基础知识 #

## 什么是Redis？ ##

Redis(Remote Dictionary Server) 是一个使用 C 语言编写的、开源的、高性能非关系型（NoSQL）的键值对数据库。

Redis 可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值支持五种数据类型：String（字符串），List（列表），Set（无序集合），ZSet（有序集合），Hash（无序散列表）。具体类型使用可看见[这篇文章][Link 1]

与传统数据库不同的是 Redis 的数据是存在内存中的，读写速度非常快，因此 redis 被广泛应用于缓存方向。另外，Redis 也经常用来做分布式锁。除此之外，Redis 支持事务 、持久化、LUA脚本、多种集群方案。

## redis的优缺点? ##

**优点**

*  读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。
 *  支持数据持久化，支持AOF和RDB两种持久化方式。线上 Redis 一般会同时使用两种方式，通过开启 appendonly 及关联配置项，将写命令及时追加到 AOF 文件，同时在每日流量低峰时，通过 bgsave 保存当时所有内存数据快照。
 *  支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。
 *  数据结构丰富，除了支持string类型的value外还支持hash、set、zset、list等数据结构。
 *  支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。
 *  单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能。
 *  比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的memcached来用

**缺点**

*  数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
 *  Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
 *  主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
 *  Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

## redis为什么是单线程的？ ##

Redis 一般被看作单进程/单线程组件，因为 Redis 的网络 IO 和命令处理，属于是io密集型的操作，Redis 基于 Epoll 事件模型开发，可以进行非阻塞网络 IO，同时由于单线程命令处理，整个处理过程不存在竞争，不需要加锁，没有上下文切换开销，所有数据操作都是在内存中操作，所以 Redis 的性能很高，单个实例即可以达到 10w 级的 QPS。核心线程除了负责网络 IO 及命令处理外，还负责写数据到缓冲，以方便将最新写操作同步到 AOF、slave。

其实redis也不完全是单线程，redis只是处理核心是单线程的，还会存在其他的辅助线程。  
![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SBuL2BRe-1598337789730)(https://raw.githubusercontent.com/zhaozhen197/my\_markdown\_img/master/CgotOV2lPF-AZtVrAABZ5Cio\_aE709.png)\]][img-SBuL2BRe-1598337789730_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgotOV2lPF-AZtVrAABZ5Cio_aE709.png]

## redis比memcached的优势在哪里？以及两者的区别？ ##

**优势**

*  memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型
 *  redis的速度比memcached快很多
 *  redis支持事务。
 *  redis可以持久化其数据

**区别**

1.  redis可以看做是一个内存型的非关系数据库，memcached只是一个缓存工具。
2.  redis的数据类型比memcached丰富。redis的数据类型有string,list,set,zset hash.memcached只有字符串和二进制数据两种类型。
3.  redis的命令库更加丰富。支持批量操作 、事务支持 、每个类型不同的CRUD。memcached只是支持常用的CURD以及其他少量的其他命令。
4.  redis支持原生的集群模式。memcached如果要实现集群模式，就要依靠客户端的配合才行。
5.  redis支持持久化。memcached不支持。
6.  在 Redis 中，并不是所有数据都一直存储在内存中，可以将一些很久没用的 value 交换到磁盘。Memcached 的数据则会一直在内存中，Memcached 将内存分割成特定长度的块来存储数据，以完全解决内存碎片的问题。但是这种方式会使得内存的利用率不高，例如块的大小为 128 bytes，只存储 100 bytes 的数据，那么剩下的 28 bytes 就浪费掉了。

## redis的基本数据结构 ##

*  string 字符串类型:

string 是 Redis 的最基本数据类型。string 类型是二进制安全的，即 string 中可以包含任何数据。

Redis 中的普通 string 采用 raw encoding 即原始编码方式，该编码方式会动态扩容，并通过提前预分配冗余空间，来减少内存频繁分配的开销。在字符串长度小于 1MB 时，按所需长度的 2 倍来分配，超过 1MB，则按照每次额外增加 1MB 的容量来预分配。

Redis 中的数字也存为 string 类型，但编码方式跟普通 string 不同，数字采用整型编码，字符串内容直接设为整数值的二进制字节序列。

*  list 列表类型:

Redis 的 list 列表，是一个快速双向链表，存储了一系列的 string 类型的字串值。list 中的元素按照插入顺序排列

*  set 集合类型:

set 是 string 类型的无序集合，set 中的元素是唯一的，即 set 中不会出现重复的元素。Redis 中的集合一般是通过 dict 哈希表实现的，所以插入、删除，以及查询元素，可以根据元素 hash 值直接定位，时间复杂度为 O(1)。redis的哈希表的制作使用的是`拉链法`。

*  sorted set 有序集合类型:

Redis 中的 sorted set 有序集合也称为 zset，有序集合同 set 集合类似，也是 string 类型元素的集合，且所有元素不允许重复。

但有序集合中，每个元素都会关联一个 double 类型的 score 分数值。有序集合通过这个 score 值进行由小到大的排序。有序集合中，元素不允许重复，但 score 分数值却允许重复。

*  hash 类型；

Redis 中的哈希实际是 field 和 value 的一个映射表。

hash 数据结构的特点是在单个 key 对应的哈希结构内部，可以记录多个键值对，即 field 和 value 对，value 可以是任何字符串。而且这些键值对查询和修改很高效。

*  bitmap 位图类型；

Redis 中的 bitmap 位图是一串连续的二进制数字，底层实际是基于 string 进行封装存储的，按 bit 位进行指令操作的。bitmap 位图的特点是按位设置、求与、求或等操作很高效，而且存储成本非常低，用来存对象标签属性的话，一个 bit 即可存一个标签。可以用 bitmap，存用户最近 N 天的登录情况，每天用 1 bit，登录则置 1。个性推荐在社交应用中非常重要，可以对新闻、feed 设置一系列标签，如军事、娱乐、视频、图片、文字等，用 bitmap 来存储这些标签，在对应标签 bit 位上置 1。对用户，也可以采用类似方式，记录用户的多种属性，并可以很方便的根据标签来进行多维度统计

*  geo 地理位置类型

Redis 的 GEO 地理位置本质上是基于 sorted set 封装实现的。在存储分类 key 下的地理位置信息时，需要对该分类 key 构建一个 sorted set 作为内部存储结构，用于存储一系列位置点。Redis 的 GEO 地理位置数据结构，应用场景很多，比如查询某个地方的具体位置，查当前位置到目的地的距离，查附近的人、餐厅、电影院等。

*  HyperLogLog 基数统计类型。

Redis 的 hyperLogLog 是用来做基数统计的数据类型，当输入巨大数量的元素做统计时，只需要很小的内存即可完成。HyperLogLog 不保存元数据，只记录待统计元素的估算数量，这个估算数量是一个带有 0.81% 标准差的近似值，在大多数业务场景，对海量数据，不足 1% 的误差是可以接受的。

Redis 的 HyperLogLog 在统计时，如果计数数量不大，采用稀疏矩阵存储，随着计数的增加，稀疏矩阵占用的空间也会逐渐增加，当超过阀值后，则改为稠密矩阵，稠密矩阵占用的空间是固定的，约为12KB字节。

hyperLogLog 的特点是统计过程不记录独立元素，占用内存非常少，非常适合统计海量数据。在大中型系统中，统计每日、每月的 UV 即独立访客数，或者统计海量用户搜索的独立词条数，都可以用 hyperLogLog 数据类型来进行处理。

## redis底层的数据结构 ##

Redis 中所有数据都保存在 DB 中，一个 Redis 默认最多支持 16 个 DB。Redis 中的每个 DB 都对应一个 redisDb 结构，即每个 Redis 实例，默认有 16 个 redisDb。用户访问时，默认使用的是 0 号 DB，可以通过 select $dbID 在不同 DB 之间切换。

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uiZ5bPCr-1598337789733)(https://raw.githubusercontent.com/zhaozhen197/my\_markdown\_img/master/CgoB5l28Bx6AUzW7AACuWHuW1yQ159.png)\]][img-uiZ5bPCr-1598337789733_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgoB5l28Bx6AUzW7AACuWHuW1yQ159.png]

redisDb 主要包括 2 个核心 dict 字典、3 个非核心 dict 字典、dbID 和其他辅助属性。2 个核心 dict 包括一个 dict 主字典和一个 expires 过期字典。主 dict 字典用来存储当前 DB 中的所有数据，它将 key 和各种数据类型的 value 关联起来，该 dict 也称 key space。过期字典用来存储过期时间 key，存的是 key 与过期时间的映射。日常的数据存储和访问基本都会访问到 redisDb 中的这两个 dict。

3 个非核心 dict 包括一个字段名叫 blocking\_keys 的阻塞 dict，一个字段名叫 ready\_keys 的解除阻塞 dict，还有一个是字段名叫 watched\_keys 的 watch 监控 dict。在执行 Redis 中 list 的阻塞命令 blpop、brpop 或者 brpoplpush 时，如果对应的 list 列表为空，Redis 就会将对应的 client 设为阻塞状态，同时将该 client 添加到 DB 中 blocking\_keys 这个阻塞 dict。所以该 dict 存储的是处于阻塞状态的 key 及 client 列表。

### redisObject ###

redisObject 由 5 个字段组成。

*  type：即 Redis 对象的数据类型，目前支持 7 种 type 类型
 *  encoding：Redis 对象的内部编码方式，即内部数据结构类型，目前支持 10 种编码方式
 *  LRU：存储的是淘汰数据用的 LRU 时间或 LFU 频率及时间的数据。
 *  refcount：记录 Redis 对象的引用计数，用来表示对象被共享的次数，共享使用时加 1，不再使用时减 1，当计数为 0 时表明该对象没有被使用，就会被释放，回收内存。
 *  ptr：它指向对象的内部数据结构。比如一个代表 string 的对象，它的 ptr 可能指向一个 sds 或者一个 long 型整数。

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jeonRrtW-1598337789737)(https://raw.githubusercontent.com/zhaozhen197/my\_markdown\_img/master/CgoB5l28Bx6AVwGxAAEKF2oxItk727-20200824212419623.png)\]][img-jeonRrtW-1598337789737_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgoB5l28Bx6AVwGxAAEKF2oxItk727-20200824212419623.png]

Redis中有5种对象类型

<table> 
 <thead> 
  <tr> 
   <th align="left">类型常量</th> 
   <th align="left">对象的名称</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left"><code>REDIS_STRING</code></td> 
   <td align="left">字符串对象</td> 
  </tr> 
  <tr> 
   <td align="left"><code>REDIS_LIST</code></td> 
   <td align="left">列表对象</td> 
  </tr> 
  <tr> 
   <td align="left"><code>REDIS_HASH</code></td> 
   <td align="left">哈希对象</td> 
  </tr> 
  <tr> 
   <td align="left"><code>REDIS_SET</code></td> 
   <td align="left">集合对象</td> 
  </tr> 
  <tr> 
   <td align="left"><code>REDIS_ZSET</code></td> 
   <td align="left">有序集合对象</td> 
  </tr> 
 </tbody> 
</table>

/* * Redis 对象 */
    typedef struct redisObject { 
     
        // 类型
        unsigned type:4;        
     
        // 不使用(对齐位)
        unsigned notused:2;
     
        // 编码方式
        unsigned encoding:4;
     
        // LRU 时间（相对于 server.lruclock）
        unsigned lru:22;
     
        // 引用计数
        int refcount;
     
        // 指向对象的值
        void *ptr;
     
    } robj;

type表示了该对象的对象类型，即上面五个中的一个。但为了提高存储效率与程序执行效率，每种对象的底层数据结构实现都可能不止一种。encoding就表示了对象底层所使用的编码。下面先介绍每种底层数据结构的实现，再介绍每种对象类型都用了什么底层结构并分析他们之间的关系。

<table> 
 <thead> 
  <tr> 
   <th align="left">编码常量</th> 
   <th align="left">编码所对应的底层数据结构</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left"><code>REDIS_ENCODING_INT</code></td> 
   <td align="left"><code>long</code> 类型的整数</td> 
  </tr> 
  <tr> 
   <td align="left"><code>REDIS_ENCODING_EMBSTR</code></td> 
   <td align="left"><code>embstr</code> 编码的简单动态字符串</td> 
  </tr> 
  <tr> 
   <td align="left"><code>REDIS_ENCODING_RAW</code></td> 
   <td align="left">简单动态字符串</td> 
  </tr> 
  <tr> 
   <td align="left"><code>REDIS_ENCODING_HT</code></td> 
   <td align="left">字典</td> 
  </tr> 
  <tr> 
   <td align="left"><code>REDIS_ENCODING_LINKEDLIST</code></td> 
   <td align="left">双端链表</td> 
  </tr> 
  <tr> 
   <td align="left"><code>REDIS_ENCODING_ZIPLIST</code></td> 
   <td align="left">压缩列表</td> 
  </tr> 
  <tr> 
   <td align="left"><code>REDIS_ENCODING_INTSET</code></td> 
   <td align="left">整数集合</td> 
  </tr> 
  <tr> 
   <td align="left"><code>REDIS_ENCODING_SKIPLIST</code></td> 
   <td align="left">跳跃表和字典</td> 
  </tr> 
 </tbody> 
</table>

### 字符串对象 ###

字符串对象的编码可以是int、raw或者embstr。  
如果一个字符串的内容可以转换为long，那么该字符串就会被转换成为long类型，对象的ptr就会指向该long，并且对象类型也用int类型表示。  
普通的字符串有两种，embstr和raw。embstr应该是Redis 3.0新增的数据结构,在2.8中是没有的。如果字符串对象的长度小于39字节，就用embstr对象。否则用传统的raw对象。

**embstr的好处有如下几点：**

*  embstr的创建只需分配一次内存，而raw为两次（一次为sds分配对象，另一次为objet分配对象，embstr省去了第一次）。相对地，释放内存的次数也由两次变为一次。
 *  embstr的objet和sds放在一起，更好地利用缓存带来的优势。

#### Sds ####

字符串是 Redis 中最常见的数据类型，其底层实现是简单动态字符串即 sds。简单动态字符串本质是一个 char\*，内部通过 sdshdr 进行管理。sdshdr 有 4 个字段。len 为字符串实际长度，alloc 当前字节数组总共分配的内存大小。flags 记录当前字节数组的属性；buf 是存储字符串真正的值及末尾一个 \\0。sds 的存储 buf 可以动态扩展或收缩，字符串长度不用遍历，可直接获得，修改和访问都很方便。由于 sds 中字符串存在 buf 数组中，长度由 len 定义，而不像传统字符串遇 0 停止，所以 sds 是二进制安全的，可以存放任何二进制的数据。

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nZg7t6Q6-1598337789742)(https://raw.githubusercontent.com/zhaozhen197/my\_markdown\_img/master/CgoB5l28Bx-ARu4ZAACk1VRWcR4166.png)\]][img-nZg7t6Q6-1598337789742_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgoB5l28Bx-ARu4ZAACk1VRWcR4166.png]

sds 相比传统字符串多了一个 sdshdr，对于大量很短的字符串，这个 sdshdr 还是一个不小的开销。在 3.2 版本后，sds 会根据字符串实际的长度，选择不同的数据结构，以更好的提升内存效率。当前 sdshdr 结构分为 5 种子类型，分别为 sdshdr5、sdshdr8、sdshdr16、sdshdr32、sdshdr64。其中 sdshdr5 只有 flags 和 buf 字段，其他几种类型的 len 和 alloc 采用从 uint8\_t 到 uint64\_t 的不同类型，以节省内存空间。

sds 可以作为字符串的内部数据结构，同时 sds 也是 hyperloglog、bitmap 类型的内部数据结构。

### 列表对象 ###

列表对象的编码可以是ziplist或者linkedlist，现在主要是quicklist。

#### ziplist ####

ziplist是一种压缩链表，它的好处是更能节省内存空间，因为它所存储的内容都是在连续的内存区域当中的。当列表对象元素不大，每个元素也不大的时候，就采用ziplist存储。但当数据量过大时就ziplist就不是那么好用了。因为为了保证他存储内容在内存中的连续性，插入的复杂度是O(N)，即每次插入都会重新进行realloc。如下图所示，对象结构中ptr所指向的就是一个ziplist。整个ziplist只需要malloc一次，它们在内存中是一块连续的区域。

![x][]

linkedlist是一种双向链表。它的结构比较简单，节点中存放pre和next两个指针，还有节点相关的信息。当每增加一个node的时候，就需要重新malloc一块内存。

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1URGEJS0-1598337789747)(https://raw.githubusercontent.com/zhaozhen197/my\_markdown\_img/master/Center-20200824130312240.png)\]][img-1URGEJS0-1598337789747_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_Center-20200824130312240.png]

#### quicklist ####

Redis 在 3.2 版本之后引入 quicklist，用以替换 linkedlist。因为 linkedlist 每个节点有前后指针，要占用 16 字节，而且每个节点独立分配内存，很容易加剧内存的碎片化。而 ziplist 由于紧凑型存储，增加元素需要 realloc，删除元素需要内存拷贝，天然不适合元素太多、value 太大的存储。而 quicklist 快速列表应运而生，它是一个基于 ziplist 的双向链表。将数据分段存储到 ziplist，然后将这些 ziplist 用双向指针连接。快速列表从头尾读写数据很快，时间复杂度为 O(1)。也支持从中间任意位置插入或读写元素，但速度较慢，时间复杂度为 O(n)。快速列表当前主要作为 list 列表的内部数据结构。

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bUoJEHpL-1598337789749)(https://raw.githubusercontent.com/zhaozhen197/my\_markdown\_img/master/CgoB5l28ByCADkuqAACua3XXug4030.png)\]][img-bUoJEHpL-1598337789749_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgoB5l28ByCADkuqAACua3XXug4030.png]

### 哈希对象 ###

哈希对象的底层实现可以是ziplist或者dict字典。对于哈希类型，如果元素数小于 512，并且元素长度小于 64，则用 ziplist 存储，否则使用 dict 字典存储。

ziplist中的哈希对象是按照key1,value1,key2,value2这样的顺序存放来存储的。当对象数目不多且内容不大时，这种方式效率是很高的。其中 hash 使用 ziplist 作为内部数据结构的限制时，元素数默认不超过 512 个，value 值默认不超过 64 字节。可以通过修改配置来调整 hash\_max\_ziplist\_entries 、hash\_max\_ziplist\_value 这两个阀值的大小。

#### dict ####

Redis 中的 dict，类似于 Memcached 中 hashtable。都可以用于 key 或元素的快速插入、更新和定位。dict 字典中，有一个长度为 2 的哈希表数组，日常访问用 0 号哈希表，如果 0 号哈希表元素过多，则分配一个 2 倍 0 号哈希表大小的空间给 1 号哈希表，然后进行逐步迁移，rehashidx 这个字段就是专门用来做标志迁移位置的。在哈希表操作中，采用单向链表来解决 hash 冲突问题。dict 中还有一个重要字段是 type，它用于保存 hash 函数及 key/value 赋值、比较函数。

由dict这个结构来实现的

typedef struct dict { 
        dictType *type;
        void *privdata;
        dictht ht[2];
        long rehashidx; /* rehashing not in progress if rehashidx == -1 */
        int iterators; /* number of iterators currently running */
    } dict;

dict是一个字典，其中的指针dicht ht\[2\] 指向了两个哈希表

typedef struct dictht { 
        dictEntry **table;
        unsigned long size;
        unsigned long sizemask;
        unsigned long used;
    } dictht;

dicht\[0\] 是用于真正存放数据，dicht\[1\]一般在哈希表元素过多进行rehash的时候用于中转数据。

dictht中的table用语真正存放元素了，每个key/value对用一个dictEntry表示，放在dictEntry数组中。  
![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jftdtrbx-1598337789751)(https://raw.githubusercontent.com/zhaozhen197/my\_markdown\_img/master/Center-20200824130530842.png)\]][img-jftdtrbx-1598337789751_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_Center-20200824130530842.png]

### 集合对象 ###

集合对象的编码可以是intset或者dict。主要用的是dict。

intset是一个整数集合，里面存的为某种同一类型的整数，支持如下三种长度的整数：

#define INTSET_ENC_INT16 (sizeof(int16_t))
    #define INTSET_ENC_INT32 (sizeof(int32_t))
    #define INTSET_ENC_INT64 (sizeof(int64_t))

intset是一个有序集合，查找元素的复杂度为O(logN)，但插入时不一定为O(logN)，因为有可能涉及到升级操作。比如当集合里全是int16\_t型的整数，这时要插入一个int32\_t，那么为了维持集合中数据类型的一致，那么所有的数据都会被转换成int32\_t类型，涉及到内存的重新分配，这时插入的复杂度就为O(N)了。是intset不支持降级操作。

### 有序集合对象 ###

在 sorted set 数据类型中，如果元素数较多或元素长度较大，则使用跳跃表作为内部数据结构。默认元素数超过 128 或者最大元素的长度超过 64，此时有序集合就采用 zskiplist 进行存储。由于 geo 也采用有序集合类型来存储地理位置名称和位置 hash 值，所以在超过相同阀值后，也采用跳跃表进行存储。

zset 有序集合，当使用 ziplist 作为内部数据结构的限制元素数默认不超过 128 个，value 值默认不超过 64 字节。可以通过修改配置来调整 zset\_max\_ziplist\_entries 和 zset\_max\_ziplist\_value 这两个阀值的大小。ziplist作为集合和作为哈希对象是一样的，member和score顺序存放。按照score从小到大顺序排列。它的结构不再复述。

跳跃表 zskiplist 是一种有序数据结构，它通过在每个节点维持多个指向其他节点的指针，从而可以加速访问。跳跃表支持平均 O(logN) 和最差 O(n) 复杂度的节点查找。在大部分场景，跳跃表的效率和平衡树接近，但跳跃表的实现比平衡树要简单，所以不少程序都用跳跃表来替换平衡树。

它的结构比较特殊。下面分别是跳跃表skiplist和它内部的节点skiplistNode的结构体：

/* * 跳跃表 */
    typedef struct zskiplist { 
        // 头节点，尾节点
        struct zskiplistNode *header, *tail;
        // 节点数量
        unsigned long length;
        // 目前表内节点的最大层数
        int level;
    } zskiplist;
    /* ZSETs use a specialized version of Skiplists */
    /* * 跳跃表节点 */
    typedef struct zskiplistNode { 
        // member 对象
        robj *obj;
        // 分值
        double score;
        // 后退指针
        struct zskiplistNode *backward;
        // 层
        struct zskiplistLevel { 
            // 前进指针
            struct zskiplistNode *forward;
            // 这个层跨越的节点数量
            unsigned int span;
        } level[];
    } zskiplistNode;

head和tail分别指向头节点和尾节点，然后每个skiplistNode里面的结构又是分层的(即level数组)

用图表示，大概是下面这个样子：

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ahA0qdfI-1598337789751)(https://raw.githubusercontent.com/zhaozhen197/my\_markdown\_img/master/Center-20200824130739558.png)\]][img-ahA0qdfI-1598337789751_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_Center-20200824130739558.png]

每一列都代表一个节点，保存了member和score，按score从小到大排序。每个节点有不同的层数，这个层数是在生成节点的时候随机生成的数值。每一层都是一个指向后面某个节点的指针。这种结构使得跳跃表可以跨越很多节点来快速访问。

typedef struct zset { 
        // 字典
        dict *dict;
        // 跳跃表
        zskiplist *zsl;
    } zset;

为什么要用这种结构呢。试想如果单一用hashtable，那可以快速查找、添加和删除元素，但没法保持集合的有序性。如果单一用skiplist，有序性可以得到保障，但查找的速度太慢O（logN）。

### hyperloglog ###

对于 hyperloglog，采用 sds 简单动态字符串存储。

### GEO ###

对于 geo，如果位置数小于 128，则使用 ziplist 存储，否则使用 zskiplist 存储。

### bitmap ###

bitmap，采用 sds 简单动态字符串存储。

## Redis的协议模式 ##

Redis 设计了 RESP，即 Redis Serialization Protocol，中文意思是 Redis 序列化协议。RESP 是二进制安全协议，可以供 Redis 或其他任何 Client-Server 使用。

### 设计原则 ###

Redis 序列化协议的设计原则有三个：

*  第一是实现简单；
 *  第二是可快速解析；
 *  第三是便于阅读。

### 两种特殊模式 ###

Redis 协议的请求响应模型有三种，除了 2 种特殊模式，其他基本都是 ping-pong 模式，即 client 发送一个请求，server 回复一个响应，一问一答的访问模式。

*  pipeline 模式，即 client 一次连续发送多个请求，然后等待 server 响应，server 处理完请求后，把响应返回给 client。
 *  pub/sub 模式。即发布订阅模式，client 通过 subscribe 订阅一个 channel，然后 client 进入订阅状态，静静等待。当有消息产生时，server 会持续自动推送消息给 client，不需要 client 的额外请求。而且客户端在进入订阅状态后，只可接受订阅相关的命令如 SUBSCRIBE、PSUBSCRIBE、UNSUBSCRIBE 和 PUNSUBSCRIBE，除了这些命令，其他命令一律失效。

### 响应格式 ###

Redis 协议的响应格式有 5 种，分别是：

*  simple strings 简单字符串类型，以 + 开头，后面跟字符串，以 CRLF（即 \\r\\n）结尾。这种类型不是二进制安全类型，字符串中不能包含 \\r 或者 \\n。比如许多响应回复以 OK 作为操作成功的标志，协议内容就是 +OK\\r\\n 。
 *  Redis 协议将错误作为一种专门的类型，格式同简单字符串类型，唯一不同的是以 -（减号）开头。Redis 内部实现对 Redis 协议做了进一步规范，减号后面一般先跟 ERR 或者 WRONGTYPE，然后再跟其他简单字符串，最后以 CRLF（回车换行）结束。这里给了两个示例，client 在解析响应时，一旦发现 - 开头，就知道收到 Error 响应。
 *  Integer 整数类型。整数类型以 ：开头，后面跟字符串表示的数字，最后以回车换行结尾。Redis 中许多命令都返回整数，但整数的含义要由具体命令来确定。比如，对于 incr 指令，：后的整数表示变更后的数值；对于 llen 表示 list 列表的长度，对于 exists 指令，1 表示 key 存在，0 表示 key 不存在。这里给个例子，：后面跟了个 1000，然后回车换行结束。
 *  bulk strings 字符串块类型。字符串块分头部和真正字符串内容两部分。字符串块类型的头部， 为 $ 开头，随后跟真正字符串内容的字节长度，然后以 CRLF 结尾。字符串块的头部之后，跟随真正的字符串内容，最后以 CRLF 结束字符串块。字符串块用于表示二进制安全的字符串，最大长度可以支持 512MB。一个常规的例子，“$6\\r\\nfoobar\\r\\n”，对于空字串，可以表示为 “KaTeX parse error: Can't use function '\\r' in math mode at position 2: 0\\̲r̲\\n\\r\\n”，NULL字串：…\-1\\r\\n”。
 *  Arrays 数组类型，如果一个命令需要返回多条数据就需要用数组格式类型，另外，前面提到 client 的请求命令也是主要采用这种格式。

### 协议分类 ###

Redis 协议主要分为 16 种，其中 8 种协议对应前面我们讲到的 8 种数据类型，你选择了使用什么数据类型，就使用对应的响应操作指令即可。剩下 8 种协议如下所示。

*  pub-sub 发布订阅协议，client 可以订阅 channel，持续等待 server 推送消息。
 *  事务协议，事务协议可以用 multi 和 exec 封装一些列指令，来一次性执行。
 *  脚本协议，关键指令是 eval、evalsha 和 script等。
 *  连接协议，主要包括权限控制，切换 DB，关闭连接等。
 *  复制协议，包括 slaveof、role、psync 等。
 *  配置协议，config set/get 等，可以在线修改/获取配置。
 *  调试统计协议，如 slowlog，monitor，info 等。
 *  其他内部命令，如 migrate，dump，restore 等。

## Redis事件处理机制 ##

Redis 中的事件处理模块，采用的是作者自己开发的 ae 事件驱动模型，可以进行高效的网络 IO 读写、命令执行，以及时间事件处理。

其中，网络 IO 读写处理采用的是 IO 多路复用技术，通过对 evport、epoll、kqueue、select 等进行封装，同时监听多个 socket，并根据 socket 目前执行的任务，来为 socket 关联不同的事件处理器。

当监听端口对应的 socket 收到连接请求后，就会创建一个 client 结构，通过 client 结构来对连接状态进行管理。在请求进入时，将请求命令读取缓冲并进行解析，并存入到 client 的参数列表。

然后根据请求命令找到 对应的redisCommand ，最后根据命令协议，对请求参数进一步的解析、校验并执行。Redis 中时间事件比较简单，目前主要是执行 serverCron，来做一些统计更新、过期 key 清理、AOF 及 RDB 持久化等辅助操作。

### Redis 事件驱动模型 ###

Redis 的事件驱动模型处理 2 类事件：

*  文件事件，如连接建立、接受请求命令、发送响应等；
 *  时间事件，如 Redis 中定期要执行的统计、key 淘汰、缓冲数据写出、rehash等。

### 文件事件处理 ###

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FASnDClJ-1598337789752)(https://raw.githubusercontent.com/zhaozhen197/my\_markdown\_img/master/CgoB5l2yv6iAb3V5AACx5LFCsHM346.png)\]][img-FASnDClJ-1598337789752_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgoB5l2yv6iAb3V5AACx5LFCsHM346.png]

Redis 的文件事件采用典型的 Reactor 模式进行处理。Redis 文件事件处理机制分为 4 部分：

*  连接 socket
 *  IO 多路复用程序
 *  文件事件分派器
 *  事件处理器

## redis的持久化策略？ ##

Redis 是内存型数据库，为了之后重用数据（比如重启机器、机器故障之后回复数据），或者是为了防止系统故障而将数据备份到一个远程位置，需要将内存中的数据持久化到硬盘上。Redis 提供了RDB和AOF两种持久化方式。默认是只开启RDB，当Redis重启时，它会优先使用AOF文件来还原数据集。

*  RDB持久化方式

Redis 的 RDB 持久化是以快照的方式将内存数据存储到磁盘。在需要进行 RDB 持久化时，Redis 会将内存中的所有数据以二进制的格式落地，每条数据存储的内容包括过期时间、数据类型、key，以及 value。**当 Redis 重启时，如果 appendonly 关闭，则会读取 RDB 持久化生成的二进制文件进行数据恢复。**

触发构建 RDB 的场景主要有以下四种。

*  第一种场景是通过 save 或 bgsave 命令进行主动 RDB 快照构建。它是由调用方调用 save 或 bgsave 指令进行触发的。
 *  第二种场景是利用配置 save m n 来进行自动快照生成。它是指在 m 秒中，如果插入或变更 n 个 key，则自动触发 bgsave。这个配置可以设置多个配置行，以便组合使用。由于峰值期间，Redis 的压力大，变更的 key 也比较多，如果再进行构建 RDB 的操作，会进一步增加机器负担，对调用方请求会有一定的影响，所以线上使用时需要谨慎。
 *  第三种场景是主从复制，如果从库需要进行全量复制，此时主库也会进行 bgsave 生成一个 RDB 快照。
 *  第四种场景是在运维执行 flushall 清空所有数据，或执行 shutdown 关闭服务时，也会触发 Redis 自动构建 RDB 快照。

save 是在主进程中进行 RDB 持久化的，持久化期间 Redis 处于阻塞状态，不处理任何客户请求，所以一般使用较少。而 bgsave 是 fork 一个子进程，然后在子进程中构建 RDB 快照，构建快照的过程不直接影响用户的访问，但仍然会增加机器负载。线上 Redis 快照备份，一般会选择凌晨低峰时段，通过 bgsave 主动触发进行备份。

#在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
    save 900 1

创建快照的办法有如下几种：
    BGSAVE命令 ：客户端向Redis发送 BGSAVE命令 来创建一个快照。对于支持BGSAVE命令的平台来说（基本上所有平台支持，除了Windows平台），Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求。
    SAVE命令 ：客户端还可以向Redis发送 SAVE命令 来创建一个快照，接到SAVE命令的Redis服务器在快照创建完毕之前不会再响应任何其他命令。SAVE命令不常用，我们通常只会在没有足够内存去执行BGSAVE命令的情况下，又或者即使等待持久化操作执行完毕也无所谓的情况下，才会使用这个命令。
    save选项 ：如果用户设置了save选项（一般会默认设置），比如 save 60 10000，那么从Redis最近一次创建快照之后开始算起，当“60秒之内有10000次写入”这个条件被满足时，Redis就会自动触发BGSAVE命令。
    SHUTDOWN命令 ：当Redis通过SHUTDOWN命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执行一个SAVE命令，阻塞所有客户端，不再执行客户端发送的任何命令，并在SAVE命令执行完毕之后关闭服务器。
    一个Redis服务器连接到另一个Redis服务器：当一个Redis服务器连接到另一个Redis服务器，并向对方发送SYNC命令来开始一次复制操作的时候，如果主服务器目前没有执行BGSAVE操作，或者主服务器并非刚刚执行完BGSAVE操作，那么主服务器就会执行BGSAVE命令

*  AOF 持久化

开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。使用 AOF 持久化需要设置同步选项，从而确定写命令同步到磁盘文件上的时机。这是因为对文件进行写入并不会马上将内容同步到磁盘上，而是先存储到缓冲区，然后由操作系统决定什么时候同步到磁盘。在Redis的配置文件中存在三种同步方式

<table> 
 <thead> 
  <tr> 
   <th align="center">选项</th> 
   <th align="center">同步频率</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="center">always</td> 
   <td align="center">每个写命令都同步，这样会严重降低Redis的速度</td> 
  </tr> 
  <tr> 
   <td align="center">everysec</td> 
   <td align="center">每秒同步一次</td> 
  </tr> 
  <tr> 
   <td align="center">no</td> 
   <td align="center">让操作系统来决定何时同步</td> 
  </tr> 
 </tbody> 
</table>

虽然AOF持久化非常灵活地提供了多种不同的选项来满足不同应用程序对数据安全的不同要求，但AOF持久化也有缺陷——AOF文件的体积太大。由于不断追加，AOF 会记录数据大量的中间状态，AOF 文件会变得非常大，此时，可以通过 bgrewriteaof 指令，对 AOF 进行重写，只保留数据的最后内容，来大大缩减 AOF 的内容。

AOF 重写的过程，是一个轮询全部 RedisDB 快照，逐一落地的过程。每个 DB，首先通过 select $db 来记录待落的 DBID。然后通过命令记录每个 key/value。对于数据类型为 SDS 的value，可以直接落地。但如果 value 是聚合类型，则会将所有元素设为批量添加指令，进行落地。

**混合持久化**

Redis 在 4.0 版本之后，引入了混合持久化方式，而且在 5.0 版本后默认开启。前面讲到 RDB 加载速度快，但构建慢，缺少最新数据。AOF 持续追加最新写记录，可以包含所有数据，但冗余大，加载速度慢。混合模式一体化使用 RDB 和 AOF，综合 RDB 和 AOF 的好处。即可包含全量数据，加载速度也比较快。可以使用 aof-use-rdb-preamble 配置来明确打开混合持久化模式。

混合持久化也是通过 bgrewriteaof 来实现的。当启用混合存储后，进行 bgrewriteaof 时，主进程首先依然是 fork 一个子进程，子进程首先将内存数据以 RDB 的二进制格式写入 AOF 临时文件中。然后，再将落地期间缓冲的新增写指令，以命令的方式追加到临时文件。然后再通知主进程落地完毕。主进程将临时文件修改为 AOF 文件，并关闭旧的 AOF 文件。这样主体数据以 RDB 格式存储，新增指令以命令方式追加的混合存储方式进行持久化。后续执行的任务，以正常的命令方式追加到新的 AOF 文件即可。

混合持久化综合了 RDB 和 AOF 的优缺点，优势是包含全量数据，加载速度快。不足是头部的 RDB 格式兼容性和可读性较差。

## Redis过期键的删除策略 ##

Redis中有个设置时间过期的功能，即对存储在 redis 数据库中的值可以设置一个过期时间。作为一个缓存数据库，这是非常实用的。如我们一般项目中的 token 或者一些登录信息，尤其是短信验证码都是有时间限制的，按照传统的数据库处理方式，一般都是自己判断过期，这样无疑会严重影响项目性能.具体详细的策略说明可参照[这篇文章][Link 2]

其实有三种不同的删除策略：  
（1）：立即删除。在设置键的过期时间时，创建一个回调事件，当过期时间达到时，由时间处理器自动执行键的删除操作。  
（2）：惰性删除。键过期了就过期了，不管。每次从dict字典中按key取值时，先检查此key是否已经过期，如果过期了就删除它，并返回nil，如果没过期，就返回键值。  
（3）：定时删除。每隔一段时间，对expires字典进行检查，删除里面的过期键。

redis使用的过期键值删除策略是：**惰性删除加上定期删除，两者配合使用。**

## 数据淘汰策略 ##

当 key 过期后，或者 Redis 实际占用的内存超过阀值后，Redis 就会对 key 进行淘汰，删除过期的或者不活跃的 key，回收其内存，供新的 key 使用。Redis 的内存阀值是通过 maxmemory 设置的，而超过内存阀值后的淘汰策略，是通过 maxmemory-policy 设置的，具体的淘汰策略后面会进行详细介绍。Redis 会在 2 种场景下对 key 进行淘汰，第一种是在定期执行 serverCron 时，检查淘汰 key；第二种是在执行命令时，检查淘汰 key。

第一种场景，Redis 定期执行 serverCron 时，会对 DB 进行检测，清理过期 key。清理流程如下。首先轮询每个 DB，检查其 expire dict，即带过期时间的过期 key 字典，从所有带过期时间的 key 中，随机选取 20 个样本 key，检查这些 key 是否过期，如果过期则清理删除。如果 20 个样本中，超过 5 个 key 都过期，即过期比例大于 25%，就继续从该 DB 的 expire dict 过期字典中，再随机取样 20 个 key 进行过期清理，持续循环，直到选择的 20 个样本 key 中，过期的 key 数小于等于 5，当前这个 DB 则清理完毕，然后继续轮询下一个 DB。

第二种场景，Redis 在执行命令请求时。会检查当前内存占用是否超过 maxmemory 的数值，如果超过，则按照设置的淘汰策略，进行删除淘汰 key 操作。

Redis 中 key 的淘汰方式有两种，分别是同步删除淘汰和异步删除淘汰。在 serverCron 定期清理过期 key 时，如果设置了延迟过期配置 lazyfree-lazy-expire，会检查 key 对应的 value 是否为多元素的复合类型，即是否是 list 列表、set 集合、zset 有序集合和 hash 中的一种，并且 value 的元素数大于 64，则在将 key 从 DB 中 expire dict 过期字典和主 dict 中删除后，value 存放到 BIO 任务队列，由 BIO 延迟删除线程异步回收；否则，直接从 DB 的 expire dict 和主 dict 中删除，并回收 key、value 所占用的空间。在执行命令时，如果设置了 lazyfree-lazy-eviction，在淘汰 key 时，也采用前面类似的检测方法，对于元素数大于 64 的 4 种复合类型，使用 BIO 线程异步删除，否则采用同步直接删除。

Redis 具体有 6 种淘汰策略：

<table> 
 <thead> 
  <tr> 
   <th align="center">策略</th> 
   <th align="center">描述</th> 
   <th align="center">应用场景</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="center">volatile-lru</td> 
   <td align="center">从已设置过期时间的数据集中挑选最近最少使用的数据淘汰</td> 
   <td align="center">如果设置了过期时间，且分热数据与冷数据，推荐使用 volatile-lru 策略。</td> 
  </tr> 
  <tr> 
   <td align="center">volatile-lfu</td> 
   <td align="center">从所有配置了过期时间的键中驱逐使用频率最少的键</td> 
   <td align="center">Redis 4.0 引入的。</td> 
  </tr> 
  <tr> 
   <td align="center">volatile-ttl</td> 
   <td align="center">从已设置过期时间的数据集中挑选将要过期的数据淘汰</td> 
   <td align="center">如果让 Redis 根据 TTL 来筛选需要删除的key，请使用 volatile-ttl 策略。</td> 
  </tr> 
  <tr> 
   <td align="center">volatile-random</td> 
   <td align="center">从已设置过期时间的数据集中任意选择数据淘汰</td> 
   <td align="center">很少使用</td> 
  </tr> 
  <tr> 
   <td align="center">allkeys-lru</td> 
   <td align="center">从所有数据集中挑选最近最少使用的数据淘汰</td> 
   <td align="center">使用 Redis 缓存数据时，为了提高缓存命中率，需要保证缓存数据都是热点数据。可以将内存最大使用量设置为热点数据占用的内存量，然后启用 allkeys-lru 淘汰策略，将最近最少使用的数据淘汰。</td> 
  </tr> 
  <tr> 
   <td align="center">allkeys-lfu</td> 
   <td align="center">从所有键中驱逐使用频率最少的键</td> 
   <td align="center">redis 4.0 引入的。</td> 
  </tr> 
  <tr> 
   <td align="center">allkeys-random</td> 
   <td align="center">从所有数据集中任意选择数据进行淘汰</td> 
   <td align="center">如果需要循环读写所有的key，或者各个key的访问频率差不多，可以使用 allkeys-random 策略</td> 
  </tr> 
  <tr> 
   <td align="center">noeviction</td> 
   <td align="center">不删除策略，达到最大内存限制时，如果需要更多内存，直接返回错误信息。</td> 
   <td align="center">大多数写命令都会导致占用更多的内存 很少使用</td> 
  </tr> 
 </tbody> 
</table>

在正式的生产环境中需要根据系统的特征，来选择合适的淘汰策略。 在运行过程中也可以通过命令动态设置淘汰策略，并通过 INFO 命令监控缓存的 miss 和 hit，来进行调优。

## Redis崩溃后，如何进行数据恢复的？ ##

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5SdeJEf6-1598337789755)(https://raw.githubusercontent.com/zhaozhen197/my\_markdown\_img/master/CgoB5l3OHiKACmE3AABtGNZ4Oxg924.png)\]][img-5SdeJEf6-1598337789755_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgoB5l3OHiKACmE3AABtGNZ4Oxg924.png]

主要是通过内存数据持久化来进行数据恢复的，根据采用的持久化方式不同，数据恢复的策略也不同。

## redis的事务？ ##

Redis 通过 MULTI、EXEC、WATCH,UNWATCH,DISCARD 等命令来实现事务(transaction)功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。

事务中的多个命令被一次性发送给服务器，而不是一条一条发送，这种方式被称为流水线，可以减少客户端与服务器之间的网络通信次数从而提升性能。

在传统的关系式数据库中，常用 ACID 性质来检验事务功能的可靠性和安全性。在 Redis 中，事务总是具有原子性（Atomicity）、一致性（Consistency）和隔离性（Isolation），并且当 Redis 运行在某种特定的持久化模式下时，事务也具有持久性（Durability）。

**watch** : 将给出的`Keys`标记为`监测态`，作为事务执行的条件.

**unwatch**: 清除事务中`Keys`的 `监测态`，如果调用了**EXEC** or **DISCARD**，则没有必要再手动调用**UNWATCH**.

**MULTI**: `显式`开启`redis事务`，后续`commands`将排队，等候使用**EXEC**进行原子执行.

**EXEC:** 执行事务中的`commands`队列，恢复连接状态。如果**WATCH**在之前被调用，只有`监测`中的`Keys`没有被修改，命令才会被执行，否则停止执行（详见下文，`CAS机制`）.

**DISCARD**: 清除事务中的`commands`队列，恢复连接状态。如果**WATCH**在之前被调用，`释放` `监测`中的`Keys`.

**`WATCH`命令的使用是为了解决 `事务并发` 产生的`不可重复读`和`幻读`的问题（简单理解为给`Key加锁`）**

`MULTI`,`EXEC`,`DISCARD`才是`显式`开启并控制事务的常用命令，可类比关系型数据据库中的 `BEGAIN`,`COMMIT`,`ROLLBACK`

事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。

***Redis事务不支持Rollback***

`Redis命令`可能会执行失败，仅仅是由于错误的语法被调用（命令排队时检测不出来的错误），或者使用错误的数据类型操作某个`Key`： 这意味着，实际上失败的命令都是编程错误造成的，都是开发中能够被检测出来的，生产环境中不应该存在。

# redis 高并发和高可用 #

## Redis的高并发是如何实现的？ ##

首先**从程序编写的角度上**来说，

*  Redis是纯内存数据库，读写速度快，
 *  采用了非阻塞IO复用，
 *  采用了优秀的数据结构设计，

然后，**从布局架构上**来说，实现**高并发**主要依靠**主从架构**（**单线程多进程**），比如**单机写数据，多机查数据**。单机能达到几万QPS(queries per sec)，多个从实例能达到10W的QPS。  
更进一步，可以采用集群，不仅能实现高并发，还能容纳大量数据。

## Redis的高可用是如何实现的？ ##

高可用性指**系统无中断地执行其功能的能力**。Redis实现高可用依靠的是Sentinel哨兵机制。Sentinel**本质上只是一个运行在特殊模式下的Redis服务器**，是一个进程。

**Sentinel作用：**

*  监控Redis整体是否正常运行。
 *  某个节点出问题时，**通知给其他进程**（比如他的客户端）。
 *  主服务器下线时，在从服务器中**选举**出一个新的主服务器。

**Sentinel互相监督：**

1.  Sentinel和服务器之间建立hello频道连接
2.  Sentinel在hello频道发送信息时会被其他Sentinel发现，达到握手的目的。
3.  发现后，Sentinel之间建立连接，形成环形网络。

**Sentinel监督下线：**

*  按频率向所有创建连接的实例发送PING，查看是否回复PONG来判断是否在线，不回复则**标记为主观下线状态**。
 *  向其他Sentinel询问，如果足够数量的Sentinel也标记为下线状态，则改为**客观下线**。

**Sentinel应对服务器下线的补救措施：**

**（1）选举领头的Sentinel**

过程：一个Sentinel向另一个Sentinel发送设置请求命令。**最先向目标Sentinel**发送设置要求的源Sentinel将成为目标Sentinel的局部领头Sentinel，而之后接收到的所有设置要求都会被目标Sentinel拒绝。

如果有某个Sentinel**被半数**以上的Sentinel设置成了局部领头Sentinel，那么这个Sentinel成为领头Sentinel。

**（2）故障转移**

1.  从已下线的主服务器的从服务器中**拔举**一个作为主服务器。标准：**偏移量最大**
2.  让已下线主服务器属下的所有从服务器改为复制新的主服务器
3.  将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线时，它就会成为新的主服务器的从服务器。

# redis多机架构 #

不考虑中间件，原生的架构有**主从复制架构**和**集群架构**。

## redis集群 ##

集群通过分片（sharding）来进行数据共享，并提供复制和故障转移功能，保证高可用性。

**集群的结构**是：多个节点（node）组成一个集群，节点是Redis中数据存储的单位，在刚开始的时候，每个节点都是相互独立的。通过`CLUSTER MEET`命令相互握手，组成集群。

**集群数据的存储方式**是：集群的整个数据库被分一万多个槽（slot）\*\*，\*\*数据库中的每个键都属于槽的其中一个。当所有槽都有节点在处理时，集群处于上线状态。

### Redis 的集群管理有 3 种方式。 ###

Redis 集群的分布式方案主要有 3 种。分别是 Client 端分区方案，Proxy 分区方案，以及原生的 Redis Cluster 分区方案。

#### Client 端分区 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 9]

Client 端分区方案就是由 Client 决定数据被存储到哪个 Redis 分片，或者由哪个 Redis 分片来获取数据。它的核心思想是通过哈希算法将不同的 key 映射到固定的 Redis 分片节点上。对于单个 key 请求，Client 直接对 key 进行哈希后，确定 Redis 分片，然后进行请求。而对于一个请求附带多个 key 的场景，Client 会首先将这些 key 按哈希分片进行分类，从而将一个请求分拆为多个请求，然后再分别请求不同的哈希分片节点。

对于 Client 端分区，由于 Redis 集群有多个 master 分片，同时每个 master 下挂载多个 slave，每个 Redis 节点都有独立的 IP 和端口。如果 master 异常需要切换 master，或读压力过大需要扩展新的 slave，这些都会涉及集群存储节点的变更，需要 Client 端做连接切换。

Client 端分区方案的优点在于分区逻辑简单，配置简单，Client 节点之间和 Redis 节点之间均无需协调，灵活性强。而且 Client 直接访问对应 Redis 节点，没有额外环节，性能高效。但该方案扩展不便。在 Redis 端，只能成倍扩展，或者预先分配足够多的分片。在 Client 端，每次分片后，业务端需要修改分发逻辑，并进行重启。

#### Proxy 端分区 ####

Proxy 端分区方案是指 Client 发送请求给 Proxy 请求代理组件，Proxy 解析 Client 请求，并将请求分发到正确的 Redis 节点，然后等待 Redis 响应，最后再将结果返回给 Client 端。

在整个处理过程中，Proxy 代理首先要负责接受请求并解析，然后还要对 key 进行哈希计算及请求路由，最后还要将结果进行读取、解析及组装。如果系统运行中，主从变更或发生扩缩容，也只需由 Proxy 变更完成，业务 Client 端基本不受影响。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 10]

常见的 Proxy 端分区方案有 2 种，第一种是基于 Twemproxy 的简单分区方案，第二种是基于Codis 的可平滑数据迁移的分区方案。

Twemproxy 实现简单、稳定性高，在一些访问量不大且很少发生扩缩的业务场景中，可以很好的满足需要。但由于 Twemproxy 是单进程单线程模型的，对包含多个 key 的 mutli 请求，由于需要分拆请求，然后再等待聚合，处理性能较低。而且，在后端 Redis 资源扩缩容，即增加或减少分片时，需要修改配置并重启，无法做到平滑扩缩。而且 Twemproxy 方案默认只有一个代理组件，无管理后端，各种运维变更不够便利。

Codis 是一个较为成熟的分布式 Redis 解决方案。对于业务 Client 访问，连接 Codis-proxy 和连接单个 Redis 几乎没有区别。Codis 底层除了会自动解析分发请求之外，还可以在线进行数据迁移，使用非常方便。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 11]

**Proxy 端分区方案的优势，是 Client 访问逻辑和 Redis 分布逻辑解耦，业务访问便捷简单。在资源发生变更或扩缩容时，只用修改数量有限的 Proxy 即可，数量庞大的业务 Client 端不用做调整。但 Proxy 端分区的方案，访问时请求需要经过 Proxy 中转，访问多跳了一级，性能会存在损耗，一般损耗会达到 5~15% 左右。另外多了一个代理层，整个系统架构也会更复杂。**

#### Redis Cluster 分区 ####

Redis 社区版在 3.0 后开始引入 Cluster 策略，一般称之为 Redis-Cluster 方案。Redis-Cluster 按 slot 进行数据的读写和管理，一个 Redis-Cluster 集群包含 16384 个 slot。每个 Redis 分片负责其中一部分 slot。在集群启动时，按需将所有 slot 分配到不同节点，在集群系统运行后，按 slot 分配策略，将 key 进行 hash 计算，并路由到对应节点 访问。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 12]

#### Redis cluster集群的通信方式 ####

集群依靠消息通信，消息有5种：MEET, PING, PONG, FAIL, PUBLISH。

Redis集群中的各个节点通过**Gossip协议**来交换各自关于不同节点的状态信息，其中Gossip协议由MEET、PING、PONG三种消息实现。

--------------------

所谓Gossip是八卦消息的意思，在Redis中，发送每次发送MEET、PING、PONG消息时，发送者都从自己的已知节点列表中**随机选出两个节点**（可以是主节点或者从节点），保存到一个特殊结构体中。

接受者接收到MEET、PING、PONG消息时，根据保存的两个节点是否认识来选择进行哪种操作：

*  不认识，说明接收者**第一次接触被选中节点**，则接收者与被选中节点握手
 *  认识，根据结构信息进行更新。

比如A节点发送的PING给B，携带了CD两个节点，然后B回复PONG携带了EF两个节点，这样就完成了ABCDEF六个节点的信息交换。**每个节点按照周期向不同节点传播PING-PONG信息，就能完成整个集群的状态更新。**

--------------------

如果节点很多，则Gossip消息比较慢，而主节点下线的消息需要立即通知给所有人。FAIL消息的正文只包含已下线的节点名称，直接通知给所有已知节点。

![img][]

![img][img 1]

--------------------

接收到PUBLISH命令的节点**不仅会向channel频道发送消息message，它还会向集群广播一条PUBLISH消息，所有接收到这条PUBLISH消息的节点都会向channel频道发送message消息**。

也就是说，向集群发送`PUBLISH`，会导致集群所有节点都向channel发送message消息。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 13]

#### 集群分片的原理是什么? ####

Redis引入了哈希槽的概念，通过槽指派的方式存储数据。

Redis集群有214=16384214=16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽`slot = CRC16(key) & 16383`，集群的每个节点负责一部分hash槽。

**使用哈希槽的好处就在于可以方便的添加或移除节点。**

1.  当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；
2.  当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了。

CRC16算法能分配65535个槽位，但作为包发送太臃肿，一般情况下一个redis集群不会有超过1000个master节点，所以采用1/41/4

#### 集群扩容和收缩是怎么实现的？ ####

集群的伸缩是通过重新分片的方式实现的，重新分片操作可以将**任意数量已经指派给某个节点（源节点）的槽改为指派给另一个节点（目标节点）**，并且相关槽所属的键值对也会从源节点被移动到目标节点。

重新分片操作可以**在线（online）进行**，在重新分片的过程中，集群不需要下线，并且**源节点和目标节点都可以继续处理命令请求**。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 14][]

## Redis主从复制 ##

Redis 支持 master-slave 的复制功能。当 Redis 的 slave 部署并设置完毕后，slave 会和 master 建立连接，进行全量同步。第一次建立连接，或者长时间断开连接后，缺失的指令超过 master 复制缓冲区的大小，都需要先进行一次全量同步。全量同步时，master 会启动一个子进程，将数据库快照保存到文件中，然后将这个快照文件发给 slave，同时将快照之后的写指令也同步给 slave。  
![1598337789753)(https://raw.githubusercontent.com/zhaozhen197/my\_markdown\_img/master/CgotOV3c5d2AJsqpAAB0B4B\_zA8513.png)\]][1598337789753_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgotOV3c5d2AJsqpAAB0B4B_zA8513.png]

全量同步完成后，如果 slave 短时间中断，然后重连复制，缺少的写指令长度小于 master 的复制缓冲大小，master 就会把 slave 缺失的内容全部发送给 slave，进行增量复制。

Redis 的 master 可以挂载多个 slave，同时 slave 还可以继续挂载 slave，通过这种方式，可以有效减轻 master 的压力，同时在 master 挂掉后，可以在 slave 通过 slaveof no one 指令，使当前 slave 停止与 master 的同步，转而成为新的 master。

随着负载不断上升，主服务器可能无法很快地更新所有从服务器，或者重新连接和重新同步从服务器将导致系统超载。为了解决这个问题，可以创建一个中间层来分担主服务器的复制工作。中间层的服务器是最上层服务器的从服务器，又是最下层服务器的主服务器。

# Redis的应用 #

## 大任务的处理机制 ##

通过 BIO 线程解决处理容易超时的系统调用问题。

Redis 在运行过程中，不可避免的会产生一些运行慢的、容易引发阻塞的任务，如将内核中的文件缓冲同步到磁盘中、关闭文件，都会引发短时阻塞，还有一些大 key，如一些元素数高达万级或更多的聚合类元素，在删除时，由于所有元素需要逐一释放回收，整个过程耗时也会比较长。而 Redis 的核心处理线程是单进程单线程模型，所有命令的接受与处理、数据淘汰等都在主线程中进行，这些任务处理速度非常快。如果核心单线程还要处理那些慢任务，在处理期间，势必会阻塞用户的正常请求，导致服务卡顿。为此，Redis 引入了 BIO 后台线程，专门处理那些慢任务，从而保证和提升主线程的处理能力。

Redis 的 BIO 线程采用生产者-消费者模型。主线程是生产者，生产各种慢任务，然后存放到任务队列中。BIO 线程是消费者，从队列获取任务并进行处理。

**BIO 处理任务**

Redis 的 BIO 线程采用生产者-消费者模型。主线程是生产者，生产各种慢任务，然后存放到任务队列中。BIO 线程是消费者，从队列获取任务并进行处理。

Redis 启动时，会创建三个任务队列，并对应构建 3 个 BIO 线程，三个 BIO 线程与 3 个任务队列之间一一对应。BIO 线程分别处理如下 3 种任务。

*  close 关闭文件任务。rewriteaof 完成后，主线程需要关闭旧的 AOF 文件，就向 close 队列插入一个旧 AOF 文件的关闭任务。由 close 线程来处理。
 *  fysnc 任务。Redis 将 AOF 数据缓冲写入文件内核缓冲后，需要定期将系统内核缓冲数据写入磁盘，此时可以向 fsync 队列写入一个同步文件缓冲的任务，由 fsync 线程来处理。
 *  lazyfree 任务。Redis 在需要淘汰元素数大于 64 的聚合类数据类型时，如列表、集合、哈希等，就往延迟清理队列中写入待回收的对象，由 lazyfree 线程后续进行异步回收。

## 提升性能 ##

Memcached 单实例压测 TPS 可以高达百万，线上可以稳定跑 20~40 万而言，Redis 的单实例压测 TPS 不过 10~12 万，线上一般最高也就 2~4 万，仍相差一个数量级。

Redis 慢的主要原因是单进程单线程模型。虽然一些重量级操作也进行了分拆，如 RDB 的构建在子进程中进行，文件关闭、文件缓冲同步，以及大 key 清理都放在 BIO 线程异步处理，但还远远不够。线上 Redis 处理用户请求时，十万级的 client 挂在一个 Redis 实例上，所有的事件处理、读请求、命令解析、命令执行，以及最后的响应回复，都由主线程完成，纵然是 Redis 各种极端优化，巧妇难为无米之炊，一个线程的处理能力始终是有上限的。当前服务器 CPU 大多是 16 核到 32 核以上，Redis 日常运行主要只使用 1 个核心，其他 CPU 核就没有被很好的利用起来，Redis 的处理性能也就无法有效地提升。而 Memcached 则可以按照服务器的 CPU 核心数，配置数十个线程，这些线程并发进行 IO 读写、任务处理，处理性能可以提高一个数量级以上。

针对这种性能的压力，redis的主要是通过多部署几个 Redis 实例来达到类似多线程的效果，但多实例部署则带来了运维复杂的问题，而且单机多实例部署，会相互影响，进一步增大运维的复杂度。

Redis 在 6.0 版本引入多线程模型，Redis 的多线程模型，分为主线程和 IO 线程。因为处理命令请求的几个耗时点，分别是请求读取、协议解析、协议执行，以及响应回复等。所以 Redis 引入 IO 多线程，并发地进行请求命令的读取、解析，以及响应的回复。而其他的所有任务，如事件触发、命令执行、IO 任务分发，以及其他各种核心操作，仍然在主线程中进行，也就说这些任务仍然由单线程处理。这样可以在最大程度不改变原处理流程的情况下，引入多线程。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 15]

主线程负责监听端口，注册连接读事件。当有新连接进入时，主线程 accept 新连接，创建 client，并为新连接注册请求读事件。当请求命令进入时，在主线程触发读事件，主线程此时并不进行网络 IO 的读取，而将该连接所在的 client 加入待读取队列中。Redis 的 Ae 事件模型在循环中，发现待读取队列不为空，则将所有待读取请求的 client 依次分派给 IO 线程，并自旋检查等待，等待 IO 线程读取所有的网络数据。所谓自旋检查等待，也就是指主线程持续死循环，并在循环中检查 IO 线程是否读完，不做其他任何任务。只有发现 IO 线程读完所有网络数据，才停止循环，继续后续的任务处理。

**多线程方案优劣**

虽然多线程方案能提升1倍以上的性能，但整个方案仍然比较粗糙。首先所有命令的执行仍然在主线程中进行，存在性能瓶颈。然后所有的事件触发也是在主线程中进行，也依然无法有效使用多核心。而且，IO 读写为批处理读写，即所有 IO 线程先一起读完所有请求，待主线程解析处理完毕后，所有 IO 线程再一起回复所有响应，不同请求需要相互等待，效率不高。最后在 IO 批处理读写时，主线程自旋检测等待，效率更是低下，即便任务很少，也很容易把 CPU 打满。整个多线程方案比较粗糙，所以性能提升也很有限，也就 1~2 倍多一点而已。要想更大幅提升处理性能，命令的执行、事件的触发等都需要分拆到不同线程中进行，而且多线程处理模型也需要优化，各个线程自行进行 IO 读写和执行，互不干扰、等待与竞争，才能真正高效地利用服务器多核心，达到性能数量级的提升。

# Redis的应用场景 #

（1）会话缓存（Session Cache）

最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？

幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。

（2）全页缓存（FPC）

除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。

（3）队列

Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。

（4）排行榜/计数器

Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。

（5）发布/订阅

最后（但肯定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建立聊天系统！

(6) 查找表

例如 DNS 记录就很适合使用 Redis 进行存储。查找表和缓存类似，也是利用了 Redis 快速的查找特性。但是查找表的内容不能失效，而缓存的内容可以失效，因为缓存不作为可靠的数据来源。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/b2696ff7d00145e09d98afac73f386ac.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/816bd37a0eb641198a96c734720d0c07.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/4e526193860b409abc6d2fc262b728ff.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/bdf133e1ea3a471f86fb7b376ae1e085.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/84bf0ce11f364e3bbbe6a956ff2f9a5b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221123/365ef5cec411406e839f5cd29790b054.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221123/d520d9d012414aedb107bb558f79787b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221123/deaf6c828cc94ea3863911a719e276bd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20221123/e9f8dd45da29465f9e8021be2d011edd.png
[Link 1]: https://blog.csdn.net/ThinkWon/article/details/101521724
[img-SBuL2BRe-1598337789730_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgotOV2lPF-AZtVrAABZ5Cio_aE709.png]: /images/20221123/1c393379211f4085b0e24eb25ee7713f.png
[img-uiZ5bPCr-1598337789733_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgoB5l28Bx6AUzW7AACuWHuW1yQ159.png]: /images/20221123/f9f1638550164b2aac564374af132481.png
[img-jeonRrtW-1598337789737_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgoB5l28Bx6AVwGxAAEKF2oxItk727-20200824212419623.png]: /images/20221123/e83d1c02e1214053a34544785ee3a26c.png
[img-nZg7t6Q6-1598337789742_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgoB5l28Bx-ARu4ZAACk1VRWcR4166.png]: /images/20221123/3c0f6a0225194a99ac539b019609c815.png
[x]: /images/20221123/d9ca6c7d7d474833bda0f88e08a03482.png
[img-1URGEJS0-1598337789747_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_Center-20200824130312240.png]: /images/20221123/d182ad3b13d94286a9178ba4fa818f90.png
[img-bUoJEHpL-1598337789749_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgoB5l28ByCADkuqAACua3XXug4030.png]: /images/20221123/3529d4a9b4c3494a98da1032c57facb6.png
[img-jftdtrbx-1598337789751_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_Center-20200824130530842.png]: /images/20221123/71b9e8e9bb174b6abfb137047c2e3d02.png
[img-ahA0qdfI-1598337789751_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_Center-20200824130739558.png]: /images/20221123/34b44722ed554b818d37098468500215.png
[img-FASnDClJ-1598337789752_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgoB5l2yv6iAb3V5AACx5LFCsHM346.png]: /images/20221123/c85f842cf9b44c138b4b94ea4de4d165.png
[Link 2]: https://blog.csdn.net/ThinkWon/article/details/101522970
[img-5SdeJEf6-1598337789755_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgoB5l3OHiKACmE3AABtGNZ4Oxg924.png]: /images/20221123/ef219572ec504c0dad0c5b918b522fbd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20221123/c8335c456fef4e26b7d20716271f0ac5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 10]: /images/20221123/eb5bd70285754b25a8af625f3a9cffc5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 11]: /images/20221123/5b928639e78d4bd48f4eecdb8555e815.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 12]: /images/20221123/1034cd49d3bf4944910ebe1cc4cdc617.png
[img]: /images/20221123/3d3c144fbd574d0e8daa68cc0605b48d.png
[img 1]: /images/20221123/8c6f600c989a46af8385226afa65faae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 13]: /images/20221123/4699a727059e4dbb9f9b204e699a1755.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 14]: /images/20221123/3908f9cac6784e57a2ea1bb495a10f7f.png
[1598337789753_https_raw.githubusercontent.com_zhaozhen197_my_markdown_img_master_CgotOV3c5d2AJsqpAAB0B4B_zA8513.png]: /images/20221123/606601d2ed2043e498348d25f1df8a76.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70_pic_center 15]: /images/20221123/c1ffd69d77aa46f583036e7d6f73723b.png