Redis持久化和事务

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了Redis持久化和事务，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4414字，纯文字阅读大概需要7分钟。

内容图文

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

如果需要进行大规模数据的恢复。且对于数据恢复的完整性不是非常敏感，那RDB方案要比AOF方案更加的高效，RDB的缺点是最后一次持久化后的数据可能丢失。

fork

fork的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致。但是是一个全新的进程，并作为原进程的子进程。
缺点：复制进程消耗大

Redis的两种持久化方式：

一、RDB（Redis DataBase）

在指定的时间间隔内将内存中的数据集快照写入磁盘。也就是行话讲的Snapshot快照，它回复时是将快照文件直接读到内存里。
在一定条件下，将内存中的数据保存到磁盘上（比如说60秒内10次修改、100秒内10次修改，可以自己配置）。
保存的是dump.rdb文件
优点：适合大规模的数据恢复
对数据完整性和以执行要求不高

缺点：redis意外挂了，最后一次会丢失
fork，占内存

停止rdb备份：redis-cli config set save ""

二、AOF（Append Only File）

以日志的方式记录每个写操作，将redis执行过的所有写操作记录下来，只需追加但不可以改写文件，redis启动之初会读取该文件重新构建数据。换言之，redis重启的话就根据日志文件的内容将写操作从前到后执行一次。以完成数据的恢复工作。

redis默认dump.rdb和appendonly.aof可以同时存在，在同时存在的情况下默认先加载appendonly.aof，若appedonly.aof文件损坏，则redis会启动失败。

appendonly.aof文件损坏时，可以使用redis安装目录下的bin目录下的redis-check-aof修复appendonly.aof文件。命令：redis-check-aof --fix appendonly.aof。

aof配置策略：

Appendfsync：
Always：同步持久化，每次发生数据变更会被立即记录到磁盘。性能差但数据完整性好。
Everysec：出厂默认，异步操作，每秒记录。如果一秒内宕机，会有数据丢失
No：不同步

Rewrite

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

重写原理：

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

触发机制：
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

No-appendfsync-on-rewrite：重写时是否可以运用Appendfsync.用默认no即可，保证数据安全性。

Auto-aof-rewrite-min-size：设置重写的基准值。

Auto-aof-rewrite-percentage：设置重写的基准值

Redis的事务

可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序串行化执行。

一个队列中，一次性、顺序性、排他性的执行一系列命令。

Redis事务命令：
DISCARD：取消事务，放弃执行事务块中的所有命令。
EXEC：执行所有事务块内的命令。
MUTIL：标记一个事务块的开始

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

WATCH key：监视一个（或多个）key，如果在事务执行之前这个key被其他命令锁改动，那么事务将被打断。

Redis对事务部分支持：
除去事务的正常执行和放弃事务之外。还有两种对事务的支持，一种是一个事务出错，同一个事务块中的所有事务全部失败。另一种是一个事务失败，同一个事务块中的其他事务正常执行。这两者之间的区别是，在插入队列的时候报错是第一种情况，在事务执行exec的时候报错是第二种情况。这就有一点类似于java中的编译时错误和运行时错误。第一种情况类似于编译时错误，第二种类似运行时报错。

watch监控：
监控一个或多个key，类似于乐观锁，事务提交时，如果key的值被别的客户端改变，那么整个书屋队列都不会被执行。

通过WATCH命令在事务执行之前监控了多个keys，倘若在WATCH之后有任何key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

Redis事务的三个阶段

• 开启：以MULTI开始一个事务
• 入队：将多个命令入队列到事务中，街道这些命令并不会立即执行，而是放到等待执行的事务队列里面
• 执行：由EXEC命令触发事务。

Redis事务的三特性

• 单独的隔离操作：事务中的所有命令都会序列化、按顺序执行。事务在执行的过程中，不会被其他客户端发送来的命令请求锁打断。
• 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何执行都不会被实际执行，也就不存在“事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题。
• 不保证原子性：redis同一个事务中如果由一条命令执行失败，其后的命令仍然会被执行，没有回滚。

Redis的发布订阅

进程间的一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息。

订阅：SUBSCRIBE c1 c2 c3：订阅c1 c2 c3
消息发布：PUBLISH c2 hellowolrd

这时订阅了c2的客户端就会接收到hellowolrd这条消息。

订阅多个，通配符*：SUBSCRIBE new*，发布消息：PUBLISH new12 hello，这时new*就会接收到消息。

持续更新~~

内容总结

以上是互联网集市为您收集整理的Redis持久化和事务全部内容，希望文章能够帮你解决Redis持久化和事务所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端