Redis 是个基于内存的数据库。那服务一旦宕机,内存中数据必将全部丢失。所以丢失数据的恢复对于 Redis 是十分重要的,我们首先想到是可以从数据库中恢复,但是在由 Redis 宕机时(说明相关工作正在运行)且数据量很大情况下,从数据库恢复的话,会为数据库带来巨大的压力,进而导致程序相应缓慢。因此实现数据的持久化,避免从后端数据库中恢复数据,对于Redis 是十分必要的。 ~ 本篇内容包括:Redis 持久化机制(即 RDB、AOF 和 二者的区别)、Redis 事务及相关命令。
Redis 是个基于内存的数据库。那服务一旦宕机,内存中数据必将全部丢失。所以丢失数据的恢复对于 Redis 是十分重要的,我们首先想到是可以从数据库中恢复,但是在由 Redis 宕机时(说明相关工作正在运行)且数据量很大情况下,从数据库恢复的话,会为数据库带来巨大的压力,进而导致程序相应缓慢。因此实现数据的持久化,避免从后端数据库中恢复数据,对于Redis 是十分必要的。
此外,Redis 可以通过创建快照来获得存储在内存里面的数据。创建快照之后,可以对快照进行备份,可以将快照复制到其他服务器从而创建具有相同数据的服务器副本(Redis 主从结构,主要用来提高 Redis 性能),还可以将快照留在原地以便重启服务器的时候使用,其中 Redis 最常用的快照持久化机制分为两种,即 RDB 与 AOF。
RDB 持久化可以手动执行也可以根据配置定期执行,它的作用是将某个时间点上的数据库状态保存到 RDB 文件中,RDB 文件是一个压缩的二进制文件,通过它可以还原某个时刻数据库的状态。由于RDB文件是保存在硬盘上的,所以即使 Redis 崩溃或者退出,只要 RDB 文件存在,就可以用它来恢复还原数据库的状态。
可以通过 SAVE 或者 BGSAVE 来生成 RDB 文件:
AOF 和 RDB 不同,AOF 是通过保存 redis服务器所执行的写命令来记录数据库状态的。
AOF 通过追加、写入、同步三个步骤来实现持久化机制。
- | RDB | AOF |
---|---|---|
启动优先级 | 低 | 高 |
文件大小 | 小 | 大 |
恢复速度 | 快 | 慢 |
数据安全性 | 丢数据 | 根据策略决定 |
Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务机制,事务执行过程将一系列多个命令按照顺序一次性执行,并且在执行期间,事务不会被中断,也不会去执行客户端的其他请求,直到所有命令执行完毕。事务的执行过程如下:
WATCH 的机制本身是一个 CAS 的机制,被监视的 key 会被保存到一个链表中,如果某个 key 被修改,那么 REDIS_DIRTY_CAS 标志将会被打开,这时服务器会拒绝执行事务。
Redis 通过 MULTI、EXEC、DISCARD、WATCH 实现事务功能:
# MULTI 开始事务
> multi
OK
MULTI 命令将 Redis 中的 Redis_multi 选项打开,让客户端从非事务状态变为事务状态
# 命令入队
> set bookName "LiZhengi"
QUEUED
> get bookName
QUEUED
> sadd tag "LiZhengi" "Old Book"
QUEUED
> smembers tag
QUEUED
在 Redsi 进入事务状态后,Redis 命令并不是立即执行的,而是进入一个先进先出的事务队列。其中返回 QUEUED 表示这个命令已经入了事务队列。
# exec 提交事物
> exec
1) OK
2) "LiZhengi"
3) (integer) 2
4) 1) "LiZhengi"
2) "Old Book"
可以看到:当执行 exec 命令时,Redis 根据客户端所保存的事务队列,事务队列中的命令以先进先出的方式执行。当 exec 命令执行完毕时,Redis 会将结果保存到一个回复队列,并将回复队列返回给客户端。客户端从事务状态退出,一个事务执行完毕。
# discard 取消事务
> multi
OK
> set bookName "LiZhengi"
QUEUED
> discard
OK
> get bookName
(nil)
discard 取消一个事务的命令,表示这个事务被取消。客户端从事务状态退出,回到非事务状态,Redis_multi 选项关闭。
# watch 命令
watch 命令在事务开始之前监视任意数量的键:当调用 exce 命令执行事务时,如果任意一个被监视的键已经被其他客户端修改了,那么整个事务不再执行,直接返回失败。
管道技术(Pipeline)是客户端提供的一种批处理技术,用于一次处理多个 Redis 命令,从而提高整个交互的性能。
通常情况下 Redis 是单行执行的,客户端先向服务器发送请求,服务端接收并处理请求后再把结果返回给客户端,这种处理模式在非频繁请求时不会有任何问题。
但如果出现集中大批量的请求时,因为每个请求都要经历先请求再响应的过程,这就会造成网络资源浪费,此时就需要管道技术来把所有的命令整合一次发给服务端,再一次响应给客户端,这样就能大大的提升了 Redis 的响应速度。
管道技术解决了多个命令集中请求时造成网络资源浪费的问题,加快了 Redis 的响应速度,让 Redis 拥有更高的运行速度。但要注意的一点是,管道技术本质上是客户端提供的功能,而非 Redis 服务器端的功能。
Pipeline 与 事务相比: