目录
一、事务
Redis事务本质：一组命令的集合！一个事务中的所有的命令都会被序列化，在事务执行过程中，会按照顺序执行。一次性，顺序性，排他性，执行一些列的命令
Redis事务没有隔离级别的概念
所有的命令在事务中，并没有直接被执行，只要发起执行命令的时候才会执行！exec
Redis单条命令是保存原子性的，但是事务不保证原子性
1.Redis的事务
- 开启事务（multi ）
- 命令入队（ .... ）
- 执行事务（ exec）
正常执行事务！
127.0.0.1:6379> multi #开启事务
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2 #命令入队
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> set k3 k3
QUEUED
127.0.0.1:6379> exec #执行事务
1) OK
2) OK
3) "v2"
4) OK
放弃事务
127.0.0.1:6379> multi #开启事务
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> discard #取消事务
OK
127.0.0.1:6379> get k4 # 事务队列中命令都不会被执行
(nil)
127.0.0.1:6379> exec
(error) ERR EXEC without MULTI
编译型异常（代码有问题，命令错误），事务中所有的命令都不会被执行
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> getset k3 #错误的命令
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> set k5 v5
QUEUED
127.0.0.1:6379> exec #执行事务报错
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k5 #所有的命令都不会执行
(nil)
运行时异常（1除以0），如果事务队列中存在语法性，那么执行命令的时候，其他的命令是正常执行的，错误命令抛出异常
127.0.0.1:6379> set k1 "v1"
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr k1 #会执行的时候失败
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> get k3
QUEUED
127.0.0.1:6379> exec
1) (error) ERR value is not an integer or out of range #虽然第一天报错，但是依旧正常执行成功
2) OK
3) OK
4) "v3"
2. 监控watch
悲观锁
- 很悲观，认为什么时候都会出问题，无论做什么都会加锁
乐观锁
- 很乐观，认为什么时候都不会出问题，所以不会上锁。更新数据的时候去判断一下，在此期间是否有人修改过这个数据。（在mysql中，获取version，更新的时候比较version）
redis监视测试
#正常执行成功
127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out 0
OK
127.0.0.1:6379> watch money #监视money对象
OK
127.0.0.1:6379> multi #事务正常结束，数据期间没有发生变动，这个时候就正常执行成功
OK
127.0.0.1:6379> decrby money 20
QUEUED
127.0.0.1:6379> incrby out 20
QUEUED
127.0.0.1:6379> exec
1) (integer) 80
2) (integer) 20
测试多线程修改值，使用watch可以当做redis的乐观锁操作
127.0.0.1:6379> watch money #监视money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 10
QUEUED
127.0.0.1:6379> incrby out 10
QUEUED
127.0.0.1:6379> exec #执行之前，另外一个线程，修改了我们的值，这时，就会导致事务执行失败
（nil）
如果修改失败，获取最新的值就好（先unwatch解锁，再watch加锁）
二、Redis.conf详解
pwd：/usr/local/redis/conf/redis.conf
1.配置文件unit单位对大小写不敏感
2.包含
3.网络
bind 127.0.0.1 #绑定的ip
protected-mode yes # 保护模式
port 6379 # 端口设置
4.通用general
daemonize yes # 以守护进程的方式运行，默认是no，我们需要自己开启yes
pidfile /var/run/redis_6379.pid # 如果以后台的方式运行，我们就需要指定一个pid文件
#日志
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably) 生产环境使用
# warning (only very important / critical messages are logged)
loglevel notice
logfile "" #日志的文件位置名，为空是标准的输出
databases 16 #数据库的数量，默认是 16 个数据库
always-show-logo yes #是否总是显示LOGO
5.快照
持久化，在规定的时间内，执行了多少次操作，则会持久化到文件。rdb。aof
redis是内存数据库，没有持久化，那么数据断电即失
save 900 1 # 如果900s内，如果至少有一个1 key进行了修改，我们即进行持久化操作
save 300 10 # 如果300s内，如果至少有一个10 key进行了修改，我们即进行持久化操作
save 60 10000 # 如果60s内，如果至少有一个10000 key进行了修改，我们即进行持久化操作
stop-writes-on-bgsave-error yes #持久化如果出错，是否还需要继续工作
rdbchecksum yes #是否压缩rdb文件，需要消耗一些cpu资源
rdbchecksum yes #保存rdb文件的时候，进行错误的检查校验
dir ./ #rdb 文件保存的目录
6.SECURITY安全
requirepass 123 #在 配置文件设置密码，默认是没有密码
127.0.0.1:6379> config set requirepass "123" # 命令行设置密码
OK
127.0.0.1:6379> auth 123 # 用密码登录
ok
127.0.0.1:6379> config get requirepass # 获取redis的密码
1) "requirepass"
2) "123"
7.限制clients
maxclients 10000 #设置能连接上redis的最大客户端的数量
maxmemory <bytes> #redis配置最大的内存容量
maxmemory-policy noeviction # 内存到达上限之后的处理策略
maxmemory-policy 六种方式
1、volatile-lru：只对设置了过期时间的key进行LRU（默认值）
2、allkeys-lru ： 删除lru算法的key
3、volatile-random：随机删除即将过期key
4、allkeys-random：随机删除
5、volatile-ttl ： 删除即将过期的
6、noeviction ： 永不过期，返回错误
8.append only 模式 aof配置
append only no # 默认是不开启aof模式，默认使用rdb持久化，大部分情况下，rdb完全够用
appendfilename "appendonly.aof" #持久化的 问价的名字
# appendfsync always #每次写入都会sync，消耗性能
appendfsync everysec # 每秒执行一次sync，可能会丢失这1s的数据
# appendfsync no #不执行sync，这个是时候操作系统自己同步数据，速度最快
三、数据持久化
1.Redis数据安全问题
Redis 是一个缓存中间件，它的最大特点是使用内存从而使其性能强悍。但是使用内存的方 式有一个致命的特点就是数据没办法持久化保存。然而 Redis 持久化存储有两种持久化方案，RDB(Redis DataBase) 和 AOF(Append-Only File)。其中 RDB 是将内存中的数据进行快照存储到磁盘，AOF 则为可回放的命令日志记录 redis 内的所有操作。它们各有特点也相互独立。Redis4 之后支持 RDB-AOF 混合持久化的方式，结合了两者的优 点，可以通过 aof-use-rdb-preamble 配置项可以打开混合开关。
2.快照持久化（RDB）
RDB是将Redis内存中的数据进行snaptshot快照存储在磁盘内存，是Redis的默认持久化方案。使用RDB持久化默认有三种策略，该持久化策略在redis.conf中可配置，会以一段时间内有指定此数据修改的规则触发快照的动作，快照文件名为dump.rdb，该文件默认使用LZF压缩算法。每当Redis服务重启的时候会从该文件中加载数据进内存。
RDB持久化除了可以根据配置文件的策略触发，也可以手动触发,使用save和bgsave命令即可。这两个命令的区别是save会阻塞服务器的进程，在进行save的过程中，服务器不能处理任何请求，而bgsave会通过一个子进程在后台处理rdb持久化。事实上save和bgsave调用的都是sdbsave函数，因此Redis不允许save和bgsave同时运行，这也是为了避免出现竞争导致rdb文件数据不准确。
bgsave操作使用copyonwrite机制进行写时复制，是有一个子进程将内存中的最新数据遍历写入临时文件，此时父进程仍旧处理客户端的操作，当子进程操作完毕后再将该临时文件重命名为dump.rdb替换掉原来的dump.rdb文件，因此无论bgsave是否成功，dump.rdb都不会受到影响。
# 另外在主从全量同步、debug reload以及shutdown的情况下也会触发RDB数据持久化。
[root@redis01 ~]# egrep '^save' /usr/local/redis/conf/redis.conf
save 900 1
save 300 10
save 60 10000
save原理
bgsave原理
3、快照持久化配置设置
#1.创建持久化文件存储目录
[root@docker ~]# mkdir /usr/local/redis/data
#2.修改持久化文件存储目录
[root@tomcat redis]# vim /usr/local/redis/conf/redis.conf
dir /usr/local/redis/data
#3.开启数据持久化（RDB触发机制）
[root@docker ~]# vim /usr/local/redis/conf/redis.conf #默认是开启的
save 900 1 #900秒内至少有1个key被改变则做一次快照
save 300 10 #300秒内至少有10key被改变做一次快照
save 60 10000 #60秒内至少有10000个key被改变则做一次快照
#4.Redis服务在data目录下会生成备份数据文件（dump.rdb）
[root@docker redis]# systemctl start redis
[root@docker redis]# ll
总用量 0
drwxr-xr-x 2 root root 134 4月 30 20:35 bin
drwxr-xr-x 2 root root 24 5月 1 10:36 conf
drwxr-xr-x 2 root root 22 5月 1 10:37 data
[root@docker redis]# cd data/
[root@docker data]# ll
总用量 4
-rw-r--r-- 1 root root 92 5月 1 10:37 dump.rdb
1),配置文件详解
# 1、配置文件详解
save m n
# 2、配置快照(rdb)促发规则，格式：save <seconds> <changes>
save 900 1 900 秒内至少有 1 个 key 被改变则做一次快照
save 300 10 300 秒内至少有 10个 key 被改变则做一次快照
save 60 10000 60 秒内至少有 10000 个 key 被改变则做一次快照
# 3、关闭该规则使用 svae “”
[root@redis01 redis]# egrep 'dump.rdb' /usr/local/redis/conf/redis.conf
# 4、rdb 持久化存储数据库文件名，默认为 dump.rdb
dbfilename dump.rdb
# 5、yes 代表当使用 bgsave 命令持久化出错时候停止写 RDB 快照文件,no 表明忽略错误继续写文件。
stop-write-on-bgsave-error yes
# 6、在写入文件和读取文件时是否开启 rdb 文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。
rdbchecksum yes
# 7、数据文件存放目录，rdb 快照文件和 aof 文件都会存放至该目录，请确保有写权限
dir "/etc/redis"
# 8、是否开启 RDB 文件压缩，该功能可以节约磁盘空间、
rdbcompression yes
4、RDB的优缺点
# 优点：
* RDB是一种表示某个即时点的Redis数据的紧凑文件。RDB文件适合用于备份。例如，你可能想要每小时归档最近24小时的RDB文件，每天保存近30天的RDB快照。这允许你很容易的回复不同版本的数据集以容灾。
* RDB非常适合灾难回复，作为一个紧凑的单一文件，可以被传输到远程的数据中心。
* RDB最大化了Redis的性能，因为Redis父进程持久化是唯一需要做的启动一个子进程，又子进程完成所有剩余工作。父进程实例不需要执行像磁盘IO这样的操作。
* RDB在重启保存了大数据集的实例时比AOF要快
（适合大规模的数据恢复 ； 对数据的完整性要求不高）
# 缺点：
* 当你需要在 Redis 停止工作(例如停电)时最小化数据丢失，RDB 可能不太好。你可以配置不同的保存点(save point)来保存 RDB 文件(例如，至少 5 分钟和对数据集 100 次写之后，但是你可以有多个保存点)。然而，你 通常每隔 5 分钟或更久创建一个 RDB 快照，所以一旦 Redis 因为任何原因没有正确关闭而停止工作，你就得 做好最近几分钟数据丢失的准备了。
* RDB 需要经常调用 fork()子进程来持久化到磁盘。如果数据集很大的话，fork()比较耗时，结果就是，当数据 集非常大并且 CPU 性能不够强大的话，Redis 会停止服务客户端几毫秒甚至一秒。AOF 也需要 fork()，但是你 可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。
（需要一定的时间间隔进程操作！如果redis意外宕机，最后一次修改数据就没有了 ；fork进程时，占用一定的内容空间）
# RDB总结：
# 优点：
速度快，适合用作备份，主从复制也是基于RDB持久化功能实现的
# 致命性缺点：
会有数据丢失、导致服务停止几秒
5、停止备份
在配置文件中设置save“” 或在命令行执行config set save “”
6、手动开始备份
# save：会立即生成 dump.rdb，但是会阻塞往 redis 内存中写入数据。
# bgsave：后台异步备份。
如果是使用 flushdb 命令，会把之前的快照更新成当前的空状态，所以执行了 flushdb 后更新的快照是没有数据的
7、save 与 bgsave 对比
8、持久化（AOF）
AOF(Append-Only File)记录 Redis 中每次的写命令，类似 mysql 中的 binlog，服务重启时会重新执行 AOF 中的 命令将数据恢复到内存中，RDB(按策略持久化)持久化方式记录的粒度不如 AOF(记录每条写命令)，因此很多生产 环境都是开启 AOF 持久化。AOF 中记录了操作和数据，在日志文件中追加完成后才会将内存中的数据进行变更。
# AOF 类似于数据库的binnlog日志
AOF 原理
1、客户端的请求写命令会被 append 追加到 AOF 缓冲区内；
2、AOF 缓冲区根据 AOF 持久化策略[always,everysec,no]将操作 sync 同步到磁盘的 AOF 文件中；
3、AOF 文件大小超过重写策略或手动重写时 ，会对 AOF 文件 rewrite 重写，压缩 AOF 文件容量；
4、Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的
9、AOF配置
开启了 AOF 之后，RDB 就默认不使用了。使用下面的配置开启 AOF 以及策略。
(如果使用 AOF，推荐选择 always 方式持久化，否则在高并发场景下，每秒钟会有几万甚至百万条请求，如果使用 everysec 的方式的话，万一服务 器挂了那几万条数据就丢失了)。
[root@redis01 redis]# vim /usr/local/redis/conf/redis.conf
# 1、开启 AOF 持久化
appendonly yes
# 2、AOF 文件名
appendfilename "appendonly.aof"
[root@redis01 data]# ll
total 8
-rw-r--r-- 1 root root 97 Jul 19 21:16 appendonly.aof
-rw-r--r-- 1 root root 92 Jul 19 21:16 dump.rdb
# 3、AOF 文件存储路径 与 RDB 是同一个参数
dir "/opt/app/redis6/data"
# 4、AOF策略，一般都是选择第一种[always:每个命令都记录],[everysec:每秒记录一次],[no:看机器的心情高兴了就记录]
appendfsync always
# appendfsync everysec
# appendfsync no
# 5、AOF文件大小比起上次重写时的大小,增长 100%(配置可以大于 100%)时,触发重写。[假如上次重写后大小为10MB，当 AOF 文件达到 20MB 时也会再次触发重写，以此类推]
auto-aof-rewrite-percentage 100
# 6、AOF文件大小超过 64MB 时,触发重写
auto-aof-rewrite-min-size 64mb
# 7、是否在后台写时同步单写，默认值 no(表示需要同步).这里的后台写，表示后台正在重写文件(包括 bgsave和 bgrewriteaof.bgrewriteaof 网上很多资料都没有涉及到。其实关掉 bgsave 之后，主要的即是 aof 重写文件了).no 表示新的主进程的 set 操作会被阻塞掉，而 yes 表示新的主进程的 set 不会被阻塞，待整个后台写完成之后再将这部分 set 操作同步到 aof 文件中。但这可能会存在数据丢失的风险(机率很小)，如果对性能有要求，可以设置为 yes，仅在后台写时会异步处理命令.
no-appendfsync-on-rewrite no
# 8、指 redis 在恢复时，会忽略最后一条可能存在问题的指令。默认值 yes。即在 aof 写入时，可能存在指令写错的问题(突然断电，写了一半)，这种情况下，yes 会 log 并继续，而 no 会直接恢复失败.
aof-load-truncated
10、AOF持久化策略
# AOF 分别有三种备份策略，
[always:每个命令都记录],
[everysec:每秒记录一次],
[no:看机器的心情高兴了 就记录]，
针对这三种策略给出如下说明。
策略说明
策略抉择
11、AOF重写
AOF 持久化机制记录每个写命令，当服务重启的时候会复现 AOF 文件中的所有命令，会消耗太多的资源且 重启很慢。因此为了避免 AOF 文件中的写命令太多文件太大，Redis 引入了 AOF 的重写机制来压缩 AOF 文件体积。 AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新 AOF 文件的过程。
AOF重写配置
AOF重写触发机制
根据配置，AOF 持久化触发机制如下： 1. aof_current_size > auto-aof-rewrite-min-size 2. (aof_current_size - aof_base_size) / aof_base_size > auto-aof-rewrite-percentage
AOF重写流程
12、RDB和AOF抉择
RDB和AOF比较
RDB 与 AOF 之间的优劣
# 1、RDB优点：
1、压缩后的二进制文件，适用于备份、全量复制及灾难恢复
2、RDB 恢复数据性能优于 AOF 方式
# 2、RDB 的缺点：
1、无法做到实时持久化，每次都要创建子进程，频繁操作成本过高
2、保存后的二进制文件，不同版本直接存在兼容性问题
# 3、AOF 的优点：
1、以文本形式保存，易读
2、记录写操作保证数据不丢失
# 4、AOF 的缺点：
1、存储所有写操作命令，且文件为文本格式保存，未经压缩，文件体积高。
2、恢复数据时重放 AOF 中所有代码，恢复性能弱于 RDB 方式
13、AOF 与 RDB 混合
看了上面的 RDB 和 AOF 的介绍后，我们可以发现，使用 RDB 持久化会有数据丢失的风险，但是恢复速度快， 而使用 AOF 持久化可以保证数据完整性，但恢复数据的时候会很慢。于是从 Redis4 之后新增了混合 AOF 和 RDB 的模式，先使用 RDB 进行快照存储，然后使用 AOF 持久化记录所有的写操作，当重写策略满足或手动触发重写 的时候，将最新的数据存储为新的 RDB 记录。这样的话，重启服务的时候会从 RDB 何 AOF 两部分恢复数据，即 保证了数据完整性，又提高了恢复的性能。
开启混合模式后，每当 bgrewriteaof 命令之后会在 AOF 文件中以 RDB 格式写入当前最新的数据，之后的新 的写操作继续以 AOF 的追加形式追加写命令。当 redis 重启的时候，加载 aof 文件进行恢复数据：先加载 rdb 的 部分再加载剩余的 aof部分
混合配置
修改下面的参数即可开启 AOF，RDB 混合持久化
aof-use-rdb-preamble yes
混合模式的使用
开启混合持久化模式后，重写之后的 aof 文件里和 rdb 一样存储二进制的快照数据，继续往 redis 中进行写 操作，后续操作在 aof 中仍然是以命令的方式追加。因此重写后 aof 文件由两部分组成，一部分是类似 rdb 的二 进制快照，另一部分是追加的命令文本。
# step: 进入 Redis， 写入数据
[root@alvin-test-os redis]# redis-cli --raw
127.0.0.1:6379> set name alvin
OK
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> set add 上海
OK
127.0.0.1:6379> exit
# Step 2: 查看备份文件
[root@alvin-test-os redis]# ll data/
总用量 8
-rw-r--r--. 1 root root 121 11 月 24 15:39 appendonly.aof
-rw-r--r--. 1 root root 116 11 月 24 15:39 dump.rdb
[root@alvin-test-os redis]# cat data/appendonly.aof | grep add
add
[root@alvin-test-os redis]# cat data/appendonly.aof
*2
$6
SELECT
$1
0
# Step 3： 启动备份
[root@alvin-test-os redis]# redis-cli --raw
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
127.0.0.1:6379> exit
# Step 4: 查看配置文件发现 AOF 备份文件变成了二进制文件
[root@alvin-test-os redis]# cat data/appendonly.aof
REDIS0009� redis-ver6.0.9�
�edis-bits�@�ctime��_used-mem��4
aof-preamble���namealvinadd 上海 age���6����&[root@alvin-test-os redis]#
# Step 5： 再次写入文件
[root@alvin-test-os redis]# redis-cli --raw
127.0.0.1:6379> set company 上海老男孩
OK
127.0.0.1:6379> exit
# Step 6：再次查看备份文件发现被分成了两份，一份二进制，一份 AOF 备份
[root@alvin-test-os redis]# cat data/appendonly.aof
REDIS0009� redis-ver6.0.9�
�edis-bits�@�ctime��_used-mem��4
aof-preamble���namealvinadd 上海 age���6����&*2
$6
SELECT
$1
0
*3
$3
set
$7
company
14、redis数据持久化总结
# 1、RDB：将数据通过二进制的方式保存下来，性能比较好 save m n
[root@docker ~]# vim /usr/local/redis/conf/redis.conf #默认是开启的
save 900 1 #900秒内至少有1个key被改变则做一次快照
save 300 10 #300秒内至少有10key被改变做一次快照
save 60 10000 #60秒内至少有10000个key被改变则做一次快照
bgsave ==> dump.rdb
save原理： 写入数据的时候可能会导致客户端阻塞的，同步
bgsave原理： 会有一个子进程，进行数据持久化（额外开销），异步
# RDB总结：
# 优点：
速度快，适合用作备份，主从复制也是基于RDB持久化功能实现的
# 致命性缺点：
会有数据丢失、导致服务停止几秒
# 2、AOF：将命令保存下来，恢复数据慢
类似于mysql binlog日志，重新会恢复到内存中
# AFO优点： 不丢数据 aooendonly yes 开启AOF持久化
# AOF 分别有三种备份策略，
[always:每个命令都记录],不丢数据，但是没错都要执行，IO比较高
[everysec:每秒记录一次],减少IO
[no:看机器的心情高兴了 就记录]，全自动
# 3、混合模式：取两者方式优点集合