标签：aof 事务 持久 redis Redis 命令 执行
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*就会接收到消息。
持续更新~~
标签：aof,事务,持久,redis,Redis,命令,执行 来源： https://www.cnblogs.com/mrjkl/p/13174439.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。