Redis发布订阅：
Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息
Redis 的 SUBSCRIBE 命令可以让客户端订阅任意数量的频道， 每当有新信息发送到被订阅的频道时， 信息就会被发送给所有订阅指定频道的客户端。
观察者模式没有队列的，区别于发布订阅模式
构件：
- 消息发送者pub
- 频道channel
- 消息订阅者sub或client
当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：
命令，可用来构建即时聊天，实时广播，实时提醒等
测试
打开link2窗口，连接redis，发布消息
127.0.0.1:6379> publish liubitalk "woshiliubi"
(integer) 1 #返回值表示接收这条消息的订阅者数量
发出去的消息不会被持久化，也就是有客户端订阅channel:1后只能接收到后续发布到该频道的消息，之前的就接收不到了。
在link1窗口中订阅频道，发现收到消息
127.0.0.1:6379> subscribe liubitalk
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "liubitalk"
3) (integer) 1
1) "message" #消息类型
2) "liubitalk" #消息来源频道
3) "woshiliubi" #消息内容
执行上面命令客户端会进入订阅状态，处于此状态下客户端不能使用除subscribe、unsubscribe、psubscribe和punsubscribe这四个属于"发布/订阅"之外的命令，否则会报错。
进入订阅状态后客户端可能收到3种类型的回复。每种类型的回复都包含3个值，第一个值是消息的类型，根据消类型的不同，第二个和第三个参数的含义可能不同。
消息类型的取值可能是以下3个:
- subscribe。表示订阅成功的反馈信息。第二个值是订阅成功的频道名称，第三个是当前客户端订阅的频道数量。
- message。表示接收到的消息，第二个值表示产生消息的频道名称，第三个值是消息的内容。
- unsubscribe。表示成功取消订阅某个频道。第二个值是对应的频道名称，第三个值是当前客户端订阅的频道数量，当此值为0时客户端会退出订阅状态，之后就可以执行其他非"发布/订阅"模式的命令了。
原理：
进阶：
1.基于模式pattern的发布订阅和基于频道channel的发布订阅
2.Springboot整合redis的发布订阅：https://blog.csdn.net/llll234/article/details/80966952
Redis三种集群方式：https://segmentfault.com/a/1190000022808576
Redis主从复制
要避免单点故障，即保证高可用，便需要冗余（副本）方式提供集群服务。而Redis 提供了主从库模式，以保证数据副本的一致，主从库之间采用的是读写分离的方式
概念
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点,，master以写为主，slave以读为主，一个主节点可以有0个或者多个从节点，一个从节点只能由一个主节点
主从复制的作用：
- 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
- 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
- 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
- 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础
环境配置（伪集群）
查看当前库信息
127.0.0.1:6379> info replication #查看当前库的信息
# Replication
role:master #角色 为master
connected_slaves:0 #没有从机
master_failover_state:no-failover
master_replid:dfbcd8c5ac53cf6f703dde01e07ca3ad6cdc69b5
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
只配置从库，不用配置主库！
- 首先需要复制多个redis.conf配置文件，并且命名为不同的名字
- 然后在每个配置文件中修改：
端口号（原来的redis配置文件为6379不用改），
pidfile后台运行的pid（原来的redis配置文件为6379.pid不用改）
日志文件（默认为" "，都需要修改成各自的），
rdb文件（默认为dump.rdb，需要修改）
注意密码问题！！！在命令行中操作只能暂时有效，持久化得去修改配置文件！ - 分别启动不同配置文件的redis-server
默认情况下，每台redis服务器都是主节点，一般只需要配置从机即可，这里使用命令行slaveof ip地址 端口号进行配置，效果是暂时的，若使用配置文件配置则是永久的
如：配置一台redis-server 为6379端口redis-server从机
此时，在主机中可查看信息：
主机写：
从机只能读，不能写：
主机突然挂掉：
查看从机情况：从机还是作为slave角色（没有配置哨兵）
当主机恢复时，从机仍然能够读取到主机写入的信息
当使用命令行来配置的主从机时，从机突然挂掉，然后从机重连后，从机将会成为一个主机，但是它拿不到断开期间原主机写进去的数据！此时若将他变为源主机的的从机，仍然可以读取主机写入的数据！！！
master断开了，可以对slave手动的使用slaveof no one命令来使其成为新的master，原来其他的slave也需要手动连接到这个新的master！！！，此时即便原来的master恢复了虽然还是master，但是没有slave了
主从复制原理：
全量复制
当我们启动多个 Redis 实例的时候，它们相互之间就可以通过 replicaof（Redis 5.0 之前使用 slaveof）命令形成主库和从库的关系，之后会按照三个阶段完成数据的第一次同步。
- 全量复制的三个阶段:
第一阶段是主从库间建立连接、协商同步的过程
具体来说，从库给主库发送 psync 命令，表示要进行数据同步，主库根据这个命令的参数来启动复制。psync 命令包含了主库的 runID 和复制进度 offset 两个参数。runID，是每个 Redis 实例启动时都会自动生成的一个随机 ID，用来唯一标记这个实例。当从库和主库第一次复制时，因为不知道主库的 runID，所以将 runID 设为“？”。offset，此时设为 -1，表示第一次复制。主库收到 psync 命令后，会用 FULLRESYNC 响应命令带上两个参数：主库 runID 和主库目前的复制进度 offset，返回给从库。从库收到响应后，会记录下这两个参数。这里有个地方需要注意，FULLRESYNC 响应表示第一次复制采用的全量复制，也就是说，主库会把当前所有的数据都复制给从库。第二阶段，主库将所有数据同步给从库,从库收到数据后，在本地完成数据加载。这个过程依赖于内存快照生成的 RDB 文件
具体来说，主库执行 bgsave 命令，生成 RDB 文件，接着将文件发给从库。从库接收到 RDB 文件后，会先清空当前数据库，然后加载 RDB 文件。这是因为从库在通过 replicaof 命令开始和主库同步前，可能保存了其他数据。为了避免之前数据的影响，从库需要先把当前数据库清空。在主库将数据同步给从库的过程中，主库不会被阻塞，仍然可以正常接收请求。否则，Redis 的服务就被中断了。但是，这些请求中的写操作并没有记录到刚刚生成的 RDB 文件中。为了保证主从库的数据一致性，主库会在内存中用专门的 replication buffer，记录 RDB 文件生成后收到的所有写操作。第三个阶段，主库会把第二阶段执行过程中新收到的写命令，再发送给从库
具体的操作是，当主库完成 RDB 文件发送后，就会把此时 replication buffer 中的修改操作发给从库，从库再重新执行这些操作。这样一来，主从库就实现同步了
增量复制
如果主从库在命令传播时出现了网络闪断，那么，从库就会和主库重新进行一次全量复制，开销非常大。从 Redis 2.8 开始，网络断了之后，主从库会采用增量复制的方式继续同步。
- 增量复制流程：
repl_backlog_buffer：它是为了从库断开之后，如何找到主从差异数据而设计的环形缓冲区，从而避免全量复制带来的性能开销。如果从库断开时间太久，repl_backlog_buffer环形缓冲区被主库的写命令覆盖了，那么从库连上主库后只能乖乖地进行一次全量复制，所以repl_backlog_buffer配置尽量大一些，可以降低主从断开后全量复制的概率。而在repl_backlog_buffer中找主从差异的数据后，如何发给从库呢？这就用到了replication buffer。
replication buffer：Redis和客户端通信也好，和从库通信也好，Redis都需要给分配一个 内存buffer进行数据交互，客户端是一个client，从库也是一个client，我们每个client连上Redis后，Redis都会分配一个client buffer，所有数据交互都是通过这个buffer进行的：Redis先把数据写到这个buffer中，然后再把buffer中的数据发到client socket中再通过网络发送出去，这样就完成了数据交互。所以主从在增量同步时，从库作为一个client，也会分配一个buffer，只不过这个buffer专门用来传播用户的写命令到从库，保证主从数据一致，我们通常把它叫做replication buffer。
一个从库如果和主库断连时间过长，造成它在主库repl_backlog_buffer的slave_repl_offset位置上的数据已经被覆盖掉了，当从库重连主库时进行全量复制。
每个从库会记录自己的slave_repl_offset，每个从库的复制进度也不一定相同。在和主库重连进行恢复时，从库会通过psync命令把自己记录的slave_repl_offset发给主库，主库会根据从库各自的复制进度，来决定这个从库可以进行增量复制，还是全量复制
读写分离中的问题
延迟与不一致问题
由于主从复制的命令传播是异步的，延迟与数据的不一致不可避免。数据过期问题
在单机版Redis中，存在两种删除策略：
-
惰性删除：服务器不会主动删除数据，只有当客户端查询某个数据时，服务器判断该数据是否过期，如果过期则删除。 -
定期删除：服务器执行定时任务删除过期数据，但是考虑到内存和CPU的折中（删除会释放内存，但是频繁的删除操作对CPU不友好），该删除的频率和执行时间都受到了限制。
主从复制场景下，为了主从节点的数据一致性，从节点不会主动删除数据，而是由主节点控制从节点中过期数据的删除。由于主节点的惰性删除和定期删除策略，都不能保证主节点及时对过期数据执行删除操作，因此，当客户端通过Redis从节点读取数据时，很容易读取到已经过期的数据。
Redis 3.2中，从节点在读取数据时，增加了对数据是否过期的判断：如果该数据已过期，则不返回给客户端；将Redis升级到3.2可以解决数据过期问题。
- 提升redis性能的方法
在使用读写分离之前，可以考虑其他方法增加Redis的读负载能力：如尽量优化主节点（减少慢查询、减少持久化等其他情况带来的阻塞等）提高负载能力；使用Redis集群同时提高读负载能力和写负载能力等。如果使用读写分离，可以使用哨兵，使主从节点的故障切换尽可能自动化，并减少对应用程序的侵入。
哨兵模式
哨兵的核心功能是主节点的自动故障转移，不再是主从复制出现故障时的人工手动操作
- 正常运行结构图：
注意：哨兵集群的哨兵之间也会互相监督
- 哨兵功能：
- 监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
- 自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机
- 配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
- 通知（Notification）：哨兵可以将故障转移的结果发送给客户端。
其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。
- 哨兵模式的工作方式：
- 每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的 Master 主服务器，Slave 从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。
- 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）
- 如果一个 Master 主服务器被标记为主观下线（SDOWN），则正在监视这个 Master 主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认 Master 主服务器的确进入了主观下线状态
- 当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认 Master 主服务器进入了主观下线状态（SDOWN）， 则 Master 主服务器会被标记为客观下线（ODOWN）
- 在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有 Master 主服务器、Slave 从服务器发送 INFO 命令。
- 当 Master 主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master 主服务器的所有 Slave 从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
- 若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master 主服务器的客观下线状态就会被移除。若 Master 主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。
如何判断出现故障（主机下线）以及故障转移操作
- 判断主机下线
- 主观下线：任何一个哨兵都是可以监控探测，并作出Redis节点下线的判断；
- 客观下线：有哨兵集群共同决定Redis节点是否下线；
当某个哨兵（如下图中的哨兵2）判断主库“主观下线”后，就会给其他哨兵发送 is-master-down-by-addr 命令。接着，其他哨兵会根据自己和主库的连接情况，做出 Y 或 N 的响应，Y 相当于赞成票，N 相当于反对票。
如果赞成票数（这里是2）是大于等于哨兵配置文件中的 quorum 配置项（比如这里如果是quorum=2）, 则可以判定主库客观下线了！
注意：客观下线 和 是否能够主从切换判断是不一样的！客观下线需要达到quorum值，而成为leader哨兵进行主从切换需要达到num(sentinels)/2+1
- 出现主机下线后需要选出新主库
- 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点
- 选择salve-priority从节点优先级最高（redis.conf）的
- 选择复制偏移量最大，只复制最完整的从节点
- 故障转移具过程
首先需要有一个leader哨兵，即由哪个哨兵节点来执行主从切换，选出leader哨兵使用raft算法：选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举
任何一个想成为 Leader 的哨兵，要满足两个条件：
- 第一，拿到半数以上的赞成票；
- 第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值（满足主机客观下线的要求）。
例子中sentinel3为leader哨兵
转移前：
转移流程：
- 将slave-1脱离原从节点（PS: 5.0 中应该是
replicaof no one)，升级主节点， - 将从节点slave-2指向新的主节点
- 通知客户端主节点已更换
- 将原主节点（oldMaster）变成从节点，指向新的主节点
转移后：
测试：在一主二从的状态下进行操作
- 配置哨兵配置文件：sentinel.conf
# sentinel monitor 被监控的名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1
最后的1表示master挂了，slave投票看让票数多者接替成为新master
- 通过sentinel.conf配置文件启动哨兵
[root@liubi bin]# redis-sentinel sentinel.conf
启动成功：
- 此时如果master宕机，会通过算法随机选择一个服务器成为新的master
- 即便原来的master回来了，也只能成为新master的slave
- 哨兵模式的配置文件
Redis缓存穿透和雪崩
缓存穿透(查不到)
对于缓存和数据库中都没有的数据，而用户不断发起请求。由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。
缓存穿透在流量大时可能造成数据库崩掉
- 解决方案
接口层增加校验，如用户鉴权校验，id做基础校验，id<=0或者id过大的的直接拦截；
从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击
此方法会有两个问题：
- 布隆过滤器。bloomfilter就类似于一个hash set，用于快速判某个元素是否存在于集合中，其典型的应用场景就是快速判断一个key是否存在于某容器，不存在就直接返回。布隆过滤器的关键就在于hash算法和容器大小，
缓存击穿（查太多）
缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。
- 解决方案
1、设置热点数据永远不过期。
2、接口限流与熔断，降级。重要的接口一定要做好限流策略，防止用户恶意刷接口，同时要降级准备，当接口中的某些 服务 不可用时候，进行熔断，失败快速返回机制。
3、加互斥锁
缓存雪崩(太多失效)
指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
- 解决方案
缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
如果缓存数据库是分布式部署，将热点数据均匀分布在不同的缓存数据库中。
设置热点数据永远不过期
缓存污染（访问的少的留在缓存不走）
缓存污染问题说的是缓存中一些只会被访问一次或者几次的的数据，被访问完后，再也不会被访问到，但这部分数据依然留存在缓存中，消耗缓存空间。
缓存污染会随着数据的持续增加而逐渐显露，随着服务的不断运行，缓存中会存在大量的永远不会再次被访问的数据。缓存空间是有限的，如果缓存空间满了，再往缓存里写数据时就会有额外开销，影响Redis性能。这部分额外开销主要是指写的时候判断淘汰策略，根据淘汰策略去选择要淘汰的数据，然后进行删除操作
- 缓存大小设置
建议把缓存容量设置为总数据量的 15% 到 30%，兼顾访问性能和内存空间开销
CONFIG SET maxmemory 4gb
- 缓存淘汰策略
Redis共支持八种淘汰策略，分别是noeviction、volatile-random、volatile-ttl、volatile-lru、volatile-lfu、allkeys-lru、allkeys-random 和 allkeys-lfu 策略。
-
不淘汰
1）noeviction （v4.0后默认的）
该策略是Redis的默认策略。在这种策略下，一旦缓存被写满了，再有写请求来时，Redis 不再提供服务，而是直接返回错误。这种策略不会淘汰数据，所以无法解决缓存污染问题。一般生产环境不建议使用。
- 对设置了过期时间的数据中进行淘汰
1）随机：volatile-random
在设置了过期时间的键值对中，进行随机删除。因为是随机删除，无法把不再访问的数据筛选出来，所以可能依然会存在缓存污染现象，无法解决缓存污染问题。
2）ttl：volatile-ttl
这种算法判断淘汰数据时参考的指标比随机删除时多进行一步过期时间的排序。Redis在筛选需删除的数据时，越早过期的数据越优先被选择。
3） lru：volatile-lru
Redis优化了LRU算法实现：
Redis会记录每个数据的最近一次被访问的时间戳。在Redis在决定淘汰的数据时，第一次会随机选出 N 个数据，把它们作为一个候选集合。接下来，Redis 会比较这 N 个数据的 lru 字段，把 lru 字段值最小的数据从缓存中淘汰出去。通过随机读取待删除集合，可以让Redis不用维护一个巨大的链表，也不用操作链表，进而提升性能。
Redis 选出的数据个数 N，通过 配置参数 maxmemory-samples 进行配置。个数N越大，则候选集合越大，选择到的最久未被使用的就更准确，N越小，选择到最久未被使用的数据的概率也会随之减小
4） lfu：volatile-lfu
redis的LFU算法实现:
当 LFU 策略筛选数据时，Redis 会在候选集合中，根据数据 lru 字段的后 8bit 选择访问次数最少的数据进行淘汰。当访问次数相同时，再根据 lru 字段的前 16bit 值大小，选择访问时间最久远的数据进行淘汰。
- 全部数据进行淘汰
1）随机：allkeys-random
从所有键值对中随机选择并删除数据。volatile-random 跟 allkeys-random算法一样，随机删除就无法解决缓存污染问题。
2） lru：allkeys-lru
使用 LRU 算法在所有数据中进行筛选。具体LFU算法跟上述 volatile-lru 中介绍的一致，只是筛选的数据范围是全部缓存
3） lfu：allkeys-lfu
使用 LFU 算法在所有数据中进行筛选。具体LFU算法跟上述 volatile-lfu 中介绍的一致，只是筛选的数据范围是全部缓存
更新缓存的模式：https://coolshell.cn/articles/17416.html
- 最常用的Cache Aside Pattern：
读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
更新的时候，先更新数据库，然后再删除缓存。