Redis笔记汇总 - 技术栈

nosql是为了解决性能问题产生的技术，代表就是redis

NoSQL数据库

概述

NoSQL数据库意思是不仅仅是SQL，泛指非关系型数据库

NoSQL不依赖业务逻辑方式存储，而以简单的key-value模式存储。因此大大的增加了数据库的扩展能力。

不遵循SQL标准

不支持ACID

远超SQL的性能

适用场景

对数据高并发的读写

海量数据的读写

对数据的高可扩展性

不适用常见

需要事务支持

基于sql的机构化存储，处理复杂的关系，需要及时查询

用不着sql的场景或用了sql无法解决就考虑nosql

典型nosql数据库

Memcache：数据都在内存，不能持久化，支持简单的key-value，支持类型单一（只有字符串），一般作为缓存数据库辅助持久化的数据库。早期nosql数据库

Redis：几乎覆盖了Memcache的绝大部分功能，支持持久化，支持多种数据类型。与关系型数据库一起使用

MongoDB：文档数据库，数据形式更加多样，结构更复杂，支持二进制数据以及大型对象。

行式存储数据库

行式数据库：把数据的每行作为一部分存储

列式数据库：把数据的每一列作为一部分存储

redis

概述

Redis是一个开源的key-value存储系统。

和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合）、zset(sorted set-有序集合)和hash（哈希类型）。

redis是单线程的，单个命令具有原子性。

低延迟，速度快：基于内存、IO复用、良好的编码等。

这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。

在此基础上，Redis支持各种不同方式的排序。

与memcached一样，为了保证效率，数据都是缓存在内存中。

区别的是Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件。

并且在此基础上实现了master-slave(主从)同步。

支持多语言客户端。

Redis命令

redis数据结构介绍

Redis是一个kv数据库，key一般是string类型，value的类型多种多样。

通用命令

通用指令是不分数据类型的，都可以使用的指令，常见的有：

KEYS：查看符合模板的所以key，不建议在生产环境设备上使用。（模糊查询，效率慢。redis是单线程，大数据量下会阻塞线程。主从集群时在从节点可以酌情使用）

通过help 【command】可以查看一个命令的具体用法

MSET：批量插入keys

del：批量删除key并返回删除的key个数

exists：判断一个key是否存在，存在返回1，不存在返回0

expire：给key设置一个有效期，到期会自动删除key

ttl:查看一个key的有效期，单位是s，永久有效是-1，已删除是-2

string类型

String类型，也就是字符串类型，是Redis中最简单的存储类型。

其value是字符串，不过根据字符串的格式不同，又可以分为3类：

string：普通字符串

int：整数类型，可以做自增、自减操作

float：浮点类型，可以做自增、自减操作

不管那种格式都是以字节数组的形式存储，不过编码方式不同。字符串类型的最大空间不能超过512M

string类型的常见命令

String的常见命令有：

SET：添加或者修改已经存在的一个String类型的键值对

GET：根据key获取String类型的value

MSET：批量添加多个String类型的键值对

MGET：根据多个key获取多个String类型的value

INCR：让一个整型的key自增1

INCRBY:让一个整型的key自增并指定步长，例如：incrby num 2让num值自增2

INCRBYFLOAT：让一个浮点类型的数字自增并指定步长

SETNX：添加一个String类型的键值对，前提是这个key不存在，否则不执行（相当于set+nx）

SETEX：添加一个String类型的键值对，并且指定有效期（相当于set+expire）

key的层级格式

redis允许多个单词形成层级结构，多个单词之间用：分隔开，格式如下：

项目名:业务名:类型:id

redis可以将字段序列化为json格式存储。插入时也需要以json插入，会形成层级结构

类似set heima:user:1 '{"id":1,"name":"Jack","age": 21}'

Hash类型

Hash类型，也叫散列，其value是一个无序字典，类似HashMap结构。

string结构是将对象序列化为json字符串后存储，当需要修改对象某个字段时很不方便。

Hash结构可以将对象中的每个字段独立存储，可以针对单个字段CURD

常见命令

Hash的常见命令有:

HSET key field value：添加或者修改hash类型key的field的值

HGET key field：获取一个hash类型key的field的值

HMSET：批量添加多个hash类型key的field的值

HMGET：批量获取多个hash类型key的field的值

HGETALL：获取一个hash类型的key中的所有的field和value

HKEYS：获取一个hash类型的key中的所有的field

HVALS：获取一个hash类型的key中的所有的value

HINCRBY:让一个hash类型key的字段值自增并指定步长

HSETNX：添加一个hash类型的key的field值，前提是这个field不存在，否则不执行

list类型

redis中的list类型和双向链表类似，支持正向检索和反向检索。

特征：

有序

元素可以重复

插入和删除快

查询速度一般

常见命令

List的常见命令有:

LPUSH keyelement...：向列表左侧插入一个或多个元素

LPOP key：移除并返回列表左侧的第一个元素，没有则返回nil

RPUSH keyelement..：向列表右侧插入一个或多个元素

RPOP key：移除并返回列表右侧的第一个元素

LRANGE key star end：返回一段角标范围内的所有元素

BLPOP和BRPOP：与LPOP和RPOP类似，只不过在没有元素时等待指定时间，而不是直接返回nil（阻塞式的等待）

set类型

redis的set结构类似集合，可以看作是一个value为null的hashmap。特性：

无序

元素不可重复

查找快

支持交集、并集、差集等功能

常见指令

String的常见命令有：

SADD key member ..：向set中添加一个或多个元素

SREM key member ...：移除set中的指定元素

SCARD key：返回set中元素的个数

SISMEMBER key member：判断一个元素是否存在于set中

SMEMBERS：获取set中的所有元素

SINTER key1 key2 .：求key1与key2的交集

SDIFF key1 key2...：求key1与key2的差集

SUNION key1 key2..:求key1和key2的并集

sortedset类型

redis 的sortedset是一个可排序的set集合。每个元素都带有一个score属性，可以基于score属性对元素排序，底层的实现是一个跳表加hash表。特性：

可排序

元素不重复

查询速度快

因为可排序的特性，常被用于实现排行榜等功能。

常用命令

SortedSet的常见命令有：

ZADD key score member：添加一个或多个元素到sorted set，如果已经存在则更新其score值

ZREM key member：删除sorted set中的一个指定元素

ZSCORE key member：获取sorted set中的指定元素的score值

ZRANK key member：获取sorted set 中的指定元素的排名

ZCARD key:获取sorted set中的元素个数

ZCOUNT key min max：统计score值在给定范围内的所有元素的个数

ZINCRBY key increment member:让sorted set中的指定元素自增，步长为指定的increment值

ZRANGE key min max：按照score排序后，获取指定排名范围内的元素

ZRANGEBYSCORE key min max：按照score排序后，获取指定score范围内的元素

ZDIFF、ZINTER、ZUNION：求差集、交集、并集

所有命令默认是升序排名，如果需要降序排名，直接在命令的z后面加上rev即可

分布式缓存

单点redis存在的部分问题

数据丢失问题：由于是在内存中存储数据，服务器重启后会导致数据丢失

并发能力问题：单节点redis并发能力虽然不错，但是无法满足高并发的服务场景

故障恢复问题：如果redis当即，则服务不可以，需要一种自动的故障恢复手段。

存储能力问题：数据存储在内存，单节点难以满足海量数据的存储需求

解决方案：实现redis数据持久化；搭建主从集群，实现读写分离；利用redis哨兵，实现健康检测和自动恢复；搭建分片集群，利用插槽机制实现动态扩容。

redis持久化

RDB持久化

RDB是redis数据备份文件，也叫redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当redis示例故障重启后，从磁盘读取快照文件，恢复数据。

快照文件被称为RDB文件，默认是保存到当前目录。

当使用save命令执行rdb时会阻塞所有命令。推荐使用bgsave开启子进程执行rdb，避免主进程收到影响。一般是在redis停机时会执行一次rdb。

redis内部有触发rdb的机制，可以在redis.conf文件中找到，格式如下：

rdb的其他配置也可以设置

RDB的fork原理

bgsave开始时会fork主进程，子进程共享主进程的内存数据。完成fork（fork是阻塞的）后读取内存数据并写入RDB文件（此过程是异步执行）

主进程操作操作系统提供的虚拟内存，再通过操作系统提供的虚拟内存到物理内存的映射关系来修改物理内存，映射关系存储在页表中。调用fork就是把映射关系拷贝给子进程，映射关系一样就实现了主进程和子进程内存的共享。缩短了拷贝时间，实现异步持久化。

为了避免拷贝时的读写冲突，拷贝时的数据是被标记为只读的，主进程和子进程都只能读取，当主进程接收到写请求时会拷贝对应数据，创建副本，当再次写该数据时仍然写进副本中。会增加内存占用，最坏情况下当所有字段都在拷贝时被修改时，所有字段都会出现一个副本，都需要重新拷贝，而且会使得内存翻倍。

RDB缺点：

RDB执行间隔时间长，两次RDB之间写入数据会有丢失的风险。

fork子进程、压缩、写出RDB文件比较耗时。

RDB是全量快照，执行时间长，耗时，每次执行都会把整个内存数据写入磁盘。执行间隔变长可以减少数据持久化产生的开销，但是执行间隔越长，由redis宕机可能造成的数据丢失风险也越高。

AOF持久化

AOF全称是追加文件appendonly。redis处理的每个写命令都被记录到AOF文件，可以看作是命令日志文件。文件中记录的是命令，如果出现数据丢失，可以将命令重新执行以恢复数据。

AOF默认是关闭的，需要修改配置文件来开启AOF

AOF命令记录的频率也可通过修改配置文件来设置

第一种方案是写内存和写磁盘同时进行，数据的安全性最高，最多丢失宕机前的一条命令，但是性能最差；第二种是将命令写入缓冲区，每隔1s写入磁盘，最多丢失宕机前1s的命令，性能会有提升，也是默认方案；第三种是将写磁盘频率交给操作系统，性能最好，但是安全性最低，写磁盘的频率通常很低。

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

redis主从

搭建主从架构

单点redis 的并发能力是有上限的，要进一步提高redis的并发能力就需要搭建主从集群，实现读写分离。

基础架构如下

要配置主从可以使用replicaof或者slaveof（5.0以前）命令

有临时和永久两种模式：

●修改配置文件（永久生效)

在redis.conf中添加一行配置：slaveof <masterip> <masterport>

●使用redis-cli客户端连接到redis服务，执行slaveof命令（重启后失效）：

slaveof <masterip> <masterport>

数据同步原理

全量同步

主从第一次同步是全量同步

master如何判断slave是否是第一次来同步数据：

Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid

offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此slave做数据同步，必须向master声明自己的replication id和offset，master才可以判断到底需要同步哪些数据

简述全量同步的流程？

slave节点请求增量同步

master节点判断replid，发现不一致，拒绝增量同步

master将完整内存数据生成RDB，发送RDB到slave

slave清空本地数据，加载master的RDB

master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave

slave执行接收到的命令，保持与master之间的同步

增量同步

如果slave重启后同步就执行增量同步

baklog是一个环状缓冲区，新的数据会追加覆盖旧的数据，如果offset差距过大，超过整个baklog，就无法进行增量同步，需要进行全量同步。

数据同步优化

可以从以下几个方面来优化redis主从集群

在master中配置repl-diskless-sync yes启动无磁盘复制，避免全量同步时的磁盘IO。

控制redis单点上的内存占用上限，减少RDB导致的过多磁盘IO

适当提高repl_baklog的大小，当slave宕机时尽快进行故障恢复，尽可能避免全量同步

限制从节点数量，如果从节点过多，采用主-从-从的链式结构，减少master压力。

|------------|----------|------------|
| 方面 | 有磁盘复制 | 无磁盘复制 |
| 磁盘 I/O | 高（读写两次） | 低（完全跳过） |
| 网络流量 | 相同 | 相同 |
| 内存占用 | 低 | 高（RDB 在内存） |
| CPU 占用 | 中等 | 高（压缩 RDB） |
| 复制速度 | 慢 | 快 |
| 多从节点 | 每个都写一次磁盘 | 共享一份数据流 |
| 可靠性 | 高（磁盘有备份） | 中（网络中断丢失） |

|--------------|--------------------------|
| 什么是无磁盘复制 | 主节点直接向从节点发送 RDB，跳过磁盘读写 |
| 核心优势 | 减少磁盘 I/O，加快复制速度，多从节点共享快照 |
| 何时使用 | 磁盘是瓶颈、多从节点连接、数据集较大 |
| 何时不用 | 网络不稳定、内存紧张、从节点稀疏连接 |

简述全量同步和增量同步区别？

全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。

增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

什么时候执行全量同步？

slave节点第一次连接master节点时

slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

什么时候执行增量同步？

slave节点断开又恢复，并且在repl_baklog中能找到offset时

redis哨兵

如果master宕机时用户有写请求要怎么办？

解决方案：选择一个slave作为新的master。使用哨兵来监测集群和实现主从切换。

哨兵的作用与原理

作用：redis提供了哨兵sentinel机制来实现主从集群的自动故障恢复。结构如下：

为防止哨兵宕机，哨兵也需要是集群。

监控：Sentinel会不断检查您的master和slave是否按预期工作

自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主

通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端

服务状态监控

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线（也可能是网络阻塞）。

客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

选举新的master

一旦发现master故障sentinel需要在slave中选择一个作为新的master，选择依据是：

首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds＊10）则会排除该slave节点

然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举

如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高

最后是判断slave节点的运行id大小越小优先级越高。（这里的runid与repliid不同，是每个redis启动时随机生成的唯一标识，用于区分不同的redis进程，与集群id无关）

当选中了其中一个slave为新的master后（例如slave1），故障的转移的步骤如下:

sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master

sentinel给所有其它slave发送slaveof 192.168.150.101 7002命令，让这些slave成为新master的从节点，开始从新的master上同步数据。

最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点

总结

Sentinel的三个作用是什么？

监控

故障转移

通知

Sentinel如何判断一个redis实例是否健康？

每隔1秒发送一次ping命令，如果超过一定时间没有相向则认为是主观下线

如果大多数sentinel都认为实例主观下线，则判定服务下线

故障转移步骤有哪些？

首先选定一个slave作为新的master，执行slaveof no one

然后让所有节点都执行slaveof 新master

修改故障节点配置，添加slaveof 新master

redis分片集群

分片集群结构

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：

海量数据存储问题

高并发写的问题

使用分片集群可以解决上述问题，分片集群特征：

集群中有多个master，每个master保存不同数据

每个master可以有多个slave节点

master之间可以通过ping检测彼此的健康状态。

散列插槽

redis会把每个master映射到0-16383个插槽hash slot上，查看集群信息可以看到

数据key不是与节点绑定，而是与插槽绑定。redis会根据key的有效部分计算插槽值，分两种情况

key中包含"{}"，且"{}"中至少包含1个字符，"{}"中的部分是有效部分

key中不包含"{}"，整个key都是有效部分

为了实现将部分key不同的数据划分到相同的节点（控制key的有效部分，计算得到相同的插槽值，从而使得数据保存在相同节点）

例如：key是num，那么就根据num计算，如果是{itcast}num，则根据itcast计算。计算方式是利用cRc16算法得到一个hash值，然后对16384取余，得到的结果就是slot值。

当访问集群中的任意一个节点并修改key时，会先根据key计算插槽值，并根据插槽值路由数据，从而获取value。

集群伸缩

添加一个节点到集群

redis-cli --cluster提供了许多操作集群的命令，可以根据以下方式查看

例如添加节点的指令

故障转移

自动故障转移：

当集群中有一个master宕机

1.首先是该实例与其它实例失去连接

2．然后是疑似宕机：

3.最后是确定下线，自动提升一个slave为新的master

手动故障转移

数据迁移

利用cluster failover命令可以手动让集群中的某个master宕机，切换到执行cluster failover命令的这个slave节点，实现无感知的数据迁移。其流程如下：

手动的Failover支持三种不同模式：

缺省：默认的流程，如图1~6步

force：省略了对offset的一致性校验

takeover：直接执行第5步，忽略数据一致性、忽略master状态和其它master的意见

多级缓存

什么是多级缓存

传统缓存的问题

请求到达romcat后，先查询redis，如果未命中则查询数据库，存在下面问题：

请求需要经过tomcat处理，tomcat的性能称为整个系统的瓶颈

redis请求失效时，会对数据库产生冲击

多级缓存方案

多级缓存就是充分利用请求处理的每个环节，分别添加缓存，减去tomcat的压力，提升服务性能。

本地进程缓存

|------------|-------|---------|---------|----------|-----|
| 缓存类型 | 位置 | 速度 | 共享范围 | 容量 | 持久化 |
| 本地进程缓存 | 进程内存 | 极快（纳秒） | 单进程 | 小（MB-GB） | 否 |
| Redis | 远程服务器 | 快（毫秒） | 多进程/服务器 | 大（GB-TB） | 可选 |
| 数据库 | 磁盘 | 慢（毫秒-秒） | 全局 | 非常大 | 是 |

缓存在日常开发中启动至关重要的作用，由于是存储在内存中，数据的读取速度是非常快的，能大量减少对数据库的访问，减少数据库的压力。我们把缓存分为两类：

分布式缓存，例如Redis:

优点：存储容量更大、可靠性更好、可以在集群间共享

缺点：访问缓存有网络开销

场景：缓存数据量较大、可靠性要求较高、需要在集群间共享

进程本地缓存，例如HashMap、GuavaCache:

优点：读取本地内存，没有网络开销，速度更快

缺点：存储容量有限、可靠性较低、无法共享

场景：性能要求较高，缓存数据量较小

lua语法

Lua 是一种轻量小巧的脚本语言，用标准C语言编写并以源代码形式开放，其设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能。

变量和循环

table类型其实更类似map，属于kv数据结构。

lua生命变量的时候，并不需要指定数据类型，lua的索引是从1开始的

访问table

数组、table都可以用for循环来遍历

遍历数组

遍历table

函数

定义函数的语法：

例如，定义一个函数，用来打印数组：

条件控制

例如if、else语法：

布尔表达式中的逻辑运算是基于英文单词：

|-----|-----------------------------------------|----------------------|
| 操作符 | 描述 | 实例 |
| and | 逻辑与操作符。若 A 为 false，则返回 A，否则返回 B。 | (A and B) 为 false。 |
| or | 逻辑或操作符。若 A 为 true，则返回 A，否则返回 B。 | (A or B) 为 true。 |
| not | 逻辑非操作符。与逻辑运算结果相反，如果条件为 true，逻辑非为 false。 | not(A and B) 为 true。 |

缓存预热

冷启动：服务刚刚启动时，Redis中并没有缓存，如果所有商品数据都在第一次查询时添加缓存，可能会给数据库带来较大压力。

缓存预热：在实际开发中，我们可以利用大数据统计用户访问的热点数据，在项目启动时将这些热点数据提前查询并保存到Redis中。

数据量较少时，可以在启动时将所有数据都放入缓存中。

缓存同步

数据同步策略

缓存同步问题：数据库发生了修改，导致数据库数据与缓存数据不一致

缓存数据同步的常见方式有三种：

设置有效期：给缓存设置有效期，到期后自动删除。再次查询时更新

优势：简单、方便

缺点：时效性差，缓存过期之前可能不一致

场景：更新频率较低，时效性要求低的业务

同步双写：在修改数据库的同时，直接修改缓存

优势：时效性强，缓存与数据库强一致

缺点：有代码侵入，耦合度高；

场景：对一致性、时效性要求较高的缓存数据

异步通知：修改数据库时发送事件通知，相关服务监听到通知后修改缓存数据

优势：低耦合，可以同时通知多个缓存服务

缺点：时效性一般，可能存在中间不一致状态

场景：时效性要求一般，有多个服务需要同步

Redis最佳实践

键值设计

优雅的key结构

redis的key虽然可以自定义，但是最好遵循以下几个最佳实践约定

遵循基本格式：[业务名称]:[数据名]:[id]

长度不超过44字节

不包括特殊字符

例如：

优点：

可读性强

避免（不同业务之间或数据结构之间）key冲突

方便管理

更节省内存：key是string类型，底层编码包含int、embstr和raw三种。embstr在小于44字节使用，采用连续内存空间，内存占用更小。当字节数大于44字节时，会转为raw模式存储，在raw模式下，内存空间不是连续的，而是采用一个指针指向了另外一段内存空间，在这段空间里存储SDS内容，这样空间不连续，访问的时候性能也就会收到影响，还有可能产生内存碎片

bigkey问题

BigKey通常以Key的大小和Key中成员的数量来综合判定，例如：

Key本身的数据量过大：一个String类型的Key，它的值为5MB

Key中的成员数过多：一个ZSET类型的Key，它的成员数量为10,000个

Key中成员的数据量过大：一个Hash类型的Key，它的成员数量虽然只有1,000个但这些成员的Value（值）总大小为100 MB

推荐值：

单个key的value小于10KB

对于集合类型的key，建议元素数量小于1000

BigKey的危害

网络阻塞：对BigKey执行读请求时，少量的QPS就可能导致带宽使用率被占满，导致Redis实例，乃至所在物理机变慢

数据倾斜：BigKey所在的Redis实例内存使用率远超其他实例，无法使数据分片的内存资源达到均衡

Redis阻塞：对元素较多的hash、list、zset等做运算会耗时较旧，使主线程被阻塞

CPU压力：对BigKey的数据序列化和反序列化会导致CPU的使用率飙升，影响Redis实例和本机其它应用

如何发现bigkey

redis-cli --bigkeys

利用redis-cli提供的--bigkeys参数，可以遍历分析所有key，并返回Key的整体统计信息与每个数据的Top1的big key

分析时会阻塞主线程，生产环境下不推荐使用

命令：redis-cli -a 密码 --bigkeys

scan扫描

自己编程，利用scan扫描Redis中的所有key，利用strlen、hlen等命令判断key的长度（此处不建议使用MEMORY USAGE）不会阻塞主线程

scan 命令调用完后每次会返回2个元素，第一个是下一次迭代的光标，第一次光标会设置为0，当最后一次scan 返回的光标等于0时，表示整个scan遍历结束了，第二个返回的是List，一个匹配的key的数组

第三方工具

利用第三方工具，如 Redis-Rdb-Tools 分析RDB快照文件，全面分析内存使用情况

网络监控

自定义工具，监控进出Redis的网络数据，超出预警值时主动告警

一般阿里云搭建的云服务器就有相关监控页面

如何删除BigKey

BigKey内存占用较多，即便时删除这样的key也需要耗费很长时间，导致Redis主线程阻塞，引发一系列问题。

redis 3.0 及以下版本，如果是集合类型，则遍历BigKey的元素，先逐个删除子元素，最后删除BigKey。Redis 4.0以后，Redis在4.0后提供了异步删除的命令：unlink

恰当的数据类型

比如存储一个User对象，我们有三种存储方式：

①方式一：json字符串

|------------|---------------------------------|
| user:1 | {"name": "Jack", "age": 21} |

优点：实现简单粗暴

缺点：数据耦合，不够灵活

②方式二：字段打散

|-----------------|----------|
| user:1:name | Jack |
| user:1:age | 21 |

优点：可以灵活访问对象任意字段

缺点：占用空间大、没办法做统一控制

③方式三：hash（推荐）

|--------|------|------|
| user:1 | name | jack |
| user:1 | age | 21 |

优点：底层使用ziplist，空间占用小，可以灵活访问对象的任意字段

缺点：代码相对复杂

假如有hash类型的key，其中有100万对field和value，field是自增id，这个key存在什么问题？如何优化？

|---------|-----------|-------------|
| key | field | value |
| someKey | id:0 | value0 |
| someKey | ..... | ..... |
| someKey | id:999999 | value999999 |

存在的问题：

hash的entry数量超过500时，会使用哈希表而不是ZipList，内存占用较多
可以通过hash-max-ziplist-entries配置entry上限。但是如果entry过多就会导致BigKey问题

方案一

拆分为string类型

|-----------|-------------|
| key | value |
| id:0 | value0 |
| ..... | ..... |
| id:999999 | value999999 |

存在的问题：

string结构底层没有太多内存优化，内存占用较多
想要批量获取这些数据比较麻烦

方案二

拆分为小的hash，将 id / 100 作为key，将id % 100 作为field，这样每100个元素为一个Hash

|----------|-------|-------------|
| key | field | value |
| key:0 | id:00 | value0 |
| key:0 | ..... | ..... |
| key:0 | id:99 | value99 |
| key:1 | id:00 | value100 |
| key:1 | ..... | ..... |
| key:1 | id:99 | value199 |
| .... |||
| key:9999 | id:00 | value999900 |
| key:9999 | ..... | ..... |
| key:9999 | id:99 | value999999 |

总结

Key的最佳实践

- 固定格式：[业务名]:[数据名]:[id]
- 足够简短：不超过44字节
- 不包含特殊字符

Value的最佳实践：

- 合理的拆分数据，拒绝BigKey
- 选择合适数据结构
- Hash结构的entry数量不要超过1000
- 设置合理的超时时间

批处理优化

单个命令的执行流程

N条命令的执行流程就是N次命令的响应时间=N次往返的网络传输耗时+N次Redis执行命令耗时

redis处理指令是很快的，主要花费的时候在于网络传输。于是乎很容易想到将多条指令批量的传输给redis

Mset：Redis提供了很多Mxxx这样的命令，可以实现批量插入数据，例如：

mset

hmset

Pipeline：MSET虽然可以批处理，但是却只能操作部分数据类型，因此如果有对复杂数据类型的批处理需要，建议使用Pipeline

注意事项：

①批处理时不建议一次携带太多命令

②Pipeline的多个命令之间不具备原子性

集群下的批处理

如MSET或Pipeline这样的批处理需要在一次请求中携带多条命令，而此时如果Redis是一个集群，那批处理命令的多个key必须落在一个插槽中，否则就会导致执行失败。这样的要求其实很难实现，因为我们在批处理时，可能一次要插入很多条数据，这些数据很有可能不会都落在相同的节点上，这就会导致报错了

这个时候，可以找到4种解决方案

第一种方案：串行执行，优点是执行起来很简单，缺点是耗时过久。

第二种方案：串行slot，执行前，客户端先计算一下对应的key的slot，一样slot的key就放到一个组里边，不同的，就放到不同的组里边，然后对每个组执行pipeline的批处理，他就能串行执行各个组的命令，这种做法比第一种方法耗时要少，缺点是相对来说复杂一点，所以这种方案还需要优化一下

第三种方案：并行slot，相较于第二种方案，在分组完成后串行执行，第三种方案，就变成了并行执行各个命令，所以他的耗时就非常短，但是实现也更加复杂。

第四种：hash_tag，redis计算key的slot的时候，其实是根据key的有效部分来计算的，通过这种方式就能一次处理所有的key，这种方式耗时最短，实现也简单，但是如果通过操作key的有效部分，那么就会导致所有的key都落在一个节点上，产生数据倾斜的问题，所以推荐使用第三种方式。

服务端优化

持久化配置

Redis的持久化虽然可以保证数据安全，但也会带来很多额外的开销，因此持久化请遵循下列建议：

用来做缓存的Redis实例尽量不要开启持久化功能
建议关闭RDB持久化功能，使用AOF持久化
利用脚本定期在slave节点做RDB，实现数据备份
设置合理的rewrite（AOF重写命令，对cpu消耗大）阈值，避免频繁的bgrewrite
配置no-appendfsync-on-rewrite = yes，禁止在rewrite期间做aof，避免因AOF引起的阻塞

如果开启此配置，aof的大致流程就是首先主进程fork一个子进程，子进程获取到主进程的aof文件并进行bgrewrite操作，生成一个临时的aof文件，然后主进程在bgrewrite期间接收到的写请求命令会被记录到一个aof缓冲区中，当子进程的bgrewrite完成后，aof缓冲区中的内容会被直接追加到临时aof文件中。此时rewrite结束，才开始进行扫盘操作，调用fsync() 临时aof文件扫入磁盘，扫入后进行rename（）操作，子进程将临时aof文件交付给主进程（准确的说是将临时aof文件名与主进程的aof文件名互换）。此时aof结束。

部署有关建议：

- Redis实例的物理机要预留足够内存，应对fork和rewrite
- 单个Redis实例内存上限不要太大，例如4G或8G。可以加快fork的速度、减少主从同步、数据迁移压力
- 不要与CPU密集型应用部署在一起
- 不要与高硬盘负载应用一起部署。例如：数据库、消息队列

慢查询

并不是很慢的查询才是慢查询，而是：在Redis执行时耗时超过某个阈值的命令，称为慢查询。

慢查询的危害：由于Redis是单线程的，所以当客户端发出指令后，他们都会进入到redis底层的queue来执行，如果此时有一些慢查询的数据，就会导致大量请求阻塞，从而引起报错，所以我们需要解决慢查询问题。

慢查询的阈值可以通过配置指定：slowlog-log-slower-than：慢查询阈值，单位是微秒。默认是10000，建议1000

慢查询会被放入慢查询日志中，日志的长度有上限，可以通过配置指定：slowlog-max-len：慢查询日志（本质是一个队列）的长度。默认是128，建议1000

可以使用config get获取配置值并使用config set设置这个值。

查询慢查询日志：

slowlog len：查询慢查询日志长度
slowlog get [n]：读取n条慢查询日志
slowlog reset：清空慢查询列表

Redis内存划分和内存配置

当Redis内存不足时，可能导致Key频繁被删除、响应时间变长、QPS不稳定等问题。当内存使用率达到90%以上时就需要我们警惕，并快速定位到内存占用的原因。

有关碎片问题分析

Redis底层分配并不是这个key有多大，他就会分配多大，而是有他自己的分配策略，比如8,16,20等等，假定当前key只需要10个字节，此时分配8肯定不够，那么他就会分配16个字节，多出来的6个字节就不能被使用，这就是我们常说的内存碎片问题。

**进程内存问题分析：**这片内存，通常我们都可以忽略不计

缓冲区内存问题分析：

一般包括客户端缓冲区、AOF缓冲区、复制缓冲区等。客户端缓冲区又包括输入缓冲区和输出缓冲区两种。这部分内存占用波动较大，所以这片内存也是我们需要重点分析的内存问题。

|----------|----------------------------------------------------------------------------------|
| 内存占用 | 说明 |
| 数据内存 | 是Redis最主要的部分，存储Redis的键值信息。主要问题是BigKey问题、内存碎片问题 |
| 进程内存 | Redis主进程本身运⾏肯定需要占⽤内存，如代码、常量池等等；这部分内存⼤约⼏兆，在⼤多数⽣产环境中与Redis数据占⽤的内存相⽐可以忽略。 |
| 缓冲区内存 | 一般包括客户端缓冲区、AOF缓冲区、复制缓冲区等。客户端缓冲区又包括输入缓冲区和输出缓冲区两种。这部分内存占用波动较大，不当使用BigKey，可能导致内存溢出。 |

通过一些命令，可以查看到Redis目前的内存分配状态：

info memory：查看内存分配的情况

memory xxx：查看key的主要占用情况

内存缓冲区常见的有三种：

复制缓冲区：主从复制的repl_backlog_buf，如果太小可能导致频繁的全量复制，影响性能。通过replbacklog-size来设置，默认1mb
AOF缓冲区：AOF刷盘之前的缓存区域，AOF执行rewrite的缓冲区。无法设置容量上限
客户端缓冲区：分为输入缓冲区和输出缓冲区，输入缓冲区最大1G且不能设置。输出缓冲区可以设置

以上复制缓冲区和AOF缓冲区不会有问题，最关键就是客户端缓冲区的问题

客户端缓冲区：指的就是我们发送命令时，客户端用来缓存命令的一个缓冲区，也就是我们向redis输入数据的输入端缓冲区和redis向客户端返回数据的响应缓存区，输入缓冲区最大1G且不能设置，所以这一块我们根本不用担心，如果超过了这个空间，redis会直接断开，因为本来此时此刻就代表着redis处理不过来了，我们需要担心的就是输出端缓冲区

我们在使用redis过程中，处理大量的big value，那么会导致我们的输出结果过多，如果输出缓存区过大，会导致redis直接断开，而默认配置的情况下，其实他是没有大小的，这就比较坑了，内存可能一下子被占满，会直接导致咱们的redis断开，所以解决方案有两个

1、设置一个大小

2、增加我们带宽的大小，避免我们出现大量数据从而直接超过了redis的承受能力

集群最佳实践

集群虽然具备高可用特性，能实现自动故障恢复，但是如果使用不当，也会存在一些问题：

集群完整性问题
集群带宽问题
数据倾斜问题
客户端性能问题
命令的集群兼容性问题
lua和事务问题

在Redis的默认配置中，如果发现任意一个插槽不可用，则整个集群都会停止对外服务：

大家可以设想一下，如果有几个slot不能使用，那么此时整个集群都不能用了，在开发中，其实最重要的是可用性，所以需要把如下配置修改成no，即有slot不能使用时，redis集群还是可以对外提供服务

集群带宽问题

集群节点之间会不断的互相Ping来确定集群中其它节点的状态。每次Ping携带的信息至少包括：

插槽信息
集群状态信息

集群中节点越多，集群状态信息数据量也越大，10个节点的相关信息可能达到1kb，此时每次集群互通需要的带宽会非常高，这样会导致集群中大量的带宽都会被ping信息所占用，这是一个非常可怕的问题，所以我们需要去解决这样的问题

解决途径：

避免大集群，集群节点数不要太多，最好少于1000，如果业务庞大，则建立多个集群。
避免在单个物理机中运行太多Redis实例
配置合适的cluster-node-timeout值

命令的集群兼容性问题

当我们使用批处理的命令时，redis要求我们的key必须落在相同的slot上，然后大量的key同时操作时，是无法完成的，所以客户端必须要对这样的数据进行处理

lua和事务的问题

lua和事务都是要保证原子性问题，如果你的key不在一个节点，那么是无法保证lua的执行和事务的特性的，所以在集群模式是没有办法执行lua和事务的

到底是集群还是主从

单体Redis（主从Redis）已经能达到万级别的QPS，并且也具备很强的高可用特性。如果主从能满足业务需求的情况下，所以如果不是在万不得已的情况下，尽量不搭建Redis集群

Redis数据结构

动态字符串

我们都知道Redis中保存的Key是字符串，value往往是字符串或者字符串的集合。可见字符串是Redis中最常用的一种数据结构。

不过Redis没有直接使用C语言中的字符串（字符数组），因为C语言字符串存在很多问题：

获取字符串长度的需要通过运算

非二进制安全

不可修改

Redis构建了一种新的字符串结构，称为简单动态字符串（Simple Dynamic String），简称SDS。

Redis是C语言实现的，其中SDS是一个结构体，源码如下：

例如，一个包含字符串"name"的sds结构如下：

SDS之所以叫做动态字符串，是因为它具备动态扩容的能力，例如一个内容为"hi"的SDS

假如我们要给SDS追加一段字符串",Amy"，这里首先会申请新内存空间：

如果新字符串小于1M，则新空间为扩展后字符串长度的两倍+1；

如果新字符串大于1M，则新空间为扩展后字符串长度+1M+1。称为内存预分配。

优点是

获取字符串长度的时间复杂度为O(1)

支持动态扩容

减少内存分配次数

二进制安全

intset

IntSet是Redis中set集合的一种实现方式，基于整数数组来实现，并且具备长度可变、有序等特征。结构如下：

其中的encoding包含三种模式，表示存储的整数大小不同：

为了方便查找，Redis会将intset中所有的整数按照升序依次保存在contents数组中，结构如图：

我们向该其中添加一个数字：50000，这个数字超出了int16_t的范围，intset会自动升级编码方式到合适的大小。以当前案例来说流程如下：

升级编码为INTSET_ENC_INT32, 每个整数占4字节，并按照新的编码方式及元素个数扩容数组
倒序依次将数组中的元素拷贝到扩容后的正确位置（从后往前拷贝防止覆盖其他数据）
将待添加的元素放入数组末尾
最后，将intset的encoding属性改为INTSET_ENC_INT32，将length属性改为4

源码如下：

上面原码中的intsetsearch函数是采用的二分查找

Intset可以看做是特殊的整数数组，具备一些特点：

Redis会确保Intset中的元素唯一、有序
具备类型升级机制，可以节省内存空间
底层采用二分查找方式来查询

Dict

我们知道Redis是一个键值型（Key-Value Pair）的数据库，我们可以根据键实现快速的增删改查。而键与值的映射关系正是通过Dict来实现的。

Dict由三部分组成，分别是：哈希表（DictHashTable）、哈希节点（DictEntry）、字典（Dict）

当我们向Dict添加键值对时，Redis首先根据key计算出hash值（h），然后利用 h & sizemask来计算元素应该存储到数组中的哪个索引位置。我们存储k1=v1，假设k1的哈希值h =1，则1&3 =1，因此k1=v1要存储到数组角标1位置。

Dict由三部分组成，分别是：哈希表（DictHashTable）、哈希节点（DictEntry）、字典（Dict）

dict的扩容

Dict中的HashTable就是数组结合单向链表的实现，当集合中元素较多时，必然导致哈希冲突增多，链表过长，则查询效率会大大降低。

Dict在每次新增键值对时都会检查负载因子（LoadFactor = used/size），满足以下两种情况时会触发哈希表扩容：

哈希表的 LoadFactor >= 1，并且服务器没有执行 BGSAVE 或者 BGREWRITEAOF 等后台进程（此时容易导致主进程阻塞）；

哈希表的 LoadFactor > 5 ；

dict的收缩

Dict除了扩容以外，每次删除元素时，也会对负载因子做检查，当LoadFactor<0.1时，会做哈希表收缩：

dict的rehash

不管是扩容还是收缩，必定会创建新的哈希表，导致哈希表的size和sizemask变化，而key的查询与sizemask有关。因此必须对哈希表中的每一个key重新计算索引，插入新的哈希表，这个过程称为rehash。过程是这样的：

计算新hash表的realeSize，值取决于当前要做的是扩容还是收缩：

- 如果是扩容，则新size为第一个大于等于dict.ht[0].used + 1的2^n
- 如果是收缩，则新size为第一个大于等于dict.ht[0].used的2^n （不得小于4）

按照新的realeSize申请内存空间，创建dictht，并赋值给dict.ht[1]
设置dict.rehashidx = 0，标示开始rehash
将dict.ht[0]中的每一个dictEntry都rehash到dict.ht[1]
将dict.ht[1]赋值给dict.ht[0]，给dict.ht[1]初始化为空哈希表，释放原来的dict.ht[0]的内存
将rehashidx赋值为-1，代表rehash结束
在rehash过程中，新增操作，则直接写入ht[1]，查询、修改和删除则会在dict.ht[0]和dict.ht[1]依次查找并执行。这样可以确保ht[0]的数据只减不增，随着rehash最终为空

整个过程可以描述成：

Dict的rehash并不是一次性完成的。试想一下，如果Dict中包含数百万的entry，要在一次rehash完成，极有可能导致主线程阻塞。因此Dict的rehash是分多次、渐进式的完成，因此称为渐进式rehash。流程如下：

1.计算新hash表的size，值取决于当前要做的是扩容还是收缩：

如果是扩容，则新size为第一个大于等于dict.ht[o].used+1的2"

如果是收缩，则新size为第一个大于等于dict.ht[o].used的2"（不得小于4）

2.按照新的size申请内存空间，创建dictht，并赋值给dict.ht[1]

3.设置dict.rehashidx = 0，标示开始rehash

4.每次执行新增、查询、修改、删除操作时，都检查一下dict.rehashidx是否大于-1，如果是则将dict.ht[o].table[rehashidx]的entry链表rehash到dict.ht[1]，并且将rehashidx++。直至dict.ht[o]的所有数据都rehash到dict.ht[1]

5.将dict.ht[1]赋值给dict.ht[o]，给dict.ht[1]初始化为空哈希表，释放原来的dict.ht[o]的内存

6.将rehashidx赋值为-1，代表rehash结束

7.在rehash过程中，新增操作，则直接写入ht[1]，查询、修改和删除则会在dict.ht[o]和dict.ht[1]依次查找并执行。这样可以确保ht[o]的数据只减不增，随着rehash最终为空

Dict的结构：

类似java的HashTable，底层是数组加链表来解决哈希冲突
Dict包含两个哈希表，ht[0]平常用，ht[1]用来rehash

Dict的伸缩：

当LoadFactor大于5或者LoadFactor大于1并且没有子进程任务时，Dict扩容
当LoadFactor小于0.1时，Dict收缩
扩容大小为第一个大于等于used + 1的2^n
收缩大小为第一个大于等于used 的2^n
Dict采用渐进式rehash，每次访问Dict时执行一次rehash
rehash时ht[0]只减不增，新增操作只在ht[1]执行，其它操作在两个哈希表

ZipList

ZipList 是一种特殊的"双端链表"（模拟链表），由一系列特殊编码的连续内存块组成。可以在任意一端进行压入/弹出操作, 并且该操作的时间复杂度为 O(1)。

|---------|----------|--------|--------------------------------------------------------------------------------------|
| 属性 | 类型 | 长度 | 用途 |
| zlbytes | uint32_t | 4 字节 | 记录整个压缩列表占用的内存字节数 |
| zltail | uint32_t | 4 字节 | 记录压缩列表表尾节点距离压缩列表的起始地址有多少字节，通过这个偏移量，可以确定表尾节点的地址。 |
| zllen | uint16_t | 2 字节 | 记录了压缩列表包含的节点数量。最大值为UINT16_MAX （65534），如果超过这个值，此处会记录为65535，但节点的真实数量需要遍历整个压缩列表才能计算得出。 |
| entry | 列表节点 | 不定 | 压缩列表包含的各个节点，节点的长度由节点保存的内容决定。 |
| zlend | uint8_t | 1 字节 | 特殊值 0xFF （十进制 255 ），用于标记压缩列表的末端。 |

ZipListEntry

ZipList 中的Entry并不像普通链表那样记录前后节点的指针，因为记录两个指针要占用16个字节，浪费内存。而是采用了下面的结构，每个entry包含以下三部分：

previous_entry_length：前一节点的长度，占1个或5个字节。（方便方向遍历）

- 如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值
- 如果前一节点的长度大于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据

encoding：编码属性，记录content的数据类型（字符串还是整数）以及长度，占用1个、2个或5个字节（方便对后续节点的遍历）
contents：负责保存节点的数据，可以是字符串或整数

ZipList中所有存储长度的数值均采用小端字节序，即低位字节在前，高位字节在后。例如：数值0x1234，采用小端字节序后实际存储值为：0x3412

Encoding编码

ZipListEntry中的encoding编码分为字符串和整数两种：字符串：如果encoding是以"00"、"01"或者"10"开头，则证明content是字符串

|------------------------------------------------------|----------|----------------------|
| 编码 | 编码长度 | 字符串大小 |
| |00pppppp| | 1 bytes | <= 63 bytes |
| |01pppppp|qqqqqqqq| | 2 bytes | <= 16383 bytes |
| |10000000|qqqqqqqq|rrrrrrrr|ssssssss|tttttttt| | 5 bytes | <= 4294967295 bytes |

5B 之所以采用这种编码方式，是在成本、效率和鲁棒性之间的综合考量。

成本与效率：若1B/2B与数字编码也采用同样的前缀压缩来表示长度，会增加内存占用、降低缓存命中率。因此只对5B使用独立的长度字段（后续四字节），因为5B的使用频率很低，对总体成本影响小。
鲁棒性：1B/2B和整数编码通常处理较小的数据，单比特翻转等错误对它们的影响较小。通过前缀两位实现四种编码的路由，可以在编码路径上保持明确分离，遇到错误时仍能根据编码特征进行回落判断，从而提升鲁棒性。例如，5B 的前两位设为10，且第一字节的后六位为0，这提供了一个明确的标记，便于解码时判断应进入5B路径，降低因错误导致的误解。短串走1B/2B的紧凑路径，极长的串才进入5B，这样在保持紧凑性的同时提升了容错能力。

例如，我们要保存字符串："ab"和 "bc"

ZipListEntry中的encoding编码分为字符串和整数两种：

整数：如果encoding是以"11"开始，则证明content是整数，且encoding固定只占用1个字节

|----------|----------|---------------------------------------|
| 编码 | 编码长度 | 整数类型 |
| 11000000 | 1 | int16_t（2 bytes） |
| 11010000 | 1 | int32_t（4 bytes） |
| 11100000 | 1 | int64_t（8 bytes） |
| 11110000 | 1 | 24位有符整数(3 bytes) |
| 11111110 | 1 | 8位有符整数(1 bytes) |
| 1111xxxx | 1 | 直接在xxxx位置保存数值，范围从0001~1101，减1后结果为实际值 |

ZipList的连锁更新问题

ZipList的每个Entry都包含previous_entry_length来记录上一个节点的大小，长度是1个或5个字节：如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值如果前一节点的长度大于等于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据现在，假设我们有N个连续的、长度为250~253字节之间的entry，因此entry的previous_entry_length属性用1个字节即可表示，如图所示：

ZipList这种特殊情况下产生的连续多次空间扩展操作称之为连锁更新（Cascade Update）。新增、删除都可能导致连锁更新的发生。

小总结：

ZipList特性：

压缩列表的可以看做一种连续内存空间的"双向链表"
列表的节点之间不是通过指针连接，而是记录上一节点和本节点长度来寻址，内存占用较低
如果列表数据过多，导致链表过长，可能影响查询性能
增或删较大数据时有可能发生连续更新问题

QuickList

问题1：ZipList虽然节省内存，但申请内存必须是连续空间，如果内存占用较多，申请内存效率很低。怎么办？

答：为了缓解这个问题，我们必须限制ZipList的长度和entry大小。

问题2：但是我们要存储大量数据，超出了ZipList最佳的上限该怎么办？

答：我们可以创建多个ZipList来分片存储数据。

问题3：数据拆分后比较分散，不方便管理和查找，这多个ZipList如何建立联系？

答：Redis在3.2版本引入了新的数据结构QuickList，它是一个双端链表，只不过链表中的每个节点都是一个ZipList。

为了避免QuickList中的每个ZipList中entry过多，Redis提供了一个配置项：list-max-ziplist-size来限制。如果值为正，则代表ZipList的允许的entry个数的最大值如果值为负，则代表ZipList的最大内存大小，分5种情况：

-1：每个ZipList的内存占用不能超过4kb
-2：每个ZipList的内存占用不能超过8kb
-3：每个ZipList的内存占用不能超过16kb
-4：每个ZipList的内存占用不能超过32kb
-5：每个ZipList的内存占用不能超过64kb

其默认值为 -2：

除了控制ZipList的大小，QuickList还可以对节点的ZipList做压缩。通过配置项list-compress-depth来控制。因为链表一般都是从首尾访问较多，所以首尾是不压缩的。这个参数是控制首尾不压缩的节点个数：

0：特殊值，代表不压缩

1：标示QuickList的首尾各有1个节点不压缩，中间节点压缩

2：标示QuickList的首尾各有2个节点不压缩，中间节点压缩

以此类推

默认值：

以下是QuickList的和QuickListNode的结构源码：

总结：

QuickList的特点：

是一个节点为ZipList的双端链表
节点采用ZipList，解决了传统链表的内存占用问题
控制了ZipList大小，解决连续内存空间申请效率问题
中间节点可以压缩，进一步节省了内存

SkipList

SkipList（跳表）首先是链表，但与传统链表相比有几点差异：

元素按照升序排列存储

节点可能包含多个指针，指针跨度不同。

SkipList的特点：

跳表是一个双向链表，每个节点都包含score和ele值
节点按照score值排序，score值一样则按照ele字典排序
每个节点都可以包含多层指针，层数是1到32之间的随机数
不同层指针到下一个节点的跨度不同，层级越高，跨度越大
增删改查效率与红黑树基本一致，实现却更简单

RedisObject

Redis中的任意数据类型的键和值都会被封装为一个RedisObject，也叫做Redis对象

什么是redisObject：从Redis的使用者的角度来看，⼀个Redis节点包含多个database（非cluster模式下默认是16个，cluster模式下只能是1个），而一个database维护了从key space到object space的映射关系。这个映射关系的key是string类型，⽽value可以是多种数据类型，比如：string, list, hash、set、sorted set等。我们可以看到，key的类型固定是string，而value可能的类型是多个。⽽从Redis内部实现的⾓度来看，database内的这个映射关系是用⼀个dict来维护的。dict的key固定用⼀种数据结构来表达就够了，这就是动态字符串sds。而value则比较复杂，为了在同⼀个dict内能够存储不同类型的value，这就需要⼀个通⽤的数据结构，这个通用的数据结构就是robj，全名是redisObject。

Redis的编码方式

Redis中会根据存储的数据类型不同，选择不同的编码方式，共包含11种不同类型：

|--------|-------------------------|---------------|
| 编号 | 编码方式 | 说明 |
| 0 | OBJ_ENCODING_RAW | raw编码动态字符串 |
| 1 | OBJ_ENCODING_INT | long类型的整数的字符串 |
| 2 | OBJ_ENCODING_HT | hash表（字典dict） |
| 3 | OBJ_ENCODING_ZIPMAP | 已废弃 |
| 4 | OBJ_ENCODING_LINKEDLIST | 双端链表 |
| 5 | OBJ_ENCODING_ZIPLIST | 压缩列表 |
| 6 | OBJ_ENCODING_INTSET | 整数集合 |
| 7 | OBJ_ENCODING_SKIPLIST | 跳表 |
| 8 | OBJ_ENCODING_EMBSTR | embstr的动态字符串 |
| 9 | OBJ_ENCODING_QUICKLIST | 快速列表 |
| 10 | OBJ_ENCODING_STREAM | Stream流 |

五种数据结构

Redis中会根据存储的数据类型不同，选择不同的编码方式。每种数据类型的使用的编码方式如下：

|------------|--------------------------------------------|
| 数据类型 | 编码方式 |
| OBJ_STRING | int、embstr、raw |
| OBJ_LIST | LinkedList和ZipList(3.2以前)、QuickList（3.2以后） |
| OBJ_SET | intset、HT |
| OBJ_ZSET | ZipList、HT、SkipList |
| OBJ_HASH | ZipList、HT |

五种数据类型

String

String是Redis中最常见的数据存储类型：

其基本编码方式是RAW，基于简单动态字符串（SDS）实现，存储上限为512mb。

如果存储的SDS长度小于44字节（分配内存时不会产生内存碎片），则会采用EMBSTR编码，此时object head与SDS是一段连续空间。申请内存时只需要调用一次内存分配函数，效率更高。

如果存储的字符串是整数值，并且大小在LONG_MAX范围内，则会采用INT编码：直接将数据保存在RedisObject的ptr指针位置（刚好8字节），不再需要SDS了。

（1）底层实现⽅式：动态字符串sds 或者 longString的内部存储结构⼀般是sds（Simple Dynamic String，可以动态扩展内存），但是如果⼀个String类型的value的值是数字，那么Redis内部会把它转成long类型来存储，从⽽减少内存的使用。

List

Redis的List类型可以从首、尾操作列表中的元素

哪一个数据结构能满足上述特征？

LinkedList ：普通链表，可以从双端访问，内存占用较高，内存碎片较多
ZipList ：压缩列表，可以从双端访问，内存占用低，存储上限低
QuickList：LinkedList + ZipList，可以从双端访问，内存占用较低，包含多个ZipList，存储上限高

Redis的List结构类似一个双端链表，可以从首、尾操作列表中的元素：

在3.2版本之前，Redis采用ZipList和LinkedList来实现List，当元素数量小于512并且元素大小小于64字节时（这个值可以调整）采用ZipList编码，超过则采用LinkedList编码。

在3.2版本之后，Redis统一采用QuickList来实现List：

Set

Set是Redis中的单列集合，满足下列特点：

不保证有序性
保证元素唯一
求交集、并集、差集

Set对查询元素的效率要求非常高，什么样的数据结构可以满足？

HashTable，也就是Redis中的Dict，不过Dict是双列集合（可以存键、值对）

为了查询效率和唯一性，set采用HT编码（Dict）。Dict中的key用来存储元素，value统一为null。当存储的所有数据都是整数，并且元素数量不超过set-max-intset-entries时，Set会采用IntSet编码，以节省内存

ZSet

ZSet也就是SortedSet，其中每一个元素都需要指定一个score值和member值：

可以根据score值排序后
member必须唯一（后添加的member会覆盖之前的值）
可以根据member查询分数

zset底层数据结构必须满足键值存储、键必须唯一、可排序这几个需求。

SkipList：可以排序，并且可以同时存储score和ele值（member）但是不能保证键的唯一性
HT（Dict）：可以键值存储，并且可以根据key找value但是无法排序

当元素数量不多时，HT和SkipList的优势不明显，而且更耗内存。因此zset还会采用ZipList结构来节省内存，不过需要同时满足两个条件：

元素数量小于zset_max_ziplist_entries，默认值128
每个元素都小于zset_max_ziplist_value字节，默认值64

ziplist本身没有排序功能，而且没有键值对的概念，因此需要有zset通过编码实现：

ZipList是连续内存，因此score和element是紧挨在一起的两个entry， element在前，score在后
score越小越接近队首，score越大越接近队尾，按照score值升序排列

Hash

Hash结构与Redis中的Zset非常类似：

都是键值存储
都需求根据键获取值
键必须唯一

区别如下：

zset的键是member，值是score；hash的键和值都是任意值
zset要根据score排序；hash则无需排序

（1）底层实现方式：压缩列表ziplist 或者字典dict当Hash中数据项比较少的情况下，Hash底层才⽤压缩列表ziplist进⾏存储数据，随着数据的增加，底层的ziplist就可能会转成dict，具体配置如下：

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

当满足上面两个条件其中之⼀的时候，Redis就使⽤dict字典来实现hash。Redis的hash之所以这样设计，是因为当ziplist变得很⼤的时候，它有如下几个缺点：

每次插⼊或修改引发的realloc操作会有更⼤的概率造成内存拷贝，从而降低性能。
⼀旦发生内存拷贝，内存拷贝的成本也相应增加，因为要拷贝更⼤的⼀块数据。
当ziplist数据项过多的时候，在它上⾯查找指定的数据项就会性能变得很低，因为ziplist上的查找需要进行遍历。

总之，ziplist本来就设计为各个数据项挨在⼀起组成连续的内存空间，这种结构并不擅长做修改操作。⼀旦数据发⽣改动，就会引发内存realloc，可能导致内存拷贝。

hash结构如下：

zset集合如下：

因此，Hash底层采用的编码与Zset也基本一致，只需要把排序有关的SkipList去掉即可：

Hash结构默认采用ZipList编码，用以节省内存。 ZipList中相邻的两个entry 分别保存field和value

当数据量较大时，Hash结构会转为HT编码，也就是Dict，触发条件有两个：

ZipList中的元素数量超过了hash-max-ziplist-entries（默认512）
ZipList中的任意entry大小超过了hash-max-ziplist-value（默认64字节）

Redis网络模型

用户空间和内核空间

服务器大多采用Linux系统，以Linux为例，用户的应用，比如redis，mysql等其实是没有办法去执行访问我们操作系统的硬件的，所以我们可以通过发行版的这个壳子去访问内核，再通过内核去访问计算机硬件。

计算机硬件包括，如cpu，内存，网卡等等，内核（通过寻址空间）可以操作硬件的，但是内核需要不同设备的驱动，有了这些驱动之后，内核就可以去对计算机硬件去进行内存管理，文件系统的管理，进程的管理等等

我们想要用户的应用来访问，计算机就必须要通过对外暴露的一些接口，才能访问到，从而简介的实现对内核的操控，但是内核本身上来说也是一个应用，所以他本身也需要一些内存，cpu等设备资源，用户应用本身也在消耗这些资源，如果不加任何限制，用户去操作随意的去操作我们的资源，就有可能导致一些冲突，甚至有可能导致我们的系统出现无法运行的问题，因此我们需要把用户和内核隔离开

进程的寻址空间划分成两部分：内核空间、用户空间

什么是寻址空间呢？我们的应用程序也好，还是内核空间也好，都是没有办法直接去物理内存的，而是通过分配一些虚拟内存映射到物理内存中，我们的内核和应用程序去访问虚拟内存的时候，就需要一个虚拟地址，这个地址是一个无符号的整数，比如一个32位的操作系统，他的地址宽度就是32，他的虚拟地址就是2的32次方，也就是说他寻址的范围就是0~2的32次方，这片寻址空间对应的就是2的32个字节，就是4GB，这个4GB，会有3个GB分给用户空间，会有1GB给内核系统

在linux中，他们权限分成两个等级，0和3，用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口来访问内核空间可以执行特权命令（Ring0），调用一切系统资源，所以一般情况下，用户的操作是运行在用户空间，而内核运行的数据是在内核空间的，而有的情况下，一个应用程序需要去调用一些特权资源，去调用一些内核空间的操作，所以此时他俩需要在用户态和内核态之间进行切换。

比如：

Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区：

写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备

读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区

针对这个操作：我们的用户在写读数据时，会去向内核态申请，想要读取内核的数据，而内核数据要去等待驱动程序从硬件上读取数据，当从磁盘上加载到数据之后，内核会将数据写入到内核的缓冲区中，然后再将数据拷贝到用户态的buffer中，然后再返回给应用程序，整体而言，速度慢，就是这个原因，为了加速，我们希望read也好，还是wait for data也最好都不要等待，或者时间尽量的短。

阻塞IO

在《UNIX网络编程》一书中，总结归纳了5种IO模型：

阻塞IO（Blocking IO）
非阻塞IO（Nonblocking IO）
IO多路复用（IO Multiplexing）
信号驱动IO（Signal Driven IO）
异步IO（Asynchronous IO）

应用程序想要去读取数据，他是无法直接去读取磁盘数据的，他需要先到内核里边去等待内核操作硬件拿到数据，这个过程就是1，是需要等待的，等到内核从磁盘上把数据加载出来之后，再把这个数据写给用户的缓存区，这个过程是2，如果是阻塞IO，那么整个过程中，用户从发起读请求开始，一直到读取到数据，都是一个阻塞状态。

具体流程如下图：

用户去读取数据时，会去先发起recvform一个命令，去尝试从内核上加载数据，如果内核没有数据，那么用户就会等待，此时内核会去从硬件上读取数据，内核读取数据之后，会把数据拷贝到用户态，并且返回ok，整个过程，都是阻塞等待的，这就是阻塞IO

顾名思义，阻塞IO就是两个阶段都必须阻塞等待：

阶段一：

用户进程尝试读取数据（比如网卡数据）
此时数据尚未到达，内核需要等待数据
此时用户进程也处于阻塞状态

阶段二：

数据到达并拷贝到内核缓冲区，代表已就绪
将内核数据拷贝到用户缓冲区
拷贝过程中，用户进程依然阻塞等待
拷贝完成，用户进程解除阻塞，处理数据

可以看到，阻塞IO模型中，用户进程在两个阶段都是阻塞状态。

非阻塞IO

非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。

阶段一：

用户进程尝试读取数据（比如网卡数据）
此时数据尚未到达，内核需要等待数据
返回异常给用户进程
用户进程拿到error后，再次尝试读取
循环往复，直到数据就绪

阶段二：

将内核数据拷贝到用户缓冲区
拷贝过程中，用户进程依然阻塞等待
拷贝完成，用户进程解除阻塞，处理数据
可以看到，非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

IO多路复用

概述

无论是阻塞IO还是非阻塞IO，用户应用在一阶段都需要调用recvfrom来获取数据，差别在于无数据时的处理方案：

如果调用recvfrom时，恰好没有数据，阻塞IO会使CPU阻塞，非阻塞IO使CPU空转，都不能充分发挥CPU的作用。如果调用recvfrom时，恰好有数据，则用户进程可以直接进入第二阶段，读取并处理数据

所以怎么看起来以上两种方式性能都不好

而在单线程情况下，只能依次处理IO事件，如果正在处理的IO事件恰好未就绪（数据不可读或不可写），线程就会被阻塞，所有IO事件都必须等待，性能自然会很差。

要提高效率有几种办法？

方案一：增加更多线程

方案二：不排队，谁数据就绪了，用户应用就去读取数据

用户进程如何知道内核中数据是否就绪呢？

所以接下来就需要详细的来解决多路复用模型是如何知道到底怎么知道内核数据是否就绪的问题了

这个问题的解决依赖于提出的

文件描述符（File Descriptor）：简称FD，是一个从0 开始的无符号整数，用来关联Linux中的一个文件。在Linux中，一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字（Socket）。

通过FD，我们的网络模型可以利用一个线程监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

阶段一：

用户进程调用select，指定要监听的FD集合
核监听FD对应的多个socket
任意一个或多个socket数据就绪则返回readable
此过程中用户进程阻塞

阶段二：

用户进程找到就绪的socket
依次调用recvfrom读取数据
内核将数据拷贝到用户空间
用户进程处理数据

当用户去读取数据的时候，不再去直接调用recvfrom了，而是调用select的函数，select函数会将需要监听的数据交给内核，由内核去检查这些数据是否就绪了，如果说这个数据就绪了，就会通知应用程序数据就绪，然后来读取数据，再从内核中把数据拷贝给用户态，完成数据处理，如果N多个FD一个都没处理完，此时就进行等待。

用IO复用模式，可以确保去读数据的时候，数据是一定存在的，他的效率比原来的阻塞IO和非阻塞IO性能都要高

IO多路复用是利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。不过监听FD的方式、通知的方式又有多种实现，常见的有：

select
poll
epoll

其中select和pool相当于是当被监听的数据准备好之后，他会把你监听的FD整个数据都发给你，你需要到整个FD中去找，哪些是处理好了的，需要通过遍历的方式，所以性能也并不是那么好

而epoll，则相当于内核准备好了之后，他会把准备好的数据，直接发给你，咱们就省去了遍历的动作。

select

select是Linux最早是由的I/O多路复用技术：

简单说，就是把需要处理的数据封装成FD，然后在用户态时创建一个fd的集合（这个集合的大小是要监听的那个FD的最大值+1，但是大小整体是有限制的），这个集合的长度大小是有限制的，同时在这个集合中，标明出来我们要控制哪些数据，

比如要监听的数据，是1,2,5三个数据，此时会执行select函数，然后将整个fd发给内核态，内核态会去遍历用户态传递过来的数据，如果发现这里边的数据都没有就绪，就休眠，直到有数据准备好时，就会被唤醒，唤醒之后，再次遍历一遍，看看哪个事件准备好了，然后再将处理掉没有准备好的数据，最后再将这个FD集合写回到用户态中去，此时用户态就知道有事件准备好了，但是对于用户态而言，并不知道谁处理好了，所以用户态也需要去进行遍历，然后找到对应准备好数据的节点，再去发起读请求，我们会发现，这种模式下他虽然比阻塞IO和非阻塞IO好，但是依然有些麻烦的事情，比如说频繁的传递fd集合，频繁的去遍历FD等问题

select模式存在的问题：

需要将整个fd_set从用户空间拷贝到内核空间，select结束还要再次拷贝回用户空间

select无法得知具体是哪个fd就绪，需要遍历整个fd_set

fd_set监听的fd数量不能超过1024

Poll

poll模式对select模式做了简单改进，但性能提升不明显，部分关键代码如下：

IO流程：

创建pollfd数组，向其中添加关注的fd信息，数组大小自定义
调用poll函数，将pollfd数组拷贝到内核空间，转链表存储，无上限
内核遍历fd，判断是否就绪
数据就绪或超时后，拷贝pollfd数组到用户空间，返回就绪fd数量n
用户进程判断n是否大于0,大于0则遍历pollfd数组，找到就绪的fd

与select对比：

select模式中的fd_set大小固定为1024，而pollfd在内核中采用链表，理论上无上限
监听FD越多，每次遍历消耗时间也越久，性能反而会下降

Epoll

epoll模式是对select和poll的改进，它提供了三个函数：

第一个是：eventpoll的函数，他内部包含两个东西

一个是：

1、红黑树-> 记录的事要监听的FD

2、一个是链表->一个链表，记录的是就绪的FD

首先使用epoll_create创建epoll，紧接着调用epoll_ctl操作，将要监听的数据添加到红黑树上去，并且给每个fd设置一个监听函数，这个函数会在fd数据就绪时触发，就是准备好了，现在就把fd把数据添加到list_head中去

3、调用epoll_wait函数

就绪等待，在用户态创建一个空的events数组，当就绪之后，我们的回调函数会把数据添加到list_head中去，当调用这个函数的时候，会去检查list_head，当然这个过程需要参考配置的等待时间，可以等一定时间，也可以一直等，如果在此过程中，检查到了list_head中有数据会将数据添加到链表中，此时将数据放入到events数组中，并且返回对应的操作的数量，用户态此时收到响应后，从events中拿到对应准备好的数据的节点，再去调用方法去拿数据。

select模式存在的三个问题：

能监听的FD最大不超过1024
每次select都需要把所有要监听的FD都拷贝到内核空间
每次都要遍历所有FD来判断就绪状态

poll模式的问题：

poll利用链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如果监听较多，性能会下降

epoll模式中如何解决这些问题的？

基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高
每个FD只需要执行一次epoll_ctl添加到红黑树，以后每次epol_wait无需传递任何参数，无需重复拷贝FD到内核空间
利用epoll_callback机制来监听FD状态，无需遍历所有FD，因此性能不会随监听的FD数量增多而下降

epoll事件通知机制

当FD有数据可读时，我们调用epoll_wait（或者select、poll）可以得到通知。但是事件通知的模式有两种：

LevelTriggered：简称LT，也叫做水平触发。只要某个FD中有数据可读，每次调用epoll_wait都会得到通知。
EdgeTriggered：简称ET，也叫做边沿触发。只有在某个FD有状态变化时，调用epoll_wait才会被通知。

ET模式避免了LT模式可能出现的惊群现象

ET模式最好结合非阻塞IO读取FD数据，相比LT会复杂一些

基于epoll的服务器端流程

服务器启动以后，服务端会去调用epoll_create，创建一个epoll实例，epoll实例中包含两个数据

1、红黑树（为空）：rb_root 用来去记录需要被监听的FD

2、链表（为空）：list_head，用来存放已经就绪的FD

创建好了之后，会去调用epoll_ctl函数，此函数会会将需要监听的数据添加到rb_root中去，并且对当前这些存在于红黑树的节点设置回调函数，当这些被监听的数据一旦准备完成，就会被调用，而调用的结果就是将红黑树的fd添加到list_head中去(但是此时并没有完成)

3、当第二步完成后，就会调用epoll_wait函数，这个函数会去校验是否有数据准备完毕（因为数据一旦准备就绪，就会被回调函数添加到list_head中），在等待了一段时间后(可以进行配置)，如果等够了超时时间，则返回没有数据，如果有，则进一步判断当前是什么事件，如果是建立连接时间，则调用accept() 接受客户端socket，拿到建立连接的socket，然后建立起来连接，如果是其他事件，则把数据进行写出

信号驱动IO

信号驱动IO是与内核建立SIGIO的信号关联并设置回调，当内核有FD就绪时，会发出SIGIO信号通知用户，期间用户应用可以执行其它业务，无需阻塞等待。

阶段一：

用户进程调用sigaction，注册信号处理函数
内核返回成功，开始监听FD
用户进程不阻塞等待，可以执行其它业务（与非阻塞IO不同的是不需要忙等待）
当内核数据就绪后，回调用户进程的SIGIO处理函数

阶段二：

收到SIGIO回调信号
调用recvfrom，读取
内核将数据拷贝到用户空间
用户进程处理数据

当有大量IO操作时，信号较多，SIGIO处理函数不能及时处理可能导致信号队列溢出，而且内核空间与用户空间的频繁信号交互性能也较低。

异步IO

这种方式，不仅仅是用户态在试图读取数据后，不阻塞，而且当内核的数据准备完成后，也不会阻塞

他会由内核将所有数据处理完成后，由内核将数据写入到用户态中，然后才算完成，所以性能极高，不会有任何阻塞，全部都由内核完成，可以看到，异步IO模型中，用户进程在两个阶段都是非阻塞状态。

在高并发的情况下，异步IO会对内核产生较大的压力，可能导致系统崩溃。如果使用异步IO就需要对并发做限流，避免对内核资源的过度请求导致系统的崩溃。

对比

最后用一幅图，来说明他们之间的区别

Redis网络模型

Redis是单线程的吗？为什么使用单线程

Redis到底是单线程还是多线程？

如果仅仅聊Redis的核心业务部分（命令处理），答案是单线程
如果是聊整个Redis，那么答案就是多线程

在Redis版本迭代过程中，在两个重要的时间节点上引入了多线程的支持：

Redis v4.0：引入多线程异步处理一些耗时较久的任务，例如异步删除命令unlink
Redis v6.0：在核心网络模型中引入多线程，进一步提高对于多核CPU的利用率

因此，对于Redis的核心网络模型，在Redis 6.0之前确实都是单线程。是利用epoll（Linux系统）这样的IO多路复用技术在事件循环中不断处理客户端情况。

为什么Redis要选择单线程？

抛开持久化不谈，Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，因此多线程并不会带来巨大的性能提升。
多线程会导致过多的上下文切换，带来不必要的开销
引入多线程会面临线程安全问题，必然要引入线程锁这样的安全手段，实现复杂度增高，而且性能也会大打折扣

Redis单线程和多线程网络模型变更

当我们的客户端想要去连接我们服务器，会去先到IO多路复用模型去进行排队，会有一个连接应答处理器，他会去接受读请求，然后又把读请求注册到具体模型中去，此时这些建立起来的连接，如果是客户端请求处理器去进行执行命令时，他会去把数据读取出来，然后把数据放入到client中， clinet去解析当前的命令转化为redis认识的命令，接下来就开始处理这些命令，从redis中的command中找到这些命令，然后就真正的去操作对应的数据了，当数据操作完成后，会去找到命令回复处理器，再由他将数据写出。