Redis总结

一、什么是Reids

Redis是一个开源（BSD许可），内存存储的数据结构服务器，可用作数据库，高速缓存和消息队列代理。它支持字符串、哈希表、列表、集合、有序集合，位图，hyperloglogs等数据类型。内置复制、Lua脚本、LRU收回、事务以及不同级别磁盘持久化功能，同时通过Redis Sentinel提供高可用，通过Redis Cluster提供自动分区。

二、Redis为什么快

• 内存数据库

  • 内存访问数据快

• 高效的数据结构，

  • 数据类型 String、List、Hash、Set、SortSet
  • 底层数据结构 动态字符串、双向链表、压缩链表(数组，头部节点有3个信息：长度、结束、偏移量)、哈希表、跳表 、整数数组
    

• 单线程&高性能的IO模型(多路复用)

  • 单线程是指：网络IO和键值读写，但是其他，例如：持久化、异步删除、集群同步还是多线程

  • IO多路复用，在网络accept、rec、waite上监听处理，同时监听多个套接，和已连接套接字。

  • 基于事件回调处理
    

  • 避免了 网络连接点的阻塞风险

• 全局Hash表，可以直接O(1)定位，

  • 问题：rehash、hash碰撞
    

  • 采用渐进rehash的方法(访问时进行复制处理，将大量拷贝分摊到多次请求中)

三、Redis日志系统

AOF日志：

• 先写数据、再写日志(逻辑操作日志)
  • 好处：校验语法错误、不会阻塞数据写入
• 宕机数据丢失问题，设置回盘策略：
  • Always：同步写回，性能影响大
  • Everyc：每秒写回
  • no ：不写回
• 重写机制：
  • 当日志文件过大后，会带来性能问题(追加、日志重放)，将旧文件多条日志重写为一条日志，这就是重写功能
  • 执行过程：主线程 fork 出后台的 bgrewriteaof 子进程,**将数据 写成操作，**拷贝过后新的操作记录到AOF缓冲区，同时也会写在AOF重写缓冲区，拷贝完成之后，新的操作也会记录在重写日志中 （一次拷贝、两次日志）
  • 

RDB日志(内存快照)：

解决AOF重放日志缓慢问题。
RDB需要有两个问题：哪些数据、生成快照时是否阻塞主线程？（fock时会阻塞、fock之后不会阻塞）

• 生成全量数据
• 利用Copy-on-waite技术，不阻塞主线程。具体过程：主线程fock出 bgsave子线程。它可以共享所有内存数据(虚拟-物理映射)，并将内存数据写入RDB问题。**此时发生写操作，将会发生真正的复制被修改过的页。**后续会将复制的副本写入写入RDB。所以说并不会阻塞主线程。(快照期间数据可修改)

• Redis4.0 有一种AOF、RDB混用模式

模式	优点	缺点
AOF	记录简单，记录逻辑操作	重放耗费时
RDB	文件内容小，恢复时间更短	生成RDB时，文件太大可能会阻塞主进程，生成相对耗时

四、高可用

redis的高可用其实代表两层含义：
答： 包含了两层含义：数据尽量不丢失；服务尽量不中断

问题	方法
数据尽量不丢失	AOF 和 RDB日志
服务尽量不中段	通过主、从库 读写分离的模式(增加副本冗余)

4.1 主从库同步

• 从库第一次全量同步主库, 步骤如下：

1、 从库向主库发送 slave of  主IP 端口 建立连接
2、 主节点 bgsave生成RDB文件
3、 同步全量数据给从库 FULLRESYNC {主库ID} {offset} RDB文件
4、 从节点清空所有数据，加载RDB
5、 主库发送新写入的命令repl buffer 到从库，加载repl buffer

生成RDB和传输RDB文件是非常消耗性能的。可以采用主-从-从-从模式，分担主库的复制负担。复制和传输是基于长连接的形式，那么就会面临一个新的问题：网络阻塞、网络断开。

• 传输过程中遇到网络问题

如果全量同步时发生了网络问题，恢复后会采用增量复制的方式。repl buffer记录主库接受的新请求；

1、网络恢复
2、从库发送 psync命令，并告知主库 slave_repl_offset
3、主库根据自身的master_repl_offset判断差距，来进行增量同步

4.2 哨兵机制

哨兵其实就是一个运行在特殊模式下的 Redis 进程。

哨兵主要是下面3个任务：
1.监控 （判断主/从库是否健康）
从库：通过PING 命令可以直接标记为 主观下线
主库**：**哨兵集群通过投票判断 “主观下线”，通常超过2/n + 1个之后，会将主库标记为 客观下线;
**2.选主 **（主库宕机后，选取从库）
通过 筛选 + 打分

筛选： 正常运行的从库，并且之前的网络状态要良好

打分：从库优先级、从库复制进度以及从库 ID 号
从库优先级： slave-priority 配置

**3.通知 ** (通知新从库，主库信息)
哨兵会把新主库的连接信息发给其他从库，让它们执行replica of 命令，和新主库建立连接，并进行数据复制。

4.3 哨兵集群

4.3.1 哨兵是如何组成集群的？

通过pub/sub机制相互发现的，通过一个共同订阅消息的频道，就可以共享不同哨兵的基本信息ip+端口号。 哨兵的相互通信是通过：sentinel_:hello 频道

4.3.2 哨兵是如何知道从库信息？

当哨兵选举出新的主库时，就需要通知从库，但是前提是如何知道从库的信息呢？

是通过 哨兵向主库 发送info命令，他会返回所有slave从库节点的列表

4.3.3 哨兵和客户端的信息同步
同样通过pub/sub,订阅特定的频道，来获取消息通知。具体相关的订阅通道如下：

具体的操作步骤是，客户端读取哨兵的配置文件后，可以获得哨兵的地址和端口，和哨兵建立网络连接。然后，我们可以在客户端执行订阅命令，来获取不同的事件消息。

4.3.4 由哪个哨兵来操作

客观下线的仲裁过程：

1.任何实例只要自己判断主库下线后，就会给其他哨兵发送 is-master-downby-addr。哨兵通过 Y/N 表示赞成或反对；
2.当自己的票获得数量 超过 = quorum 设置的值 (就可以设置为客观下线了)
3.表明自己想执行主从切换，并且让哨兵为他进行投票，这个投票的过程称为leader选举
成为leader的两个条件：** **
第一，拿到半数以上的赞成票；第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值

分为几个步骤：1、标记客观下线 2、选举操作哨兵 3、主从切换

4.4 Redis集群

切片集群，多个redis实例组成集群

大数据量导致生成RDB快照时，fock子线程的时间耗时长，并且会阻塞主进程。解决方案如下：

• 纵向扩展：例如：增加内存、CPU等，但是会有硬件瓶颈
• 横向扩展: Redis集群，可以弹性伸缩。需要解决下面问题：
  • 数据如何分片分布
    • Redis Cluster 将集群分为16384个槽，通过CRC16算法对Key进行处理确定槽位
    • 16384槽需要全部分配完成
  • 客户端如何访问
    • a.客户端如何知道实例槽的信息：客户端会缓存实例槽的信息，所有实例能拿到任何其他实例的信息
    • b .实例有新增或删除，Redis 需要重新分配哈希槽；并且提供重定向机制
    • c.槽位正在迁移： 返回ASK命令，并且会返回最新的实例地址

五、Redis数据结构

5.1 简单动态字符(SDS)

当你保存的数据中包含字符串时，就会使用 **简单动态字符(SDS)**来保存

包含：长度、实际分配长度、内容

5.2 RedisObject

redis使用RedisObject来表示所有数据类型，其中包含：

• 8B的元数据记录着最后一次引用时间、引用次数等信息。
• 8B的指针，指向SDS结构

有三种常见的编码方式如下：

当你保存的是64位有符号的整数时，String类型会把它保存成一个8个字节的 Long类型整数，这种编码方式叫int类型编码

5.3 10位的k-v一共需要多少字节

整型 int 类型的编码 可以用
redisoobject 直接存储数据，16个字节一个ID。
redis的全局hash表 dictEntry 的结构体，它由3个部分组成， key、value 以及下一个 dictEntry，三个指针共 24 字节
但是由于 Redis 使用的内存分配库 jemalloc 了，每次分配时会找一个 >= 它请求分配的 最小2的N次幂，所以24个字节实际也就是 申请了32个字节。所以 32B + 32B = 64B

5.4 什么数据结构可以省空间

Redis 基于压缩列表实现了 List、Hash 和 Sorted Set 这样的集合类型，这样做的最大好
处就是节省了 dictEntry 的开销。

• 普通k-v 一个key就需要一个dictEntry
• 集合类型 一个key 对应一个集合数据才一个dictEntry

5.5 如何用集合类型保存单值的k-v

前一部分作为 Hash 集合的 key，后一部分作为Hash 集合的 value，这样一来，我们就可以把单值数据保存到 Hash 集合中了。
例如。100001 1234
就可以 使用hashset进行存储：1000 01(key) - 1234(value)

5.6 Hash 类型的底层结构是 hash表 和 压缩表，什么时候相互转换呢？

设置了两个阀值 一但在阀值之外就会转换成 hash 表。
hash-max-ziplist-entries：表示用压缩列表保存时哈希集合中的最大元素个数。
hash-max-ziplist-value：表示用压缩列表保存时哈希集合中单个元素的最大长度。

5.7 GEO数据类型

GEO主要用于配合LBS位置信息服务。可以用来存放经纬度。底层也是sortSet实现。
GeoHash编码，也就是二分区间、Hash编码。

• 将经度、纬度编码成一串数字进行存储

GEOADD cars:locations 116.034579 39.030452 33
GEORADIUS cars:locations 116.054579 39.030452 5 km ASC COUNT 10

5.8 自定义数据结构

需要自定义数据结构，就必须了解RedisObject。分为元数据 + 指针。

• 元数据信息
• 指针

type：表示值的类型，涵盖了我们前面学习的五大基本类型；
encoding：是值的编码方式，用来表示 Redis 中实现各个基本类型的底层数据结构，
例如 SDS、压缩列表、哈希表、跳表等；
lru：记录了这个对象最后一次被访问的时间，用于淘汰过期的键值对；
refcount：记录了对象的引用计数；
*ptr：是指向数据的指针

六、Redis场景应用

6.1 消息队列

消息队列需要解决的3个问题：
1.消息保序

使用 LPUSH 命令 和 RPOP 命令 保证写入后读取消息的顺序 消费者一直使用 while(1)监听处理消息的时候 会一直消耗CPU
改进：提供使用 BRPOP 命令，再没有拿到数据时，会发生阻塞，不会消耗cup

2.重复消息处理

生产者定义一个 幂等id, 消费者自行控制幂等处理

3.消息可靠性保证

防止消费者，处理失败，消息丢失，可以使用BRPOPLPUSH 命令 ，这个命令可以将消息存储在另外一个 备份list当中

基于Stream的消息队列解决方案

Streams 是 Redis 专门为消息队列设计的数据类型，它提供了丰富的消息队列操作命令。
XADD：插入消息，保证有序，可以自动生成全局唯一 ID；
XREAD：用于读取消息，可以按 ID 读取数据；
XREADGROUP：按消费组形式读取消息；
XPENDING 和 XACK：XPENDING 命令可以用来查询每个消费组内所有消费者已读取
但尚未确认的消息，而 XACK 命令用于向消息队列确认消息处理已完成。

6.2 并发读取

加锁：会降低并发性
lua脚本：可以进行逻辑判断操作

6.3 Redis实现事务

事务的特性：括原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）

Redis如何实现事务？

开始事务：MULTI；提交事务：EXEC; 开启事务后，将客户端的请求存储到队列中，并不会立即执行，得到exec命令才会开始执行

a.原子性

命令入队时就报错，保持原子性
实际执行时报错，不保持原子性
EXEC 命令执行时实例故障，开启AOF日志 保证原子性

a.一致性

能够保证数据一致性

a.隔离性

分exec命令前后；

• exec命令前，如果开启Watch机制，发现有数据变更，放弃事务执行，客户端可以重新发起
• exec命令后不会有隔离性问题

a.持久性

不管是使用RDB. 还是 AOF，事务的持久性还是不能得到保证。RDB不会在事务的时候执行

6.4 Redis支持秒杀

• redis支持高并发，多个商品可以分布在不同的slot实例上
• 保证库存检验和扣减原子执行
  • （Lua脚本支持）
  • 或者分布式锁

七、Redis缓存

为什么需要缓存？系统中不同层次之间的访问速度存在差异

7.1 旁路缓存

读取数据，先读取redis
读取db
更新缺失缓存

缓存类型：

• 只读缓存
• 读写缓存
  • 同步直写：写缓存同时写数据库，宕机风险
  • 异步回写: 所有更新都在数据库中，等增改数据将从缓存中淘汰时，再写回后端数据库

7.2 缓存替换策略

使用 80%的访问，只需要20%的缓存就能够解决
缓存容量设置为总数据量的 15%-30%

• 过期时间到达或达到了 maxmemory 阈值
  • Volatile-XXX 在设置了过期时间的数据中进行淘汰
  • Allkeys-XXX 在所有数据中淘汰

ttl:按过期时间排序越早过期越早被删除；
random:随机删除；
lru: 根据l ru算法；(改良最少最近使用)
lfu:根据lfu算法（最少使用）

改进的LRU算法

Redis 默认会记录每个数据的最近一次访问的时间戳（由键值对数据结构RedisObject 中的 lru 字段记录）。然后，Redis 在决定淘汰的数据时，第一次会随机选出N 个数据，把它们作为一个候选集合。接下来，Redis 会比较这 N 个数据的 lru 字段，把lru 字段值最小的数据从缓存中淘汰出去。
这样就不需要维护一下大链表；也不用移动链表项

7.3 缓存一致性问题

什么是数据一致性问题：
缓存中有数据，那么，缓存的数据值需要和数据库中的值相同；
缓存中本身没有数据，那么，数据库中的值必须是最新值。

• 缓存是删除还是更新？
  • 进行删除
• 先删缓存后更新数据库
  • 可能会读取到旧值，进行延迟双删除
• 先更新数据库后删除缓存 （推荐
  • 对数据库压力小

7.4 缓存雪崩、缓存穿透、缓存击穿

缓存雪崩

缓存雪崩是指大量的应用请求无法在 Redis 缓存中进行处理，紧接着，应用将大量请求发送到数据库层，导致数据库层的压力激增。引起到的一系列连锁反应

发生原因：

• 大量key失效
• redis 宕机

解决方案：

• key的过期时间采用随机数
• 服务降级
• 在业务系统中熔断或请求限流机制
• 高可用redis集群

缓存击穿

点数据的请求，无法在缓存中进行处理，大量请求发送到后端，导致数据库激增，引发连锁反应

**发生原因：**热点key
**解决方案：**针对热点数据，就不设置过期时间

缓存穿透

访问的数据既不在 Redis 缓存中，也不在数据库中，导致请求在访问缓存时，发生缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据。

发生原因：

• 数据错误删除
• 恶意攻击

解决方案：

• 针对在缓存中可以人为的针对缓存穿透数据，设置一个 默认值
• 布隆过滤器

7.5 缓存污染

在一些场景下，有些数据被访问的次数非常少，甚至只会被访问一次。当访问完成后还留在缓存中占用缓存空间，这就是缓存污染。

如何解决缓存失效？

• LRU淘汰算法

RedisObject结构体中设置了一个lru字段，用来记录访问的时间戳，通过方法时间先后来进行淘汰。内部是改良的LRU，每次淘汰时，就随机选一批数据，根据LRU进行淘汰

• LFU淘汰算法

将24位的lru字段进行拆分：前 16bit，表示数据的访问时间戳；后8位表示访问次数count

• 并不是访问一次count+1 而是采用一种减速算法 1/（ lfu_log_factor + 1）= p ，当p大于 r 时count才 + 1
• **存在短时间内被大量访问后不访问：**通过设置 lfu_decay_time 设置count的衰减值。

八、Redis性能问题

8.1单线程阻塞问题？

Redis 主线程启动后，会使用操作系统提供的 pthread_create 函数创建 3 个子线程，分别由它们负责 AOF 日志写操作、键值对删除以及文件关闭的异步执行。操作被封装成异步任务

Redis实例有哪些阻塞点？

客户端：网络 IO，键值对增删改查操作，数据库操作；
磁盘：生成 RDB 快照，记录 AOF 日志，AOF 日志重写；
主从节点：主库生成、传输 RDB 文件，从库接收 RDB 文件、清空数据库、加载 RDB
文件；
切片集群实例：向其他实例传输哈希槽信息，数据迁移。

** 客户端交互**
1.聚合查询和全量操作
2.bigkey 删除操作就是 Redis 的第二个阻塞点
3.清空数据库
和磁盘交互的时点
4.AOF日志同步写（ AOF 日志时，会根据不同的写回策略对数据做落盘保存）
主从节点交互时的阻塞点
5.加载RDB文件，主从同步时，会FLUSHDB 命令清空当前数据库，然后开始读取RDB文件

8.2 CPU结构影响性能

正常网络交互如下： 网卡-中断程序-内核缓存区- 应用程序epoll读取

• 如果中断处理程序 与 redis内存没有绑定同一个核，那么就需要跨Socket访问，过程比较耗费时间

8.3 Redis波动响应延迟

案例：Redis延迟导致事务时间增加，Mysql其他响应连锁反应

• 影响的关键因素：文件系统、操作系统

1. 从慢查询命令开始排查，并且根据业务需求替换慢查询命令；
2. 排查过期 key 的时间设置，并根据实际使用需求，设置不同的过期时间。
3. AOF重写时的的刷盘机制
4. 操作系统的Swap
5. 内存大页：

• 写时复制时，大页更消耗性能，复制是以页为单位。（需要关闭大页开关）

8.5 数据删除内存占有率高

什么是内存碎片：
使用内存空间时不连续，会有存在未被利用的“小间隙” ，这部分小间隙，就是内存碎片

a.形成原因：

• 内存分配(内因)：Redis默认采用jemalloc分配，会分配一个大于等于2的n次方的数据；
• 操作(外因)：健值对大小不一样和删除操作

b.解决方法：

采用INFO memory命令，查看碎片率情况：
mem_fragmentation_ratio（碎片率） = （used_memory_rss）实际的 / used_memory（申请的）当碎片率 >= 1.5 需要注意

• 重启，但是可能会丢失数据
• 开启自动清理，通过参数控制，会降低性能，可以通过参数控制

active-defrag-ignore-bytes 100mb：表示内存碎片的字节数达到 100MB 时，开始
清理；
active-defrag-threshold-lower 10：表示内存碎片空间占操作系统分配给 Redis 的
总空间比例达到 10% 时，开始清理。
active-defrag-cycle-min 25： 表示自动清理过程所用 CPU 时间的比例不低于
25%，保证清理能正常开展；
active-defrag-cycle-max 75：表示自动清理过程所用 CPU 时间的比例不高于
75%，一旦超过，就停止清理，从而避免在清理时，大量的内存拷贝阻塞 Redis，导致
响应延迟升高。

九、Redis问题处理

9.1 主从同步、故障切换

主从数据不一致：客户端在从库获取的值与主库的值是不一致的

原因：
主从之间的命令复制是异步的，可能发生延迟，即使从库接收了命令，可能在处理高复杂命令而阻塞，而滞后的时间，可能发生其他操作
解决方案：
1、从硬件方面尽可能保证主从连接
2、外部监控检查主从复制进度：master_repl_offset：主库接收命令速度、slave_repl_offset：从库复制命令速度，监控二者的差值。当差异较大的时候，就可让客户端不从该从库读取数据

9.2 读取过期数据

在使用redis主从集群时，有时会读取到过期数据

Reids 有两种策略来删除过期数据，分别是惰性删除和定期删除。

• 惰性删除：过期后不会立即删除，而是下次访问后删除
• 定期删除：每隔一段时间（默认 100ms），选取一定量判断并进行删除，释放内存

读取过期数据原因：
与设置过期时间命令相关：

当使用Expire命令时会导致，从库执行完该命令时，主库数据已经到达过期时间，使用pexpireat命令制定时间戳

9.3 错误配置

protected-mode 配置项

Yes： 表示只能本地访问
NO: 表示也能被其他服务访问
需要设置为 no;并且在 bind 中设置了 IP 地址的哨兵

cluster-node-timeout 配置项

如果执行主从切换的实例超过半数，而主从切换时间又过长的话，就可能有半数以上的实例心跳超时，从而可能导致整个集群挂掉。所以，我建议你将 cluster-nodetimeout 调大些（例如 10 到 20 秒）。

9.2 脑裂

脑裂：主从节点中有两个主节点，都能写入数据

发生原因：
主从切换之前需要超过一定数量的quoum哨兵实例与主库都超时了，才会判断主观下线，然后哨兵开始切换，客户端连接新的主库。但是如果原主库并没有发生真正的故障，但是被错误判断为主观下线，等恢复之后，就会有两个主库。

为什么数据丢失：

• 主从切换之后，哨兵会让原主库与新主库，进行主从同步，执行slave of 命令，与新主库进行新的全量同步：会清空本地数据，加载主库传输过来的RDB文件，这样一来原主库更新的数据就丢失了

如何解决：

• 避免发生故障时客户端与从库发生交互。通过下面的参数控制
• min-slaves-to-write：主库能进行数据同步的最少从库数量
• min-slaves-max-lag：从库给主库发送ACK 消息的最大延迟（以秒为单位）

9.3 数据倾斜

**数据量倾斜：**在某些情况下，实例上的数据分布不均衡，某个实例上的数据特别多。
**数据访问倾斜：**集群实例相差不大，实例中的热点数据访问频繁

数据量倾斜：

• bigkey原因导致，解决方法：避免创建，或分散集合
• slot分配不均匀；运维规范
• Hash Tag问题；不实用hash Tag

访问倾斜：

• 存在热点Key数据；多副本解决方法

十、Redis6.0 新特性

Redis的瓶颈出现在网络上，单个主线程处理网络请求跟不上底层网络硬件的速度
两种解决方法：

• 用户态网络协议栈（例如 DPDK）取代内核网络协议栈，让网络请求的

处理不用在内核里执行，直接在用户态完成处理就行。缺点：架构需要改动调整

• 多线程处理网络IO

10.1 多线程

**阶段一：**服务端和客户端建立 Socket 连接，并分配处理线程
阶段二：IO 线程读取并解析请求（多线程）
阶段三：主线程执行请求操作（单线程）
阶段四：IO 线程回写 Socket 和主线程清空全局队列(多线程)

通过

io-threads-do-reads yes ## 开启多线程

10.2 实现服务端协助的客户端缓存

服务端协助客户端缓存也叫 tracking 功能，有两种模式

**a.普通模式：**订阅了才发送

• key变更后服务端会向客户端发送invalidate消息，一次查询后只会发送一次

**b.广播模式：**所有专关注的发送 （所有变更后的key 消耗带宽）

RESP2是通过 redis:invalidate 频道 来获取失效消息

10.3 权限控制

之前是在通过密码进行权限控制；

• 支持不同的用户
• 用户粒度的命令操作访问权限

10.4 启动RESP3 协议

• RESP2 基于字节数组编码，客户端需要根据不同的类型进行解码
• RESP 3 直接支持多种数据类型的区分编码；所谓区分编码，就是指直接通过不同的开头字符，区分不同的数据类型，

优点：提升解析效率

问题合集：

1.Redis的IO模型中潜在风险点？

基本IO模型中，主要是主线程执行 bigkey,全量返回都是性能瓶颈

2.AOF重写过程的风险点？

• Redis 主线程 fork 创建 bgrewriteaof 子进程时，子进程需要拷贝父进程页表，耗时取决于Redis内存大小，太大复制耗时，会有阻塞风险
• 在重写时，主线程收到新写或修改的操作时，主线程会申请新的内存空间，数据量大的集合数据，主线程会因为面临大空间而阻塞。

3.为什主从库的复制不用AOF

• RDB是二进制文件，大小，传输效率更优
• 数据恢复时RDB的效率高于AOF

4. 主从库切换过程中，客户端能否正常进行操作

• 能读 不能写

5. 何时做Rehash

• 装载因子>=1，尽力不生成多链条表
• 装载因子>=5 ，数据太多
• AOF/RDB时禁止时禁止rehash

6.采用渐进式 hash 时，如果实例暂时没有收到新请求，是不是就不做 rehash 了？

Redis 会执行定时任务，定时任务中就包含了 rehash 操作。所谓的定时任务，就是按照一定频率（例如每 100ms/ 次）

7. replication buffer 和 repl_backlog_buffer 的区别

replication buffer 是主从库在进行全量复制时，主库上用于和从库连接的客户端的 buffer，而 repl_backlog_buffer 是为了支持从库增量复制，主库上用于持续保存写操作的一块专用 buffer。

8. mem_fragmentation_ratio 的值小于1

表明操作系统分配给red is的内存，小于redis 所申请内存的大小，此时redis实例内存已经不够用了，发生了swap

9. 如何排查redis的 bigkey

./redis-cli --bigkeys

10. 如果查询慢日志

redis的慢查询日志，记录了执行时间超过一定阀值的命令操作；
slowlog-log-slower-than：慢查询日志对执行时间大于多少微秒的数据进行记
slowlog-max-len：慢查询日志最多能记录多少条记录，如果超出，则会被删除；因为慢查询太多的话，日志就会存储不下，

参考

《机客时间：Redis源码与实战》