AOF是什么
以日志的形式来记录每个写操作(增量保存)，将 Redis 执行过的所有写指令记录下来(比 如 set/del 操作会记录, 读操作 get 不记录
只许追加文件但不可以改写文件
redis 启动之初会读取该文件重新构建数据
redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
aof文件存储位置跟rbd文件存储设置的位置一致
持久化流程
1) 客户端的请求写命令会被 append 追加到 AOF 缓冲区内
2) AOF 缓冲区根据 AOF 持久化策略[always,everysec,no]将操作 sync 同步到磁盘的 AOF 文件 中
3) AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 rewrite 重写，压缩 AOF 文件容 量
4) Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的
开启AOF
在 redis.conf 中配置文件名称，默认为 appendonly.aof
AOF 启动/修复/恢复
正常恢复
跟rdb文件备份恢复一样 都是先拷贝一份文件 在进行恢复
异常恢复
1、如遇到 AOF 文件损坏，通过/usr/local/bin/redis-check-aof --fix appendonly.aof 进行恢复 2、建议先: 备份被写坏的 AOF 文件
3、恢复：重启 redis，然后重新加
同步频率设置
1) appendfsync always 谨慎使用
始终同步，每次 Redis 的写入都会立刻记入日志；性能较差但数据完整性比较好2) appendfsync everysec 默认 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
3) appendfsync no redis 不推荐 不主动进行同步，把同步时机交给操作系统
Rewrite 压缩
1、rewrite 重写介绍
1) AOF 文件越来越大，需要定期对 AOF 文件进行重写达到压缩
2) 旧的 AOF 文件含有无效命令会被忽略，保留最新的数据命令 , 比如 set a a1 ; set a b1 ; set a c1; 保留最后一条指令就可以了
3) 多条写命令可以合并为一个 , 比如 set a c1 b b1 c c1
4) AOF 重写降低了文件占用空间
5) 更小的 AOF 文件可以更快的被 redis 加载
重写触发配置
1) 手动触发 直接调用 bgrewriteaof 命令
2) 自动触发
auto-aof-rewrite-min-size: AOF 文件最小重写大小, 只有当 AOF 文件大小大于该值时候才能 重写, 默认配置 64MB
auto-aof-rewrite-percentage: 当前 AOF 文件大小和最后一次重写后的大小之间的比率等于 或者大于指定的增长百分比，如 100 代表当前 AOF 文件是上次重写的两倍时候才重写
系统载入时或者上次重写完毕时，Redis 会记录此时 AOF 大小，设为 base_size,
如果 Redis 的 AOF 当前大小>= base_size +base_size*100% (默认)且当前 大小>=64mb(默认)的情况下，Redis 会对 AOF 进行重写
AOF 持久化
优势
1、备份机制更稳健，丢失数据概率更低。
2、可读的日志文本，通过操作 AOF 稳健，可以处理误操作
劣势
1、比起 RDB 占用更多的磁盘空间
2、恢复备份速度要慢
3、每次读写都同步的话，有一定的性能压力
RDB 还是 AOF?
官方推荐两个都启用
如果只做缓存：如果你只希望你的数据在服务器运行的时候存在, 你也可以不使用任何 持久化方式
Redis_事务_锁机制
Redis 的事务是什么
1、Redis 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行
2、事务在执行的过程中，不会被其他客户端发送来的命令请求所打断
3、Redis 事务的主要作用就是串联多个命令防止别的命令插队
Redis 事务三特性
单独的隔离操作
1、事务中的所有命令都会序列化、按顺序地执行
2、事务在执行的过程中，不会被其他客户端发送来的命令请求所打断
没有隔离级别的概念
队列中的命令(指令), 在没有提交前都不会实际被执行
不保证原子性
事务执行过程中, 如果有指令执行失败，其它的指令仍然会被执行, 没有回滚
事务相关指令 Multi(开启事务队列)、Exec(执行)、discard(丢弃/放弃此次组队)
1) 从输入 Multi 命令开始，输入的命令都会依次进入命令队列中，但不会执行(类似 Mysql 的 start transaction 开启事务)
2) 输入 Exec 后，Redis 会将之前的命令队列中的命令依次执行(类似 Mysql 的 commit 提 交事务)
3) 组队的过程中可以通过 discard 来放弃组队(类似 Mysql 的 rollback )
悲观锁&乐观锁
锁
https://hlz666.blog.csdn.net/article/details/129978116?fromshare=blogdetail&sharetype=blogdetail&sharerId=129978116&sharerefer=PC&sharesource=weixin_60205306&sharefrom=from_link
1) 悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修 改，所以每次在拿数据的时候都会上锁
2) 这样别人/其它请求想拿这个数据就会 block 直到它拿到锁。
3) 悲观锁是锁设计理念, 传统的关系型数据库里边就用到了很多这种锁机制，比如行锁， 表锁等，读锁，写锁等，都是在做操作之前先上锁.
1) 乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会 修改，所以不会上锁
2) 但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等 机制。
3) 乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis 就是利用这种 check-and-set 机制实现事务的
watch & unwatch
watch
1、基本语法: watch key [key ...]
2、在执行 multi 之前，先执行 watch key1 [key2],可以监视一个(或多个) key ，如果在 事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断.
unwatch
1、基本语法 unwatch
2、取消 watch 命令对所有 key 的监视。
3、如果在执行 watch 命令后，exec 命令或 discard 命令先被执行了的话，那么就不 需要再执行 unwatch 了
