什么？你还不会Redis?超级详细最新Redis教程
文章目录
- NoSQL的特点
- NoSQL的四大分类
- Redis入门
-
- 概述
- Linux安装
- 测试性能
- 基础知识
- 五大数据类型
-
- Redis-Key
- String(字符串)
- List(列表)
- Set(集合)
- Hash(哈希)
- Zset(有序集合)
- 三种特殊数据类型
-
- geospatial地理位置
- Hyperloglog
- Bitmaps
- 事务
- Jedis
-
- 常用的API
- SpringBoot整合
- Redis.conf详解
- Redis持久化
-
- RDB(Redis DataBase)
- AOF(Append Only File)
- Redis发布订阅
- Redis主从复制：
-
- 概念
- 环境配置
- 一主二从
- 哨兵模式
- Redis缓存穿透和雪崩
-
- 缓存穿透（查不到）
- 缓存击穿（查的太多了，量太大，缓存过期）
- 缓存雪崩
NoSQL的特点
解耦！
1、方便扩展（数据之间没有关系，很好扩展）
2、大数据量高性能(Redis 一秒写8万次，读取11万，NoSL的缓存记录级，是一种细粒度的缓存，性能会比较高)
3、数据类型是多样型的！（不需要事先设计数据库！随取随用！）
4、传统RDBMS和NoSQL
传统的RDBMS
- 结构化组织
- SQL
- 数据和关系都存在单独的表中
- 操作 数据定义语言
- 严格的一致性
- 基础的事务
NoSQL
- 不仅仅是数据
- 没有固定的查询语言
- 键值对存储，列存储，文档存储，图形数据库（社交关系）
- 最终一致性
- CAP定理和BASE (异地多活)
- 高性能、高可用、高可扩
NoSQL的四大分类
KV键值对
文档型数据库(bson格式和json一样)：
- MongoDB(一般必须要掌握)
- MongoDB是一个基于分布式文件存储的数据,C++编写，主要用来处理大量文档。
- MongoDB是一个介于关系型数据库和非关系型数据库中间的产品！MongoDB是非关系型数据库中功能最丰富，最像关系型数据库的。
列存储数据库
- HBase
- 分布式文件系统
图关系数据库
- Neo4j
Redis入门
概述
- Redis是什么
Redis（Remote Dictionary Server )，即远程字典服务
是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
-
Redis能干嘛？
1、内存存储、持久化，内存中是断电即失
2、效率高，可以用于高速缓存
3、发布订阅系统
4、地图信息分析
5、计数器、计数器（浏览量)
-
特性
1、多样的数据类型
2、持久化
3、集群
4、事务
Linux安装
1、解压redis
tar -zxvf redis-6.2.1.tar.gz
2、基本环境安装
yum install gcc-c++
make
3、redis的默认安装路径/usr/local/bin
将/opt/redis-6.2.1复制到其他目录里
cp /opt/redis-6.2.1/redis.conf
4、redis默认不是后台启动的，修改配置文件daemonize yes
5、启动Redis服务
redis-server kconfig/redis.conf
6、使用redis-cli进行连接测试
redis-cli -p 6379
7、查看redis的进程是否开启
10、关闭Redis服务
测试性能
hostnamectl set-hostname ccl修改主机名
redis-benchmark是一个压力测试工具！官方自带的
redis-benchmark -h localhost -p 6379 -c 100 -n 100000
基础知识
redis默认有16个数据库
默认使用第0个数据库
可以使用select进行切换
127.0.0.1:6379> select 3 #切换数据库
OK
127.0.0.1:6379[3]> dbsize #查看DB大小
(integer) 0
127.0.0.1:6379[3]> set name ccl
OK
127.0.0.1:6379[3]> dbsize
(integer) 1
127.0.0.1:6379[3]> select 0
OK
127.0.0.1:6379> dbsize
(integer) 5
127.0.0.1:6379> select 4
OK
127.0.0.1:6379[4]> dbsize
(integer) 0
127.0.0.1:6379[4]>
127.0.0.1:6379> keys * #查看所有的Key
1) "mylist"
2) "name"
3) "key:__rand_int__"
4) "counter:__rand_int__"
5) "myhash"
127.0.0.1:6379>
清除当前数据库flushdb
清空所有数据库flushall
127.0.0.1:6379[3]> flushdb
OK
127.0.0.1:6379[3]> keys *
(empty array)
127.0.0.1:6379[3]>
Redis 是单线程的
Redis是很快的，Redis是基于内存操作，CPU不是Redis性能瓶颈，Redis的瓶颈是根据机器的内存和网络带宽，可以使用单线程就使用单线程
Redis为什么单线程还那么快
1、误区1：高性能的服务器一定是多线程的
2、误区2：多线程（CPU上下文会切换）一定比单线程效率高！
核心：redis是将所有的数据全部放在内存中的，所以说使用单线程取操作效率就是最高的，多线程（CPU上下文会切换：耗时的操作），对于内存系统来说，如果没有上下文切换效率就是最高的。多次读写都在一个CPU上的，在内存情况下，这个就是最佳的方案。
五大数据类型
Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。 它支持多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 与范围查询， bitmaps， hyperloglogs 和 地理空间（geospatial） 索引半径查询。 Redis 内置了 复制（replication），LUA脚本（Lua scripting）， LRU驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘持久化（persistence）， 并通过 Redis哨兵（Sentinel）和自动 分区（Cluster）提供高可用性（high availability）。
Redis-Key
127.0.0.1:6379> set name ccl #set key
OK
127.0.0.1:6379> set age 1
OK
127.0.0.1:6379> keys * #查看所有的key
1) "age"
2) "name"
127.0.0.1:6379> exists name #判断当前的key是否存在
(integer) 1
127.0.0.1:6379> move name 1 #移除当前的key
(integer) 1
127.0.0.1:6379> keys *
1) "age"
127.0.0.1:6379> set name ccl
OK
127.0.0.1:6379> clear
127.0.0.1:6379> key *
(error) ERR unknown command `key`, with args beginning with: `*`,
127.0.0.1:6379> keys *
1) "age"
2) "name"
127.0.0.1:6379> EXPIRE name 10 #设置key的过期时间，单位是秒
(integer) 1
127.0.0.1:6379> keys *
1) "age"
2) "name"
127.0.0.1:6379> expire name 10
(integer) 1
127.0.0.1:6379> keys *
1) "age"
2) "name"
127.0.0.1:6379> keys *
1) "age"
2) "name"
127.0.0.1:6379> keys *
1) "age"
127.0.0.1:6379> ttl name #查看当前key的剩余时间
127.0.0.1:6379> type name #查看当前key的类型
string
127.0.0.1:6379> type age
string
String(字符串)
127.0.0.1:6379> set key1 v1 #设置值
OK
127.0.0.1:6379> get key1 #获得值
"v1"
127.0.0.1:6379> keys * #获得所有的key
1) "age"
2) "key1"
3) "name"
127.0.0.1:6379> EXISTS key1 #判断某一个key是否存在
(integer) 1
127.0.0.1:6379> APPEND key1 "hello" #追加字符串，如果当前key 不存在，就相对于setkey
(integer) 7
127.0.0.1:6379> get key1
"v1hello"
127.0.0.1:6379> STRLEN key1 #获取字符串长度
(integer) 7
127.0.0.1:6379> APPEND key1 "ccl"
(integer) 10
127.0.0.1:6379> get key1
"v1helloccl"
#i++
#步长 i+=
set views 0 #初始浏览量为0
incr views #自增1 浏览量变为1
decr view #自减1
INCRBY views 10 #可以设置步长，指定增量！
DECRBY views 5
#字符串范围 range
GETRANGE key1 0 3 #截取字符串[0,3]
GETRANGE key1 0 -1 #获取全部的字符串和get key是一样的
#替换
SETRANGE key2 1 xx #替换指定位置开始的字符串
#setex(set with expire) #设置过期时间
#setnx(set if not exist) #不存在再设置（在分布式锁中会常常使用）
setex key3 30 "hello" #设置key3的值为hello,30秒后过期
setnx mykey "redis" #如果mykey 不存在，创建mykey
setnx mykey "MongoDb" #如果mykey存在，创建失败
mset
mget
mset k1 v1 k2 v2 k3 v3 #同时设置多个值
mget k1 k2 k3 #同时获取多个值
msetnx k1 v1 k4 v4 #msetnx是一个原子性操作，要么一起成功，要么一起失败
#对象
set user: 1 {
name:zhangsan,age:3} #设置一个user:1对象，值为json字符串来保存一个对象！
#这里的key是一个巧妙的设计：user:{id}:{fild}如此设计在Redis中是完全OK的
mset user:1 name zhangsan user:1:age 2
mget user:1:name user:1age
1)"zhangsan"
2)"2"
getset #先get然后再set
getset db redis #如果不存在值，则返回nil
getset db mongodb #如果存在值，获取原来的值，并设置新的值
String类似的使用场景：value除了我们的字符串还可以是我们的数组！
- 计数器
- 统计多单位的数量
- 粉丝数
- 对象缓存存储
List(列表)
基本的数据类型，列表
所有list的命令都是以l开头的 Redis不区分大小写命令
在Redis里面，我们可以用list实现栈、队列、阻塞队列
LPUSH list one #将一个值或者多个值，插入到列表头部（左）
LRANGE list 0 -1 #获取list中的值
LRANGE list right #将一个值或者多个值，插入到列表尾部（右）
LPOP list #移除list的第一个元素
RPOP list #移除list的最后一个元素
Lindex list 1 #通过下标获得list中的某一个值！
Llen list #返回列表的长度
移除指定的值
Lrem list 1 xx #移除list集合中指定格式的value,精确匹配xx
截取
Ltrim mylist 1 2 #通过下标截取指定的长度，这个list已经改变了，截取了只剩下截取的元素
rpoplpush #移除列表的最后一个元素，将他移动到新的列表中！
rpoplpush mylist myotherlist #移除列表的最后一个元素，将他移动到新的列表中！
lrange mylist 0 -1 #查看原来的列表
lrange myotherlist 0 -1 #查看目标列表中确实存在移动的值
lset 将列表中指定下标的值替换为另外一个值，更新操作，但是必须要存在，否则会报错
EXISTS list #判断这个列表是否存在
lset list 0 item #如果不存在列表，去更新就会报错
lset list 0 item #如果存在，更新当前下标的值
linsert #将某个具体的value插入到列表中某个元素的前面或者后面！
LINSERT mylist before "world" "other"
LINSERT mylist after world new
小结
- 他实际上是一个链表，before Node after ,left right 都可以插入值
- 如果key不存在，创建新的链表
- 如果key存在，新增内容
- 如果移除了所有值，空链表，也代表不存在
- 在两边插入或者改动值，效率最高!中间元素，相对来说效率会低一点
消息排队！消息队列（LPUSH RPOP）,栈（LPUSH LPOP）
Set(集合)
set中的值是不能重复的
sadd myset "hello" #set集合中添加元素
SMEMBERS myset #查看指定set的所有值
SISMEMBER myset hello #判断某一个值是不是在set集合中
(integer) 1
SISMEMBER myset world
(integer) 0
scard myset #获取set集合中的元素的个数
(integer) 4
srem myset hello #移除set集合中的指定元素
(integer) 1
#set 无序不重复集合，抽随机
SRANDMEMBER myset #随机抽选出一个元素
SRANDMEMBER myset 2 #随机抽选出(2)指定个数的元素
#随机删除key
spop myset #随机删除一些set集合中的元素
#将一个指定的值，移动到另外一个set集合！
smove myset myset2 "ccl"
数字集合类
-差集 SDIFF
-交集
-并集
SDIFF key1 key2 #差集
SINTER key1 key2 #交集 共同好友可以这样实现
SUNION key1 key2 #并集
Hash(哈希)
Map集合，key-Map集合！本质和String类型没有太大区别，还是一个简单的key-value
hset myhash field1 ccl #set一个具体 key-value
hget myhash field1 #获取一个字段值
hmset myhash field1 hello field2 world #set多个 key-value
hmget myhash field1 field2 #获取多个字段值
hgetall myhash #获取全部的数据
hdel myhash field1 #删除hash指定key字段！对应的value值也就消失了
hlen myhash #获取hash表的字段数量
(integer) 2
HEXISTS myhash field1 #判断hash中指定字段是否存在！
#只获得所有field
#只获得所有value
hkeys myhash #只获得所有field
hvals myhash #只获得所有value
hset myhash field3 5 #指定增量
HINCRBY myhash field3 1
HINCRBY myhash field3 -1
hsetnx myhash field4 hello #如果不存在则可以设置
hsetnx myhash field4 world #如果存在则不能设置
hash变更的数据 user name age, 尤其是用户信息之类的，经常变动的信息！hash更适合于对象的存储，String更加字符串的存储
Zset(有序集合)
在set的基础上，增加了一个值，set k1 v1 zset k1 score1 v1
zadd myset 1one #添加一个值
zadd myset 2 two 3 three #添加多个值
排序实现
zadd salary 2500 xiaohong #添加三个用户
zadd salary 5000 zhangsan
zadd salary 500 kuang
ZRANGEBYSCORE salary -inf +inf #显示全部的用户 从小到大
ZREVRANGE salary 0 -1 #从大到小进行排序
ZRANGEBYSCORE salary -inf +inf withscores #显示全部用户，并且附带成绩
ZRANGEBYSCORE salary -inf 2500 withscores #显示工资小于2500员工的升序排序
zrem salary xiaohong #移除有序集合中的指定元素
zcard salary #获取有序集合中的个数
zcount myset 1 3 #获取指定区间的成员数量
案例思路：set 排序 存储班级成绩表，工资表排序！
普通消息，1 重要消息 2 带权重进行判断
排行榜应用实现，取Top N测试！
三种特殊数据类型
geospatial地理位置
朋友的定位，附近的人，打车距离计算
Redis 的Geo在Redis3.2版本就推出了，这个功能可以推算地理位置的信息，两地之间的距离，方圆几里的人
GEOADD
#geo 添加地理位置
#规则:两极无法直接添加，我们一般会下载城市数据，直接通过java程序一次性导入
#有效的经度从-180°到180°
#有效的纬度从-85.04112878°到85.05112878
#当坐标位置超出上述指定范围时，该命令将会返回一个错误
geo add china: city 116.40 39.90 beijing
GETPOS
获得当前定位:一定是一个坐标值！
GEOPOS chaina:city beijing #获取指定的城市的经度和纬度
GEODIST
两人之间的距离
单位：
- m表示单位为米
- km千米
- mi英里
- ft英尺
GEODIST china:city beijing shanghai km #查看上海到北京的直线距离
GEORADIUS 以给定的经纬度为中心，找出某一半径内的元素
附近的人（获得所有附近的人的地址，定位） 通过半径来查询
所有数据应该都录入china：city,才会让结果更加精确
GEORADIUS china:city 110 30 1000 km #以110，30这个经纬度为中心，寻找方圆1000km内的城市
GEORADIUS china:city 100 30 500 km withdist #显示到中间距离(100 30)的位置
CEORADIUS china:city 110 30 500 km withcoord #显示到中间距离的经纬度
CEORADIUS china:city 110 30 500 km withcoord count 1 #筛选出指定的结果！
GEORADIUSBYMEMBER
#找出位于指定元素周围的其他元素
GEORADIUSBUYMEMBER china:city beijing 1000 km
GEOHASH命令 返回一个或多个位置元素的Geohash表示
该命令将返回11个字符的Geohash字符串
#将二维的精度转换为一维的字符串，如果两个字符串越接近，那么距离越近
geohash china:city beijing chongqing
GEO底层的实现原理其实就是Zset! 我们可以通过使用Zset命令来操作geo
ZRANGE china:city 0 -1 #查看地图中全部的元素
zrem china:city beijing #移除指定元素
Hyperloglog
什么是基数？
A{1,3,5,7,8,7}
B{1,3,5,7,8}
基数(不重复的元素) = 5 可以接受误差
简介
Redis 2.8.9 版本就更新了Hyperloglog数据结构
Redis Hyperloglog 基数统计的算法！
优点：占用的内存是固定的，2^64不同的元素的基数，只需要废12KB内存!如果要从内存角度来比较的话，Hyperloglog首选
网页的UV(一个人访问了一个网站多次，但是还是算作一个人)
传统的方式，set保存用户的id，然后就可以统计set中的元素数量作为判断标准！
这个方式如果保存大量的用户id，就会比较麻烦！我们的目的是为了计数，而不是保存用户id；
0.81%错误率！统计UV任务，可以忽略不计的！
如果允许容错，那么一定可以使用Hyperloglog
测试使用
127.0.0.1:6379> PFadd mykey a b c d e f g h i j #创建第一组元素 mykey
(integer) 1
127.0.0.1:6379> PFCOUNT mykey #统计mykey 元素的基数数量
(integer) 10
127.0.0.1:6379> PFadd mykey2 i j z x c v b n m #创建第二组元素 mykey2
(integer) 1
127.0.0.1:6379> PFCOUNT mykey2
(integer) 9
127.0.0.1:6379> PFMERGE mykey3 mykey mykey2 #合并两组 mykey mykey2 =>mykey3 并集
OK
127.0.0.1:6379> PFCOUNT mykey3 #查看并集的数量
(integer) 15
Bitmaps
位存储
统计用户信息，活跃、不活跃！登陆、未登录！打卡，365天打开！两个状态的，都可以使用Bitmaps
Bitmaps 位图，都是操作二进制来进行记录，就只有0和1两个状态！
测试
使用bitmap来记录 周一到周日的打卡…
setbit sign 0 1 #周一打卡
setbit sign 1 0 #周二未打卡
setbit sign 2 0 #周三未打卡
...
查看某一天是否有打卡
getbit sign 1
(integer) 1
getbit sign 2
(integer) 0
统计操作，统计打卡的天数！
bitcount sign #统计这周打卡记录（查看全勤）
事务
Redis 事务本质：一组命令的集合！一个事务中的所有命令都会被序列化，在事务执行过程中，会按照顺序执行
**一次性、顺序性、排他性！**执行一些列的命令！
---队列 set set set 执行---
Redis事务没有隔离级别的概念
所有的命令在事务中，并没有直接被执行，只有发起执行命令的时候，才会执行！Exec
Redis单条命令是保存原子性的，但是事务不保证原子性
Redis的事务
- 开启事务(multi)
- 命令入队(…)
- 执行事务(exec)
正常执行事务
127.0.0.1:6379> multi #开启事务
OK
#命令入队
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> get k2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> exec #执行事务
1) OK
2) OK
3) "v2"
4) OK
放弃事务
127.0.0.1:6379> multi #开启事务
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k4 v4
QUEUED
127.0.0.1:6379(TX)> DISCARD #取消事务
OK
127.0.0.1:6379> get k4 #事务队列中命令都不会被执行
(nil)
编译型异常(代码有问题！命令有错！)事务中所有的命令都不会被执行！
mult1
set k1 v1
set k2 v2
set k3 v3
getset k3 #错误的命令
set k4 v4
set k5 v5
exec #执行事务报错！
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(TX)> incr k1 #会执行的时候失败！
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> get k3
QUEUED
127.0.0.1:6379(TX)> exec
1) (error) ERR value is not an integer or out of range #虽然第一条命令报错了，但是依旧正常执行成功了。
2) OK
3) OK
4) "v3"
监控！Watch（面试常问！）
悲观锁：
- 很悲观，认为什么时候都会出问题，无论做什么都会加锁
乐观锁：
- 很乐观，认为什么时候都不会出问题，所以不会上锁，更新数据的时候去判断一下，在此期间是否有人修改过这个数据。
- 获取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(TX)> DECRBY money 20
QUEUED
127.0.0.1:6379(TX)> INCRBY out 20
QUEUED
127.0.0.1:6379(TX)> exec
1) (integer) 80
2) (integer) 20
测试多线程修改值，使用watch可以当作redis的乐观锁操作！
watch miney #监视 money
multi
DECRBY money 10
INCRBY out 10
exec #执行之前，另外一个线程，修改了值，这个时候，就会导致事务执行失败
(nil)
如果修改失败，获取最新的值就好
UNWATCH #如果发现事务执行失败，就先解锁
WATCH money #获取最新的值，再次监视，select version
DECRBY money 1
DECRBY out 1
exec #比对监视的值是否发生了变化，如果没有变化，那么可以执行成功，如果变了，就执行失败
Jedis
使用Java来操作Redis
什么是Jedis?
Jedis 是Redis官方推荐的java连接开发工具，使用Java操作Redis中间件！如果要使用java操作redis,那么一定要对jedis十分的熟悉！
1、导入对应的依赖
<dependencies>
<dependency>
<groupId>redis.clientsgroupId>
<artifactId>jedisartifactId>
<version>3.2.0version>
dependency>
<dependency>
<groupId>com.alibabagroupId>
<artifactId>fastjsonartifactId>
<version>1.2.62version>
dependency>
dependencies>
2、编码测试：
- 连接数据库
- 操作命令
- 断开连接
连接成功，输出Pong
常用的API
String
List
Set
Hash
Zset
所有的api命令，就是我们对应的上面学习的指令，一个都没有变化！
事务
Jedis操作事务
public static void main(String[] args) {
Jedis jedis=new Jedis("xx.xx.xxx",6379);
JSONObject jsonObject=new JSONObject();
jsonObject.put("hello","world");
jsonObject.put("name","kuangshen");
jedis.flushDB();
//开启事务
Transaction multi=jedis.multi();
String result=jsonObject.toJSONString();
try {
multi.set("user1",result);
multi.set("user2",result);
int i=1/0; //代码抛出异常事务，执行失败
multi.exec(); //执行事务
}catch (Exception e){
multi.discard();//放弃事务
e.printStackTrace();
} finally {
System.out.println(jedis.get("user1"));
System.out.println(jedis.get("user2"));
jedis.close();//关闭连接
}
}
SpringBoot整合
SpringBoot操作数据：Spring-data jpa jdbc mongodb redis!
SptringData也是和SpringBoot齐名的项目！
说明：在SptringBoot2.x之后，原来使用redis被替换为了lettuce
为什么？
jedis：采用的直连的模式，多个线程操作的话，是不安全的，如果想避免不安全，就要使用jedis pool 连接池！但是会有许多麻烦的问题，类似于BIO
lettuce：采用netty，实例可以在多个线程中进行共享，不存在线程不安全的情况！可以减少线程数量，更像NIO模式
整合测试一下
源码分析：
@Bean
@ConditionalOnMissingBean(name = "redisTemplate")//外面可以自己定义一个redisTemplate来替换这个默认的
public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory)
throws UnknownHostException {
//默认的RedisTemplate 没有过多的设置，redis对象都是需要序列化
//两个泛型都是Object，Object的类型，外面后续使用需要强制转换整合测试
1、导入依赖
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0modelVersion>
<parent>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-parentartifactId>
<version>2.2.5.RELEASEversion>
parent>
<groupId>com.kuanggroupId>
<artifactId>redis-02-springbootartifactId>
<version>1.0-SNAPSHOTversion>
<dependencies>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-data-redisartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-webartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-devtoolsartifactId>
<scope>runtimescope>
<optional>trueoptional>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-configuration-processorartifactId>
<optional>trueoptional>
dependency>
<dependency>
<groupId>org.projectlombokgroupId>
<artifactId>lombokartifactId>
<optional>trueoptional>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-testartifactId>
<scope>testscope>
dependency>
dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-maven-pluginartifactId>
<configuration>
<excludes>
<exclude>
<groupId>org.projectlombokgroupId>
<artifactId>lombokartifactId>
exclude>
excludes>
configuration>
plugin>
plugins>
build>
project>
2、配置连接
#配置Redis
spring.redis.host=47.94.140.241
spring.redis.port=6379
3、测试类
@RunWith(SpringRunner.class)
@SpringBootTest
public class ApplicationTest {
@Autowired
private RedisTemplate redisTemplate;
// @Resource
// RedisTemplate redisTemplate;
@Test
public void contextLoads(){
//redisTemplate 操作不同的数据类型，ops和redis的指令是一样的
//opsForValue 操作字符串 类似String
//opsForList 操作List 类似List
//opsForHash
//.....
redisTemplate.opsForHash();
redisTemplate.opsForValue();
//除了基本的操作，我们常用的方法都可以直接通过redisTemplate操作，比如事务，和基本的CRUD
//获取redis的连接对象
// RedisConnection connection = redisTemplate.getConnectionFactory().getConnection();
// connection.flushAll();
// connection.flushDb();
redisTemplate.opsForValue().set("mykey","ccl");
System.out.println(redisTemplate.opsForValue().get("mykey"));
}
}
序列化配置
默认的序列化方式是JDK序列化，我们可能会使用Json来序列化，所以自己写一个配置类。
// 自己定义了一个 RedisTemplate
@Bean
@SuppressWarnings("all")
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
// 我们为了自己开发方便，一般直接使用 所有的redis操作，其实对于java开发人员来说，十分的简单，更重要的是要去理解redis的思想和每一种数据结构的用处和作用场景！
Redis.conf详解
单位
1、配置文件unit单位，对大小写不敏感！
包含
包含其他的配置文件，可以整合起来
网络
bind 127.0.0.1 #绑定的ip
protecten-mode yes #保护模式
port 6379 #端口设置
通用
daemonize yes #以守护进程的方式运行（后台运行），默认是no，我们需要自己开启为yes
pidfile /var/run/redis_6379.pid #如果以后台的方式运行，我们需要指定一个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 "" #日志的文件位置名
database 16 #数据库的数量，默认是16个数据库
always-show-logo yes #是否总是显示LOGO
快照
持久化，在规定的时间内，执行了多少次操作，就会持久化到文件 .rdb.aof
redis 是内存数据库，如果没有持久化，那么数据断电及失！
#如果900s内，如果至少有 1 个 key进行了修改，我们就进行持久化操作
save 900 1
#如果300s内，如果至少有 10 个 key进行了修改，我们就进行持久化操作
save 300 10
#如果60s内，如果至少有 10000 个 key进行了修改，我们就进行持久化操作
save 60 10000
#学习了持久化，会自己定义这个测试
stop-writes-on-bgsave -error yes #持久化如果出错，是否还继续工作
rdbcompression yes #是否压缩rdb文件，（需要消耗一些cpu资源）
rdbchecksum yes #保存rdb文件的时候，进行错误的检查校验
dir./ #rdb文件保存的目录
REPLICATION 复制
SECURITY
config get requirepass #获取redis的密码
config set requirepass #设置redis的密码
auth xxxxx #使用密码进行登陆
限制CLIENTS
maxclients 10000 #设置能连接redis的最大客户端的数量
maxclients <bytes> #redis 配置最大的内存容量
maxmemory-policy noeviction #内存到达上限之后的处理策略
#（6种淘汰策略，面试可能会被问道）
1、volatile-lru：只对设置了过期时间的key进行LRU（默认值）
2、allkeys-lru ： 删除lru算法的key
3、volatile-random：随机删除即将过期key
4、allkeys-random：随机删除
5、volatile-ttl ： 删除即将过期的
6、noeviction ： 永不过期，返回错误
APPEND ONLY 模式 aof配置
appendonly no #默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下，rdb完全够用！
appendfilename "appendonly.aof" #持久化的文件的名字
#appendfsync always #每次修改都会 sync 。消耗性能
appendfsync everysec #每秒执行异常 sync ，可能会丢失这1s的数据！
#appendfsync no #不执行sync，这个时候操作系统自己会同步数据，速度最快
Redis持久化
面试和工作，持久化都是重点
Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化功能！
RDB(Redis DataBase)
什么是RDB
在主从复制中，rdb就是备用的，从机上面！
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程是不进行IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB,一般情况下不需要修改这个配置！
生成环境，我们一般会对这个文件进行备份
rdb保存的文件是dump.rdb
触发机制
1、save的规则满足的情况下，会自动触发rdb规则
2、执行flushall命令，也会触发rdbguiz
3、退出redis，也会产生rdb文件
备份就自动生成一个dump.rdb
如何恢复rdb文件
1、只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候，会自动检测dump.rdb 恢复其中的数据！
2、查看需要存储的位置
config get dir
1) "dir"
2) "/usr/local/bin" #如果在这个目录下存在dump.rdb文件，启动就会自动恢复其中的数据
几乎就它自己默认的配置就够用了，但是我们还是需要去学习
优点：
1、适合大规模的数据恢复！
2、对数据的完整性要求不高！
缺点：
1、需要一定的时间间隔进行操作,如果redis意外宕机了，这个最后一次修改的数据就没有了
2、fork进程的时候，会占用一定的内容空间。
AOF(Append Only File)
将我们的所有命令都记录下来，（history）恢复的时候就把这个文件全部在执行一遍
是什么？
以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件，但不可以改写文件,redis启动之初会读取该文件重新构建数据，换言之，redis重启的话，就根据日志文件的内容将写指令从前到后执行一次完成数据的恢复工作。
Aof保存的是appendonly.aof文件
append
默认是不开启的，需要手动设置成yes,只需要将appendonly改为yes就开启了aof！
重启，redis就可以生效了！
如果这个aof文件有错误，这时，redis是启动不起来的，需要修复这个aof文件
Redis给我们提供了一个工具 redis-check-aof --fix
如果文件正常，重启就可以直接恢复了（数据可能会丢失）
重写规则说明
aof默认就是文件的无限追加，文件会越来越大
#如果aof 文件大于64m。太大了，会fork一个新的进程来将我们的文件进行重写
auto-aof-rewrite-percentage 100
auto-aog-rewrite-min-size 64mb
优点和缺点！
appendonly no #默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下，rdb完全够用！
appendfilename "appendonly.aof" #持久化的文件的名字
#appendfsync always #每次修改都会 sync 。消耗性能
appendfsync everysec #每秒执行异常 sync ，可能会丢失这1s的数据！
#appendfsync no #不执行sync，这个时候操作系统自己会同步数据，速度最快
优点：
1、每一次修改都同步，文件的完整会更加好。
2、每秒同步一次，可能会丢失一秒的数据
3、从不同步，效率最高的！
缺点！
1、相对于数据文件来说，aof远远大于rdb,修复的速度也比rdb慢！
2、Aof运行效率也要比rdb慢，所以redis默认的配置就是rdb持久化！
拓展
1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储
2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据。AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化
4、同时开启两种持久化方式
在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。
5、性能建议
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这条规则。
如果启用 AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
如果不启用 AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。
Redis发布订阅
Redis发布订阅(pub/sub)是一种消息通信模式：发送者(pub) 发送信息，订阅者(sub) 接受信息。（微信、微博、关注系统）
Redis客户端可以订阅任意数量的频道。
第一个角色：消息发送者，第二个角色：频道：第三个消息订阅者！
#订阅端
127.0.0.1:6379> SUBSCRIBE ccl #订阅一个频道 kuangshenshuo
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ccl"
3) (integer) 1
1) "message" #消息
2) "ccl" #那个频道的消息
3) "hello ccl" #消息具体的内容
1) "message" #消息
2) "ccl" #那个频道的消息
3) "you get" #消息具体的内容
#发送端
127.0.0.1:6379> PUBLISH ccl "hello ccl" #发布者发布消息到频道
(integer) 1
127.0.0.1:637> PUBLISH ccl "you get" #发布者发布消息到频道
(integer) 1
原理
Redis是使用C实现的，通过分析Redis源码里的pubsub.c文件，了解发布和订阅机制的底层实现，加深对Redis的理解。
Redis通过PUBLISH、SUBSCRIBE和PSUBSCRIBE等命令实现发布和订阅功能。
送给SUBSCRIBE命令订阅某频道后，redis-server 里维护了一个字典,字典的键就是一个个channel（频道），而字典的值则是一个链表，链表中保存了所有订阅这个channel的客户端。SUBSCRIBE命令的关键，就是将客户端添加到给定的channel的订阅链表中。
通过PUBLISH命令向订阅者发送消息，redis-server会使用给定的频道作为键，在它所维护的channel字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发布给所有订阅者。
Pub/Sub从字面上理解就是发布（Public）与订阅（Subscribe）,在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息，这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天群聊等功能。
使用场景：
1、实时消息系统
2、实时聊天（频道当作聊天室，将信息回显给所有人即可）
3、订阅、关注系统
稍微复杂的场景我们就会使用消息中间件 MQ来实现
Redis主从复制：
概念
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器，前者称为主节点（master/leader），后者称为从节点（slave/follower）;数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。
默认情况下，每台Redis服务器都是主节点，且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。
主从复制的作用主要包括：
1、数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点）分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4、高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的（宕机），原因如下：
1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；
2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G,也不能将所有内存用作Redis存储内存,一般来说，单台Redis最大使用内存不应该超过20G
电商网站上的商品，一般都是一次上次，无数次浏览的，说专业点也就是"多读少写"。
对于这种场景，我们可以使用这种架构：
主从复制，读写分离！80%的情况下都是在进行读操作！减缓服务器的压力！架构中经常使用！一主二从！
只要在公司中，主从复制就是必须要使用的，因为在真实的项目中不可能单机使用Redis
环境配置
只配置从库，不用配置主库
127.0.0.1:6379> info replication #查看当前库的信息
# Replication
role:master #角色 master
connected_slaves:0 #没有从机
master_failover_state:no-failover
master_replid:36196d7ce2ea25b6ea18c5f6ed86f910477be5f5
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
复制3个配置文件，然后修改对应的信息
1、端口
2、pid名字
3、log文件名字
4、dump.rdb名字
修改完毕之后，看到三个Redis服务的进程信息：
ps:这里我服务器遇到了问题，查看进程的信息，提示我没有权限，但我就是使用的root用户，使用top命令也都提示我没有权限，
于是我去阿里云的控制台查看我服务器的状态，发现CPU的利用率几乎一直是百分百的在跑，一个redis的服务怎么可能会占用全
部的cpu资源呢，肯定是服务器被别人黑了，然后用去挖矿了。网上去找了很多解决办法，但好像攻击的人挺厉害的，我权限都没
有了，也没办法去排查那个进程在占用资源，咨询了阿里云的技术人员，他们说也不好进行恢复，只好重置服务器了。
这里提醒一下，如果要远程连接Redis的话，一定要指定ip，设置密码，不要嫌麻烦。不然很大几率被黑。
[root@ccl ~]# ps -ef|grep redis #重置服务器后，查看Redis进程
root 6830 1 0 20:04 ? 00:00:02 redis-server 127.0.0.1:6379
root 6989 1 0 20:13 ? 00:00:00 redis-server 127.0.0.1:6380
root 6998 1 0 20:14 ? 00:00:00 redis-server 127.0.0.1:6381
root 7006 6881 0 20:14 pts/3 00:00:00 grep --color=auto redis
[root@ccl ~]#
一主二从
默认情况下，每台Redis服务器都是主节点：我们一般情况下只用配置从机就好了
一主(79)，二从(81)
#从机
salc
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379 #SLAVEOF host 6379 找谁当自己的老大
OK
127.0.0.1:6380> info replication
# Replication
role:slave #当前角色是从机
master_host:127.0.0.1 #可以看到主机单独信息
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_repl_offset:14
slave_priority:100
slave_read_only:1
connected_slaves:0
master_failover_state:no-failover
master_replid:83940f8a7221d12c66cdc4845ac9d0ee668b95ab
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14
#在主机上查看
info replication
# Replication
role:master
connected_slaves:1 #多了从机的配置
slave0:ip=127.0.0.1,port=6380,state=online,offset=56,lag=0 #多了从机的配置
master_failover_state:no-failover
master_replid:83940f8a7221d12c66cdc4845ac9d0ee668b95ab
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:56
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:56
#两个都配置完，就有两个从机了
真实的主从配置应该在配置文件中配置，这样的话是永久的，我们这里使用的是命令，是暂时的！
细节
主机可以写，从机不能写只能读！从机中的所有信息和数据，都会自动被从机保存！
主机写：
127.0.0.1:6379> set k1 v1
OK
从机只能读取内容，不能写
127.0.0.1:6381> set k3 v3
(error) READONLY You can't write against a read only replica.
测试：
主机断开连接，从机依旧连接到主机的，但是没有写操作了，这个时候，如果主机重新连接，从机依旧可以直接获取到主机写的信息！
如果是使用命令行，来配置的主从，这个时候如果从机重启了。就会变回主机！但是只要变为从机，立马就会从主机中获取值！
复制原理
Slave 启动成功连接到Master 后会发送应该sync同步命令
Master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。
全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步，但是只要是重新连接master，一次完全同步（全量复制）将被自动执行！我们的数据一定可以在从机中看到
链路模型
上一个M链接下一个S！
M-->S(M)-->(S) #此时中间的主机依旧是从节点
这种模型也可以完成主从复制
如果Master断开了，没有老大了，能不能选择一个老大出来， 手动！
谋朝篡位
如果主机断开了连接，我们可以使用SLAVEOF no one 让自己编程主机！其他的节点可以手动连接到最新的这个主节点（但是都需要我们手动操作）这个时候，如果主机恢复了，想重新恢复状态，还需要重新配置
哨兵模式
（自动选举老大的模式）
概述
主从切换技术的方法是：当主服务器宕机后，需要手动把一台服务器切换为主服务器，这就需要人工干预，费时费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel(哨兵) 架构来解决这个问题。
谋朝篡位的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行，其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行多个Redis实例。
这里的哨兵有两个作用：
- 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
- 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让他们切换主机。
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象称为主观下线，当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover(故障转移)操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。
测试！
我们目前的状态是一主二从！
1、配置哨兵配置文件sentinel.conf
#sentinel monitor 被监控的名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1
#后面的这个数字1，代表主机挂了，slave投票看让谁接替成为主机，票数最多的，就会成为主机！
2、启动哨兵
[root@ccl bin]# redis-sentinel kconfig/sentinel.conf
7435:X 25 Mar 2021 21:28:11.244 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7435:X 25 Mar 2021 21:28:11.244 # Redis version=6.2.1, bits=64, commit=00000000, modified=0, pid=7435, just started
7435:X 25 Mar 2021 21:28:11.244 # Configuration loaded
7435:X 25 Mar 2021 21:28:11.245 * monotonic clock: POSIX clock_gettime
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 6.2.1 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in sentinel mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 26379
| `-._ `._ / _.-' | PID: 7435
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
7435:X 25 Mar 2021 21:28:11.245 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
7435:X 25 Mar 2021 21:28:11.247 # Sentinel ID is aabb2044c16beb75ca598840b4ecb3bc694d0e8f
7435:X 25 Mar 2021 21:28:11.247 # +monitor master myredis 127.0.0.1 6379 quorum 1
如果Master节点断开了，这个时候就会从主机中随机选择一个服务器！（这里面有一个投票算法！）
#哨兵日志
#failover 故障转移
7435:X 25 Mar 2021 21:30:55.420 # +elected-leader master myredis 127.0.0.1 6379
7435:X 25 Mar 2021 21:30:55.420 # +failover-state-select-slave master myredis 127.0.0.1 6379
7435:X 25 Mar 2021 21:30:55.503 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
7435:X 25 Mar 2021 21:30:55.503 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
7435:X 25 Mar 2021 21:30:55.574 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
7435:X 25 Mar 2021 21:30:55.677 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
7435:X 25 Mar 2021 21:30:55.677 # +failover-state-reconf-slaves master myredis 127.0.0.1 6379
7435:X 25 Mar 2021 21:30:55.730 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
7435:X 25 Mar 2021 21:30:56.701 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
7435:X 25 Mar 2021 21:30:56.701 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
7435:X 25 Mar 2021 21:30:56.759 # +failover-end master myredis 127.0.0.1 6379
7435:X 25 Mar 2021 21:30:56.759 # +switch-master myredis 127.0.0.1 6379 127.0.0.1 6381
7435:X 25 Mar 2021 21:30:56.759 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6381
7435:X 25 Mar 2021 21:30:56.759 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381
7435:X 25 Mar 2021 21:31:26.807 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381
如果主机此时回来了，只能归并到新主机下，当作从机，这就是哨兵模式的规则！
哨兵模式
优点：
1、哨兵集群，基于主从复制模式，所有的主从配置优点，它全有
2、主从可用切换，故障可用转移，系统的可用性就会更好
3、哨兵模式就是主从模式的升级，手动到自动，更加健壮
缺点：
1、Redis不好在线扩容，集群数量一旦到达上限，在线扩容就十分麻烦！
2、实现哨兵模式的配置其实是很麻烦的，里面有许多选择！
哨兵模式的全部配置！
# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认26379
port 26379
# 哨兵sentinel的工作目录
dir /tmp
# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor
sentinel monitor mymaster 127.0.0.1 6379 1
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds
sentinel down-after-milliseconds mymaster 30000
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，
# 这个数字越小，完成failover所需的时间就越长，
# 但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
# 可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout
sentinel failover-timeout mymaster 180000
# SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，
#这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，
#一个是事件的类型，
#一个是事件的描述。
#如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
#通知脚本
# sentinel notification-script
sentinel notification-script mymaster /var/redis/notify.sh
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
#
# 目前总是“failover”,
# 是“leader”或者“observer”中的一个。
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
#一般运维来配置这些
Redis缓存穿透和雪崩
服务的高可用问题
面试高频，工作常用！
在这里我们不会详细去分析解决方案的底层
Redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面，但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存。
另外的一些典型的问题就是，缓存穿透、缓存雪崩和缓存击穿。目前，业界也都有比较流行的解决方案。
缓存穿透（查不到）
概念
缓存穿透的概念很简单，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询，发现也没有，于是本次查询失败，当用户很多的时候，缓存都没有命中，于是都去请求了持久层数据库。这会给持久层数据库造成很大压力，这时候就相对于出现了缓存穿透。
解决方案
布隆过滤器
布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行检验，不符合则丢弃，从而避免了对底层存储系统的查询压力；
缓存空对象
当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源；
但是这种方法会存在两个问题：
1、如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键。因为这当中可能会有很多空值的键。
2、即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。
缓存击穿（查的太多了，量太大，缓存过期）
概述
这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。
当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导致数据库瞬间压力过大。
解决方案
设置热点数据永不过期
从缓存层面来看，没有设置过期时间，所以不会出现热点key过期后产生的问题
加互斥锁
分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。
缓存雪崩
概念
缓存雪崩，是指在某一个时间段，缓存集中过期失效。或者Redis宕机
产生雪崩的原因之一，比如在写文本的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会达到存储层，存储层的调用量暴增，造成存储层也会挂断的情况。
其实集中过期倒不是非常致命。比较致命的缓存雪崩，是缓存服务器某个节点宕机或断电。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存。这个时候，数据库也可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。
解决方案
redis高可用
这个思想的含义是，既然redis有可能挂断，那我就多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。（异地多活）
限流降级
这个解决方案的思想是，在缓存失败后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对
某个key只允许一个线程查询数据和写缓存，其他线程等待。
数据预热
数据预热的含义就是在正式部署之前，我们先把可能的数据先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。
文章总结来自b站up主——“遇见狂神说” 的教学视频，建议大家学习的时候，自己总结笔记。