Redis tutorial
本文最后更新于:2024年8月9日 晚上
Redis 是高性能 NoSQL 内存 key-value 数据库,支持数据的持久化、备份、事物、发布/订阅、通知、key 过期等特性。
键的类型只能为字符串,值支持五种数据类型:字符串、列表、集合、散列表、有序集合。
1 数据类型
Redis支持五种数据类型:
- String
最基本类型,类似Memcached,二进制安全。一个键最大存储512MB - Hash
string类型的映射表,特别适合存储对象。每个 hash 可以存储 2^32-1 键值对。 - List
string类型的列表,按照插入顺序排序。最多可存2^32-1元素。 - Set
string类型的无序集合,通过哈希表实现,成员元素唯一。最大的成员数为 2^32-1。 - zset
string类型的有序集合,成员元素唯一。每个元素关联一个double类型的分数。通过分数排序。
2 数据结构
2.1 字典
1)dictht
dictht 是一个散列表结构,使用拉链法解决哈希冲突。
1 |
|
2)dictEntry
1 |
|
3)dict
Redis 的字典 dict 中包含两个哈希表 dictht,这是为了方便进行 rehash 操作。在扩容时,将其中一个 dictht 上的键值对 rehash 到另一个 dictht 上面,完成之后释放空间并交换两个 dictht 的角色。
1 |
|
4)rehash
rehash 操作不是一次性完成,而是采用渐进方式,这是为了避免一次性执行过多的 rehash 操作给服务器带来过大的负担。
渐进式 rehash 通过记录 dict 的 rehashidx 完成,它从 0 开始,然后每执行一次 rehash 都会递增。例如在一次 rehash 中,要把 dict[0] rehash 到 dict[1],这一次会把 dict[0] 上 table[rehashidx] 的键值对 rehash 到 dict[1] 上,dict[0] 的 table[rehashidx] 指向 null,并令 rehashidx++。
在 rehash 期间,每次对字典执行添加、删除、查找或者更新操作时,都会执行一次渐进式 rehash。
采用渐进式 rehash 会导致字典中的数据分散在两个 dictht 上,因此对字典的查找操作也需要到对应的 dictht 去执行。
1 |
|
2.2 跳跃表
是有序集合的底层实现之一。
跳跃表是基于多指针有序链表实现的,可以看成多个有序链表。
在查找时,从上层指针开始查找,找到对应的区间之后再到下一层去查找。下图演示了查找 22 的过程。
与红黑树等平衡树相比,跳跃表具有以下优点:
- 插入速度非常快速,因为不需要进行旋转等操作来维护平衡性;
- 更容易实现;
- 支持无锁操作。
3 使用场景
3.1 计数器
可以对 String 进行自增自减运算,从而实现计数器功能。
Redis 这种内存型数据库的读写性能非常高,很适合存储频繁读写的计数量。
3.2 缓存
将热点数据放到内存中,设置内存的最大使用量以及淘汰策略来保证缓存的命中率。
3.3 查找表
例如 DNS 记录就很适合使用 Redis 进行存储。
查找表和缓存类似,也是利用了 Redis 快速的查找特性。但是查找表的内容不能失效,而缓存的内容可以失效,因为缓存不作为可靠的数据来源。
3.4 消息队列
List 是一个双向链表,可以通过 lpush 和 rpop 写入和读取消息
不过最好使用 Kafka、RabbitMQ 等消息中间件。
3.5 会话缓存
可以使用 Redis 来统一存储多台应用服务器的会话信息。
当应用服务器不再存储用户的会话信息,也就不再具有状态,一个用户可以请求任意一个应用服务器,从而更容易实现高可用性以及可伸缩性。
3.6 分布式锁实现
在分布式场景下,无法使用单机环境下的锁来对多个节点上的进程进行同步。
可以使用 Redis 自带的 SETNX 命令实现分布式锁,除此之外,还可以使用官方提供的 RedLock 分布式锁实现。
3.7 其它
Set 可以实现交集、并集等操作,从而实现共同好友等功能。
ZSet 可以实现有序性操作,从而实现排行榜等功能。
4 Redis 命令
- redis-cli:启动客户端
-r:重复执行
-i : 每隔几秒执行一次
-x : 读取标准输入
-c:连接redis集群时使用
-a:加入redis密码
–slave:把客户端模拟成所连接redis节点的从节点,获得数据库更新信息
–latency:测试客户端到redis服务器的网络延迟
–stat:实时监控redis信息
–raw:返回格式化后的结果
–no-raw:返回原始格式 - redis-cli -h host -p port -a password:连接远程 redis 服务
- slowlog get:慢查询
- info memory:内存信息
5 数据淘汰策略
可以设置内存最大使用量,当内存使用量超出时,会施行数据淘汰策略。
Redis 具体有 6 种淘汰策略:
策略 | 描述 |
---|---|
volatile-lru | 从已设置过期时间的数据集中挑选最近最少使用的数据淘汰 |
volatile-ttl | 从已设置过期时间的数据集中挑选将要过期的数据淘汰 |
volatile-random | 从已设置过期时间的数据集中任意选择数据淘汰 |
allkeys-lru | 从所有数据集中挑选最近最少使用的数据淘汰 |
allkeys-random | 从所有数据集中任意选择数据进行淘汰 |
noeviction | 禁止驱逐数据 |
作为内存数据库,出于对性能和内存消耗的考虑,Redis 的淘汰算法实际实现上并非针对所有 key,而是抽样一小部分并且从中选出被淘汰的 key。
使用 Redis 缓存数据时,为了提高缓存命中率,需要保证缓存数据都是热点数据。可以将内存最大使用量设置为热点数据占用的内存量,然后启用 allkeys-lru 淘汰策略,将最近最少使用的数据淘汰。
Redis 4.0 引入了 volatile-lfu 和 allkeys-lfu 淘汰策略,LFU 策略通过统计访问频率,将访问频率最少的键值对淘汰。
6 持久化
Redis 是内存型数据库,为了保证数据在断电后不会丢失,需要将内存中的数据持久化到硬盘上。
1)RDB 持久化
将某个时间点的所有数据都存放到硬盘上。
可以将快照复制到其它服务器从而创建具有相同数据的服务器副本。
如果系统发生故障,将会丢失最后一次创建快照之后的数据。
如果数据量很大,保存快照的时间会很长。
2)AOF 持久化
将写命令添加到 AOF 文件(Append Only File)的末尾。
使用 AOF 持久化需要设置同步选项,从而确保写命令同步到磁盘文件上的时机。这是因为对文件进行写入并不会马上将内容同步到磁盘上,而是先存储到缓冲区,然后由操作系统决定什么时候同步到磁盘。有以下同步选项:
选项 | 同步频率 |
---|---|
always | 每个写命令都同步 |
everysec | 每秒同步一次 |
no | 让操作系统来决定何时同步 |
- always 选项会严重减低服务器的性能;
- everysec 选项比较合适,可以保证系统崩溃时只会丢失一秒左右的数据,并且 Redis 每秒执行一次同步对服务器性能几乎没有任何影响;
- no 选项并不能给服务器性能带来多大的提升,而且也会增加系统崩溃时数据丢失的数量。
随着服务器写请求的增多,AOF 文件会越来越大。Redis 提供了一种将 AOF 重写的特性,能够去除 AOF 文件中的冗余写命令。
7 Redis 事务
Redis 事务不遵循 ACID,中间出错,后面继续执行
- multi:开启事务
- exec:提交事务
- discard:回滚事务
- watch:监听事务(乐观锁)
一个事务包含了多个命令,服务器在执行事务期间,不会改去执行其它客户端的命令请求。
事务中的多个命令被一次性发送给服务器,而不是一条一条发送,这种方式被称为流水线,它可以减少客户端与服务器之间的网络通信次数从而提升性能。
Redis 最简单的事务实现方式是使用 MULTI 和 EXEC 命令将事务操作包围起来。
8 事件
Redis 服务器是一个事件驱动程序。
8.1 文件事件
服务器通过套接字与客户端或者其它服务器进行通信,文件事件就是对套接字操作的抽象。
Redis 基于 Reactor 模式开发了自己的网络事件处理器,使用 I/O 多路复用程序来同时监听多个套接字,并将到达的事件传送给文件事件分派器,分派器会根据套接字产生的事件类型调用相应的事件处理器。
8.2 时间事件
服务器有一些操作需要在给定的时间点执行,时间事件是对这类定时操作的抽象。
时间事件又分为:
- 定时事件:是让一段程序在指定的时间之内执行一次;
- 周期性事件:是让一段程序每隔指定时间就执行一次。
Redis 将所有时间事件都放在一个无序链表中,通过遍历整个链表查找出已到达的时间事件,并调用相应的事件处理器。
8.3 事件的调度与执行
服务器需要不断监听文件事件的套接字才能得到待处理的文件事件,但是不能一直监听,否则时间事件无法在规定的时间内执行,因此监听时间应该根据距离现在最近的时间事件来决定。
事件调度与执行由 aeProcessEvents 函数负责,伪代码如下:
1 |
|
将 aeProcessEvents 函数置于一个循环里面,加上初始化和清理函数,就构成了 Redis 服务器的主函数,伪代码如下:
1 |
|
从事件处理的角度来看,服务器运行流程如下:
9 Redis 备份与恢复
- 备份:
SAVE 命令:在安装目录创建dump.rdb文件。
BGSAVE命令:后台执行SAVE 。
AOF:保存命令,文件名appendonly.aof。需redis.conf中开启配置 - 恢复:将备份文件移到安装目录并启动服务
10 Redis 主从分离
- 将 redis.conf 拷贝多份,并且创建多个目录,每个目录中都有自己的redis.conf 配置文件
- 配置启动Maste
修改端口、pidfile(启动redis 时linux 分配的pid 进程号) - 配置启动Slave
修改端口号和pid 文件,配置文件中配置从服务“slaveof 127.0.0.1 6380”或“masterauth ” - 设置读写分离
在主服务器中设置“slave-read-only yes”
11 Redis 哨兵
Sentinel 系统可以监视任意多个主服务器,以其从服务器,在被监视的主服务器下线时,自动将下线主服务器的某个从服务器升级为新的主服务器。
- 配置Sentinel
在sentinel.conf 配置文件中port属性设置sentinel 的端口 - 启动Sentinel
/sentinel$ redis-sentinel sentinel.conf
12 Redis Cluster
redis3.0开始提供了redis的分布式集群模式,redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value,保存时将 key 大致均等地哈希映射到不同的节点
- 集群中redis节点彼此互联,客户端连接集群中任一可用节点即可
- 集群中超过半数的节点检测失效时,节点fail
13 分片
分片是将数据划分为多个部分的方法,可以将数据存储到多台机器里面,这种方法在解决某些问题时可以获得线性级别的性能提升。
假设有 4 个 Redis 实例 R0,R1,R2,R3,还有很多表示用户的键 user:1,user:2,… ,有不同的方式来选择一个指定的键存储在哪个实例中。
- 最简单的方式是范围分片,例如用户 id 从 0
1000 的存储到实例 R0 中,用户 id 从 10012000 的存储到实例 R1 中,等等。但是这样需要维护一张映射范围表,维护操作代价很高。 - 还有一种方式是哈希分片,使用 CRC32 哈希函数将键转换为一个数字,再对实例数量求模就能知道应该存储的实例。
根据执行分片的位置,可以分为三种分片方式:
- 客户端分片:客户端使用一致性哈希等算法决定键应当分布到哪个节点。
- 代理分片:将客户端请求发送到代理上,由代理转发请求到正确的节点上。
- 服务器分片:Redis Cluster。
14 Redis 与 Memcached 的区别
1)数据类型
- Memcached 仅支持字符串类型
- Redis 支持五种不同的数据类型
2)数据持久化
- Memcached 不支持持久化。
- Redis 支持两种持久化策略:RDB 快照和 AOF 日志
3)分布式
- Memcached 不支持分布式,只能通过在客户端使用一致性哈希来实现分布式存储,这种方式在存储和查询时都需要先在客户端计算一次数据所在的节点。
- Redis Cluster 实现了分布式的支持。
4)内存管理机制
- Memcached 使用预分配的内存池,存在空间浪费
- Memcached 将内存分割成特定长度的块来存储数据,以完全解决内存碎片的问题。但是这种方式会使得内存的利用率不高,例如块的大小为 128 bytes,只存储 100 bytes 的数据,那么剩下的 28 bytes 就浪费掉了。
- Redis 使用现场申请内存的方式,存在内存碎片
- 在 Redis 中,并不是所有数据都一直存储在内存中,可以将一些很久没用的 value 交换到磁盘,而 Memcached 的数据则会一直在内存中。
5)事务
- Memcached 提供了 cas 命令
- Redis 没有,只提供了事务
6)线程
- Memcached 是多线程,非阻塞 IO 复用的网络模型
- Redis 使用单线程的 IO 复用模型