Redis事务
1.Redis事务本质：一组命令的集合，加入队列，然后执行，执行完事务结束。
redis事务：
①开启事务：multi
②命令入队：set key1 v1 set key2 v2 .。。get...
③执行事务：exec
取消事务：discard，所有事务中入队的命令都不会执行
注意：如果在②时候命令错误，exec所有的命令都不会被执行，如果是命令没错运行出错的话，其他命令可以执行。
watch用来监控事务：
可以用来做乐观锁操作，如果exec执行之前，另外一个事务对money进行操作并且执行完了，此时这里再exec的话就会执行失败。
如何解决？
首先放弃watch监视 unwatch，即解锁，再重新watch，如果再失败就再解锁再加锁，有种自旋锁的味道。
jedis 操作事务：
SpringBoot整合Redis
SpringBoot 2.x之后默认不用jedis，替换为lettuce？
jedis：采用直连，多线程操作不安全，如何避免？使用jedis pool
lettuce：采用netty，实例可以多线程共享，不存在线程安全问题，可以减少线程数据。
源码分析：
在导入starter包后会发现底层还是用的lettuce进行操作的，虽然也有jedis的实现，但是并没用
可以用spring自带的RedisTemplate也可以自己定义，自己定义则自带的就会失效：
，这里定义了一个jackson序列化的方法。
redis.conf了解：
bind 127.0.0.1 绑定的ip
protected-mode no 保护模式
port 端口
通用：GENERAL
daemonize yes
pidfile /var/run/redis_6379.pid
# Specify the server verbosity level.
# This can be one of:
# 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个数据库
快照：SNAPSHOTTING
save 900 1 900s内 如果至少有一个key进行修改，则持久化
save 300 10 300s内 至少10个key就行操作，则进行持久化
save 60 10000 。。。同理
stop-writes-on-bgsave-error yes 持久化出错继续工作
rdbcompression yes 是否压缩RDB文件，需要消耗一些cpu资源
rdbchecksum yes 保存RDB文件时，自动检查校验
dir ./ rdb文件保存路径
REPLICATION 主从复制
安全：SECURITY
设置redis密码
MEMORY MANAGEMENT
maxmemory <bytes> redis配置最大的内存容量
maxmemory-policy noeviction 内存达到上限时的处理策略
1、volatile-lru：只对设置了过期时间的key进行LRU（默认值）
2、allkeys-lru ： 删除lru算法的key
3、volatile-random：随机删除即将过期key
4、allkeys-random：随机删除
5、volatile-ttl ： 删除即将过期的
6、noeviction ： 永不过期，返回错误
AOF:APPEND ONLY MODE
appendonly no 默认不开启，默认rdb模式，一般情况下rdb就够用了
appendfilename "appendonly.aof"
# appendfsync always 每次修改都会同步
appendfsync everysec 默认每秒执行一次
# appendfsync no 不同步
RDB持久化
在指定时间间隔内将内存中的数据集体写入磁盘，父进程会fork一个子进程讲内存内同写入rdb文件，主进程是不进行ID操作的。
最后一次持久化的话：如果宕机就会缺失一些数据。
rdb的dump.rdb文件什么时候产生？
save时，redis关闭时，flushall时
AOF 追加
将我们所有命令记录下来，除了读操作，redis重新执行命令，会很慢，默认不开启。
如果开启了aof，aof文件有错误则是启动不了redis的，此时可以用redis目录下的redis-check-aof可以进行修复，命令：redis-check-aof --fix appendonly.aof
Redis发布订阅
Redis发布订阅（pub/sub）是一种消息通信模式。
发布者+频道
测试：
原理：通过SUBSCRIBE命令订阅某频道后，redis-server里维护了一个字典，字典就是一个个频道，字典的值是一个链表，链表中保存了所有订阅这个channel的客户端，SUBSCRIBE命令的关键就是将客户端添加到给定的channel中的订阅链表中。
通过PUBLISH命令向订阅者发送消息，redis-server会使用给定的频道作为键，在它所维护的channel中查找记录了订阅这个频道的所有客户端链表，遍历这个链表，将消息发送给所有订阅者。
Redis集群
正常最少需要一主二从。
环境配置：只配从库，不用配置主库。
通过info replication查看主从信息，
复制3个redis.conf，并修改
①端口
②pid名字
③log文件名
④dump.rdb名字
修改完毕之后 通过 redis-server set/redis6379.conf 启动各个redis。
如何配置从机？
比如有6379/6380/6381三个服务
在6380中执行slaveof 127.0.0.1 6379 意思就是找6379这个作为自己的老大，这个是通过命令配置的，是暂时的，其实应该在redis.conf文件中配置（replicaof <masterip> <masterport>）。
主机写从机读取。
如果主机断了，可以通过slaveof no one 让自己变成主机，如果此时与哪来的老大又回来了，那也没用了。
哨兵模式
与上述手动切换主从的繁琐流程，redis使用sentinel哨兵模式来智能化选举老大。
如何开启？
在bin目录下有一个redis-sentinel，如我们上面说的最少三个进程来完成主从，那么哨兵也需要最少三个。
①.在redis.conf同级目录下新建哨兵的配置sentinel.conf，多个就配置多个
sentinel monitor myredis 127.0.0.1 6379 1 myredis是被监控的名称，1代表主机挂了，slave投票让谁接替主机
②.启动哨兵
redis-sentinel
Redis缓存穿透和雪崩
①.穿透（查不到）如何解决：BloomFilter或者在缓存中加一个空对象，不让查询进入数据库查询
缓存击穿（量太大）：指的是一个key非常热点，不停的高并发集中一个点访问;
如何解决？设置永不过期/加互斥锁
②.缓存雪崩：某个时间段缓存集中过期失效；
如何解决？多搭建几台redis异地多活/限流降级/数据预热（先访问一边加载到缓存中）
