这次彻底读透 Redis ！( 三 ) _小知识

文章插图

上面我用 watch 命令监听了 k1 和 k2，然后开启事务，在事务提交之前，k1 的值被修改了，watch 监听到 k1 值被修改，所以事务没有被提交。
Redis 脚本和事务
从定义上来说，Redis 中的脚本本身就是一种事务，所以任何在事务里可以完成的事，在脚本里面也能完成。并且一般来说，使用脚本要来得更简单，并且速度更快。
因为脚本功能是 Redis 2.6 才引入的，而事务功能则更早之前就存在了，所以 Redis 才会同时存在两种处理事务的方法。
Reids 持久化为什么需要持久化
我们知道 Redis 是内存数据库，主打高性能，速度快。相比 Redis 而言，MySQL 的数据则是保存再硬盘中（其实也有内存版的 MySQL 数据库，但是价格极其昂贵，一般公司不会使用），速度慢，但是稳定性好。你想想 Redis 数据保存在内存中，一旦服务器宕机了，数据岂不是全部都没了，这将会出现很大问题。所以 Redis 为了弥补这一缺陷，提供数据持久化机制，即使服务器宕机，依然可以保证数据不丢失。
持久化简介
Redis 提供了两种持久化机制 RDB 和 AOF，适用于不同场景

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大

RDB
RDB 持久化是通过在指定时间间隔对数据进行快照，比如在 8 点钟对数据进行持久化，那么 Redis 会 fork 一个子进程将 8 点那一刻内存中的数据持久化到磁盘上。触发 RDB 持久化有以下几种方法
RDB 持久化方式
1、执行 save 命令
执行 save 命令进行持久会阻塞 Redis，备份期间 Redis 无法对外提供服务，一般不建议使用，使用场景为 Redis 服务器需要停机维护的情况下。
2、执行 bgsave 命令
bgsave 命令不会阻塞 Redis 主进程，持久化期间 Redis 依然可以正常对外提供服务
3、通过配置文件中配置的 save 规则来触发

文章插图

save 900 1：900s 内有 1 个 key 发生变化，则触发 RDB 快照
save 300 10：300s 内有 10 个 key 发生变化，则触发 RDB 快照
save 60 10000：60s 内有 10000 个 key 发生变化（新增、修改、删除），则触发 RDB 快照
save ""：该配置表示关闭 RDB 持久化
RDB 持久化原理
Redis 进行 RDB 时，会 fork 一个子进程来进行数据持久化，这样不妨碍 Redis 继续对外提供服务，提高效率。
曾经面试官出过这样面试题：
假如 Redis 在 8 点触发了 RDB 持久化，持久化用时 2 分钟，在持久化期间，Redis 中有 100 个 key 被修改了，那么 RDB 文件中的 key 是 8 点那一刻的数据，还是变化的呢？
先不要看答案，自己思考 1 分钟，一个问题只有你自己思考了，才能印象深刻。
好，下面我们一起来看下这张图：

文章插图

从图中我们可以清晰的看到，Redis 备份时，fork 了一个子进程，子进程去做持久化的工作，子进程中的 key 指向了 8 点那一刻的数据，后面 k1 的值修改了，redis 会在内存中创建一个新的值，然后主进程 k1 指针指向新的值，子进程 k1 指针依然指向 19，这样 Redis 持久化的就是 8 点那一刻的数据，不会发生变化。同时，从图中我们也可以看到，Redis 持久化时并不是将内存中数据全部拷贝一份进行备份。
RDB 优缺点
优点