Redis事务&REdis持久化RDB&AOF

➢ Redis的事务定义

• Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、 按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令 请求所打断。

• Redis事务的主要作用就是串联多个命令防止别的命令插队

➢ Multi、Exec、discard

• 从输入 Multi命令开始，输入的命令都会 依次进入命令队列中，但不会执行， 至到输入Exec后，Redis会将之前的命令队列中的命令依次执行。

•组队的过程中可以通过discard来放弃组队。

➢ 事务的错误处理

组队中某个命令出现了报告错误，执行时整个的所有队列会都 会被取消。

➢ 事务的错误处理

如果执行阶段某个命令报出了错误，则只有报错的命令不会被 执行，而其他的命令都会执行，不会回滚。

➢ 为什么要做成事务

➢ 事务冲突的问题

    ➢ 悲观锁

 悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去 拿数据的时候都认为别人会修改，所以每次在拿数据的时候 都会上锁，这样别人想拿这个数据就会block直到它拿到锁。 传统的关系型数据库里边就用到了很多这种锁机制，比如行 锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

➢ 乐观锁

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿 数据的时候都认为别人不会修改，所以不会上锁，但是在更新 的时候会判断一下在此期间别人有没有去更新这个数据，可以 使用版本号等机制。乐观锁适用于多读的应用类型，这样可 以提高吞吐量。Redis就是利用这种check-and-set机制实现事 务的。

➢ WATCH key [key ...] 

• 在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断

➢ unwatch 

• 取消 WATCH 命令对所有 key 的监视。 

• 如果在执行 WATCH 命令之后， EXEC 命令或 DISCARD 命令先被执行 了的话，那么就不需要再执行 UNWATCH 了。

➢ 三特性

➢ 单独的隔离操作 

• 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

➢ 没有隔离级别的概念 

• 队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在“事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题。

➢ 不保证原子性 

• Redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被 执行，没有回滚

➢Redis事务--秒杀案例

解决计数器和人员记录的事务操作

超卖问题

2、利用乐观锁淘汰用户，解决超卖问题。

➢链接池

• 节省每次连接redis服务带来的消耗，把连接好的实例反复利用。
• 通过参数管理连接的行为

➢链接池参数

MaxTotal：控制一个pool可分配多少个jedis实例，通过pool.getResource()来获取；如 果赋值为-1，则表示不限制；如果pool已经分配了MaxTotal个jedis实例，则此时pool的 状态为exhausted。

 maxIdle：控制一个pool最多有多少个状态为idle(空闲)的jedis实例； 

MaxWaitMillis：表示当borrow一个jedis实例时，最大的等待毫秒数，如果超过等待时 间，则直接抛JedisConnectionException； 

testOnBorrow：获得一个jedis实例的时候是否检查连接可用性（ping()）；如果为 true，则得到的jedis实例均是可用的

➢LUA脚本

Lua 是一个小巧的脚本语言，Lua脚本可以很容易的被 C/C++ 代码调用，也可以反过来调用C/C++的函数，Lua并 没有提供强大的库，一个完整的Lua解释器不过200k，所以 Lua不适合作为开发独立应用程序的语言，而是作为嵌入式 脚本语言。

➢LUA脚本在Redis中的优势

将复杂的或者多步的redis操作，写为一个脚本，一次 提交给redis执行，减少反复连接redis的次数。提升性 能。
• LUA脚本是类似redis事务，有一定的原子性，不会被其 他命令插队，可以完成一些redis事务性的操作。

• 但是注意redis的lua脚本功能，只有在2.6以上的版本才 可以使用。

利用lua脚本淘汰用户，解决超卖问题。

redis 2.6版本以后，通过lua脚本解决争抢问 题，实际上是redis 利用其单线程的特性， 用任务队列的方式解决多任务并发问题。

Redis的持久化

• Redis 提供了2个不同形式的持久化方式。 

• RDB （Redis DataBase） 

• AOF （Append Of File）

 RDB

• 在指定的时间间隔内将内存中的数据集快照写入磁盘，也 就是行话讲的Snapshot快照，它恢复时是将快照文件直接 读到内存里。

备份是如何执行的

 Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入 到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换
上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的， 这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据

恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。 RDB的缺点是最后一次持久化后的数据可能丢失。

➢ 关于fork

在Linux程序中，fork()会产生一个和父进程 完全相同的子进程，但子进程在此后多会exec系统
调用，出于效率考虑，Linux中引入了“写时复制技术”，一般情况父进程和子进程会共用同一段物

理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程

➢ rdb的保存的文件

• 在redis.conf中配置文件名称，默认为dump.rdb

• rdb文件的保存路径，也可以修改。默认为Redis启动时命令行 所在的目录下

➢ rdb的保存策略

➢ 手动保存快照

• 命令save: 只管保存，其它不管，全部阻塞 

• save vs bgsave

➢ stop-writes-on-bgsave-error yes

• 当Redis无法写入磁盘的话，直接关掉Redis的写操作

➢ rdbcompression yes

• 进行rdb保存时，将文件压缩

➢ rdbchecksum yes

• 在存储快照后，还可以让Redis使用CRC64算法来进行数 据校验，但是这样做会增加大约10%的性能消耗，如果希 望获取到最大的性能提升，可以关闭此功能

 rdb的备份

• 先通过config get dir 查询rdb文件的目录
• 将*.rdb的文件拷贝到别的地方

➢ rdb的恢复

• 关闭Redis

• 先把备份的文件拷贝到工作目录下

• 启动Redis, 备份数据会直接加载

➢ rdb的优点

• 节省磁盘空间 

• 恢复速度快

 rdb的缺点

虽然Redis在fork时使用了写时拷贝技术,但是如果数据 庞大时还是比较消耗性能

• 在备份周期在一定间隔时间做一次备份，所以如果 Redis意外down掉的话，就会丢失最后一次快照后的所 有修改。

➢Redis持久化

• 以日志的形式来记录每个写操作，将Redis执行过的所 有写指令记录下来(读操作不记录)，只许追加文件但不 可以改写文件，Redis启动之初会读取该文件重新构建 数据，换言之，Redis重启的话就根据日志文件的内容

将写指令从前到后执行一次以完成数据的恢复工作。

• AOF默认不开启，需要手动在配置文件中配置

• 可以在redis.conf中配置文件名称，默认为 appendonly.aof

• AOF文件的保存路径，同RDB的路径一致。

➢ AOF文件故障备份

AOF的备份机制和性能虽然和RDB不同, 但是备份和 恢复的操作同RDB一样，都是拷贝备份文件，需要恢 复时再拷贝到Redis工作目录下，启动系统即加载

• AOF和RDB同时开启，系统默认取AOF的数据

➢ AOF文件故障恢复

• AOF的备份机制和性能虽然和RDB不同, 但是备份和 恢复的操作同RDB一样，都是拷贝备份文件，需要恢 复时再拷贝到Redis工作目录下，启动系统即加载。
• AOF文件的保存路径，同RDB的路径一致。

➢ AOF文件故障备份

Redis的持久化--AOF

• 如遇到AOF文件损坏，可通过 redis-check-aof  --fix  appendonly.aof   进行恢复

➢ AOF同步频率设置

• 始终同步，每次Redis的写入都会立刻记入日志
• 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢 失。

• 把不主动进行同步，把同步时机交给操作系统

➢ Rewrite

• AOF采用文件追加方式，文件会越来越大为避免出现此种情况， 新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis 就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指 令集.可以使用命令bgrewriteaof。

➢ Redis如何实现重写？

• AOF文件持续增长而过大时，会fork出一条新进程来将文件重 写(也是先写临时文件最后再rename)，遍历新进程的内存中 数据，每条记录有一条的Set语句。重写aof文件的操作，并 没有读取旧的aof文件，而是将整个内存中的数据库内容用命 令的方式重写了一个新的aof文件，这点和快照有点类似

➢ 何时重写

• 重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重 写还是有一定的负担的，因此设定Redis要满足一定条件才会进 行重写。

• 系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为 base_size,如果Redis的AOF当前大小>= base_size +base_size*100% (默 认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写

➢ AOF的优点

• 备份机制更稳健，丢失数据概率更低。 

• 可读的日志文本，通过操作AOF稳健，可以处理误操作。

➢ AOF的缺点

比起RDB占用更多的磁盘空间。
• 每次读写都同步的话，有一定的性能压力。
• 恢复备份速度要慢。

• 存在个别Bug，造成恢复不能。

➢ 用哪个好

• 官方推荐两个都启用。
• 如果对数据不敏感，可以选单独用RDB。
• 不建议单独用 AOF，因为可能会出现Bug。
• 如果只是做纯内存缓存，可以都不用。