三.Redis入门指南--Redis特性

一.redis 事务

首先进入Redis

#查看容器
docker ps
#进入redis容器
docker exec -it 容器ID bash
#选择连接的redis ip 和端口 我本地用的16379端口
redis-cli -h 127.0.0.1 -p 16379 
#输入用户名和密码  配置文件中的
auth mima
#查找key
key [key规则]
#删除key
del [key]

1.事务概念

1.1什么是事务

单个redis命令的执行是原子性的，但redis并没有在事务上增加任何维持原子性的机制，所以redis事务的执行并不是原子性的。事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，redis中并没有回滚的机制，也就是说中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

1.2事务命令

一共五个命令：
开启事务：multi
执行事务：exec
取消事务：discard：就像mysql中用begin开启事务、用commit结束事务一样。redis中是用multi开启事务，用exec执行命令。如果在exec之前你不想执行事务了，可以用discard取消当前事务。
监控：watch
取消监控：unwatch
事务的原理：当执行multi命令会开启事务，那么所有的命令会加入到事务队列暂存，不会真正的直接执行，如果遇到exec就会把队列中的命令依次执行-提交事务，即使其中有命令执行失败了，也不会影响其他命令的执行结果-不回滚，但遇到discard就会放弃执行队列中的命令-取消事务。

1.3 实操

mutli #开启事务

看到TX表示开启事务了，可以做后续的操作

set name xuxu
set desription cool
set age 18

之后执行exec

exec #提交事务
get name #返回name的值
get decription #返回描述的值 单词写错 将就了
get age #返回年龄的值

结果如下：

此时我们到redis可视化工具上看，将key value成功插入
执行discard命令

discard #取消事务，开启multi后的所有命令都会被取消
get name #返回空值
get age #返回空值

此时再执行exec就会报错

1.4事务为什么不支持回滚

先来看看redis事务执行异常的情况，再说为什么不支持回滚

1.语法错误带着事务执行异常，导致事务取消

127.0.0.1:16379> set s1 1111 #设置是s1值
OK
127.0.0.1:16379> set s2 2222 #设置s2的值
OK
127.0.0.1:16379> get s1
"1111"
127.0.0.1:16379> get s2
"2222"
127.0.0.1:16379> 
127.0.0.1:16379> multi #开启事务
OK
127.0.0.1:16379(TX)> set s1 11 #设置值
QUEUED
127.0.0.1:16379(TX)> sets s2 22 #设置值 但语法报错
(error) ERR unknown command `sets`, with args beginning with: `s2`, `22`,  
127.0.0.1:16379(TX)> exec #执行事务，但前面语法有错误，所以此事务取消
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:16379> get s1
"1111"
127.0.0.1:16379> get s2 #此时s1和s2的值在事务中未改变
"2222"
127.0.0.1:16379> 

2.运行时错误（redis类型错误）导致事务异常
开启事务,设置s1的值为11,s2的值为22，开启事务，再设置s1的值为1111，但在设置s2时，将其类型作为list存入，此时运行时报错，导致事务提交失败，但此时事务并未回滚，而是跳过错误命令继续执行，此时s1的值改变，s2保留原值。

127.0.0.1:16379> set s1 11
OK
127.0.0.1:16379> set s2 22
OK
127.0.0.1:16379> multi #开启事务
OK
127.0.0.1:16379(TX)> set s1 1111
QUEUED
127.0.0.1:16379(TX)> lpush s2 2222 #类型不一致，s2为字符串，在这儿作为list来操作
QUEUED
127.0.0.1:16379(TX)> exec #提交并执行事务报错
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:16379> get s1 #修改成功
"1111"
127.0.0.1:16379> get s2 #修改失败
"22"
127.0.0.1:16379> 

总结：redis为什么不支持事务回滚？
多数事务失败是由语法错误或者数据类型错误导致的，语法错误在命令入队就进行检测，而类型错误是在执行时检测的，Redis为提升性能而采用这种简单的事务，不同于关系型数据库。

1.5：watch和unwatch命令

1.watch命令
上述的redis操作的事务是不支持回滚的，如果要让其回滚，这就需要watch命令；注：watch在mutli命令之前使用
watch的作用： 监控一个值是否发生变化，如果没有发生变化，他会执行事务队列中的命令，提交事务；如果发生变化，将不会执行事务中的任何命令，同时事务回滚。最后无论是否回滚，Redis都会取消事务前的WATCH命令。

验证： 在事务开始前，使用watch命令监控s1，之后修改s1为111111，mutli开始事务修改s2的值222222，执行EXEC，返回nil，说明事务回滚；再查看s2的值有没有被改变

127.0.0.1:16379> set s1 11111 #设置s1的值
OK
127.0.0.1:16379> set s2 22222 #设置s2的值
OK 
127.0.0.1:16379> get s1
"11111"
127.0.0.1:16379> get s2
"22222"
127.0.0.1:16379> watch s1 #监控s1的值
OK
127.0.0.1:16379> set s1 11111111 #修改s1的值
OK
127.0.0.1:16379> multi #开启事务
OK
127.0.0.1:16379(TX)> set s2 2222222 #修改s2的值
QUEUED
127.0.0.1:16379(TX)> exec #执行事务 发送错误  事务回滚
(nil)
127.0.0.1:16379> get s1  #获取s1的值 发生了改变
"11111111"
127.0.0.1:16379> get s2 #获取s2的值 未改变
"22222"
127.0.0.1:16379> 

2.unwatch命令
unwatch命令是取消监控，在事务开启前对监控的对象取消监控，事务就不会回滚了

验证

127.0.0.1:16379> set a1 1
OK
127.0.0.1:16379> set a2 2
OK
127.0.0.1:16379> watch a1 #监控a1
OK
127.0.0.1:16379> set a1 11 #改变a1的值
OK
127.0.0.1:16379> unwatch #取消监控
OK
127.0.0.1:16379> multi #开启事务
OK
127.0.0.1:16379(TX)> set a1 111
QUEUED
127.0.0.1:16379(TX)> set a2 222
QUEUED
127.0.0.1:16379(TX)> exec #执行事务成功
1) OK
2) OK
127.0.0.1:16379> get a1
"111"
127.0.0.1:16379> get a2 #修改a2的值成功
"222"
127.0.0.1:16379> 

二.Redis的持久化-rdb和aof

Redis是一个键值对数据量服务器，由于Redis是内存服务器，那么有很多内存的特点，例如断电，那么服务器中的数据也将消失不见，那么就需要一种方法将数据从内存中写到磁盘，这一过程称为数据持久化。
Redis持久化有两种方式

1.RDB和AOF

1.1：RDB

rdb持久化机制，是对redis中的数据执行周期性的持久化。
RDB优缺点
1.RDB会生成多个数据文件，每个数据文件都代表了某一时刻中redis的数据，这种多个数据文件的方式，适合做冷备，可以将这种完整的数据文件发送到远程的安全存储上去。
2.RDB对redis对外提供的读写服务，影响非常小，可以让redis 高性能 ，因为redis主进程只需要一个fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
3.相对于AOF持久化机制来说，直接基于RDB数据文件来重启和回复redis进程，更加快速。
4.如果想要在Redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者在更长时间生成一次，这个时候就得接受一点redis进程宕机，那么会丢失最近5分钟的数据。
5.RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，甚至数秒。
怎么开启

save ""
# save 900 1        #至少在900秒的时间段内至少有一次改变存储同步一次
# save xxx
# save 60 10000

1.2：AOF

AOF优缺点
1.AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过后台线程执行fsync操作，最多丢失一秒钟的数据。
2.AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易损坏，即使文件尾部损坏，也容易修复。
3.AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来，在创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换老日志文件出来。
4.AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空所有数据，只要这个时候后台的rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令删了。然后再将AOF文件放进去，就可以通过恢复机制，自动恢复所有数据。
5.对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。
6.AOF开启后，支持的写QPS会比RDB支持的QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fysnc，性能也还是非常高的。（如果实时写入，那么QPS会大降，redis性能会大大降低）
7.AOF 这种较为复杂的基于命令日志 / merge / 回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有 bug。不过 AOF 就是为了避免 rewrite 过程导致的 bug，因此每次 rewrite 并不是基于旧的指令日志进行 merge 的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。
怎么开启

appendonly yes        #yes 开启,no 关闭

# appendfsync always  #每次有新命令时就执行一次fsync 

appendfsync everysec  #每秒 fsync 一次 ,这里我们启用 everysec

# appendfsync no      #从不fsync(交给操作系统来处理,可能很久才执行一次fsync)

1.3：怎么选择持久化方式

1.完全不在乎数据丢失：关闭持久化，保持极佳的性能。
2.对数据丢失不敏感，能接受一段时间的数据丢失：选择RDB.
3.对数据丢失敏感，需要尽可能避免丢失数据：混合持久化。用AOF来保证数据不丢失，作为恢复的第一选择；用RDB来做不同程度的冷备。在AOF文件丢失或损坏不可用的时候，使用RDB来快速恢复数据。

三.Redis的淘汰策略

1.淘汰策略的基本概念

redis过期策略： 定期删除+惰性删除
定期删除： 指的是redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。
注：这里不是每隔100ms就遍历所有设置过期时间的key，而是随机抽取一些key来检查和删除的。
但定期删除可能会导致很多过期的key到了时间并没有被删除掉，这时候就需要惰性删除 。意思就是当你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会返回任何东西。
但如果定期删除漏掉了很多过期key，也没及时查，也就没走惰性删除。这时大量的key堆积在内存里，导致redis的内存耗尽了，此时就需要走：内存淘汰机制。
内存淘汰机制 - - -一共6个
1.noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
2.allkeys-lru：尝试回收最少使用的键，使新添加的数据有空间存放，这个最常用的。
3.volatile-lru：当内存不足以容纳写入新数据时，在设置了过期时间的键空间中，移除最近最少使用的key
4.allkeys-random：当内存不足以容纳新的写入数据时，在键空间中，随机移除某个key。
5.volatile-random：当内存不足时，在设置了过期时间的键空间中，随机移除 某个key。
6.volatile-ttl：当内存不足时，在设置了过期时间的键空间中，有更早过期时间 的key会优先移除。

2.淘汰策略配置

2.1：最大内存配置

修改配置redis.windows.conf，修改maxmemory，放开注释，根据情况设置大小

maxmemory <bytes

2.2配置淘汰策略

修改配置redis.window.conf ，修改maxmemory-policy ，放开注释，按情况修改策略

maxmemory-policy noeviction		#noeviction 为默认的策略，根据情况修改