Springboot整合redis与缓存

Springboot整合

SpringBoot操作数据：spring-data jpa jdbc mongodb redis

SpringData也是和SpringBoot齐名的

说明：在springboot2.X之后，原来使用jedis被替换成了lettuce

jedis：采用的直接连接，多个线程操作的话，是不安全的，如果想要避免不安全，使用jedis pool连接池！BIO

lettuce：采用netty，实例可以在多个·线程中进行共享，不存在线程不安全情况！可以减少线程数量，更新NIO模式

源码分析

    @Bean
    @ConditionalOnMissingBean(
        name = {"redisTemplate"} //我们可以自己定义一个redisTemplate来替换这个默认值
    )
    public RedisTemplate redisTemplate(RedisConnectionFactory redisConnectionFactory) throws UnknownHostException {
    //默认的RedisTemplate没有过多的设置，redis对象都是需要序列化的
    //两个泛型都是objectobject类型，我们需要强制转换
        RedisTemplate template = new RedisTemplate();
        template.setConnectionFactory(redisConnectionFactory);
        return template;
    }

    @Bean
    @ConditionalOnMissingBean //由于String是redis中最常用的类型，所以单独提出来了一个类型bean
    public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) throws UnknownHostException {
        StringRedisTemplate template = new StringRedisTemplate();
        template.setConnectionFactory(redisConnectionFactory);
        return template;
    }

整合测试

• 导入依赖

        
            org.springframework.boot
            spring-boot-starter-data-redis
        

• 配置连接

#自动配置类都会绑定一个properties配置文件RedisAutoConfiguration  RedisProperties
spring.redis.port=6379
spring.redis.host=121.40.162.47
spring.redis.password=123456

• 测试

class Redis02SpringbootApplicationTests {
    @Autowired
    private RedisTemplate redisTemplate;
    @Test
    void contextLoads() {

        //redisTemplate 操作不同数据类型 api和指令是一样的
        //opsForValue 操作字符串 类似String
        //opsForList 操作list，类型List
        //opsForSet
        //opsForHash
        //opsForGeo
        //opsForZSet
        //opsForHyperLogLog

        //除了基本的操作，我们通常的方法都可以直接redisTemplate操作，比如事务和基本正删改查
        //获取redis连接对象
//        RedisConnection connection = redisTemplate.getConnectionFactory().getConnection();
//        connection.flushDb();
//        connection.flushAll();
        redisTemplate.opsForValue().set("myset","你好");
        System.out.println(redisTemplate.opsForValue().get("myset"));
    }

}

默认的序列化配置

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ezXXOoUc-1638704868516)(C:\Users\你在教我作事？\AppData\Roaming\Typora\typora-user-images\image-20211203213656079.png)]

默认序列化方式是JDK序列化，我们可能会使用json来序列化

没序列化

    @Test
    public void test() throws JsonProcessingException {
        //真实开发一般都使用json来传递对象
        User user = new User("你好", 3);
//        String string = new ObjectMapper().writeValueAsString(user);
        redisTemplate.opsForValue().set("user",user);
        System.out.println(redisTemplate.opsForValue().get("user"));
    }

所有对象需要序列化

自定义序列化

    //编写我们自己的redisTemplate
//编写自己的redsiTemplate
    @Bean
//    @SuppressWarnings("all")
    public RedisTemplate redisTemplate(RedisConnectionFactory factory) {
        //为了自己开发方便使用Stirng Object类型
        RedisTemplate template = new RedisTemplate();
        template.setConnectionFactory(factory);

        // 序列化配置 解析任意对象
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
        // json序列化利用ObjectMapper进行转义
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        jackson2JsonRedisSerializer.setObjectMapper(om);
        // 2.序列化String类型
        StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();

        // key采用String的序列化方式
        template.setKeySerializer(stringRedisSerializer);
        // hash的key也采用String的序列化方式
        template.setHashKeySerializer(stringRedisSerializer);
        // value序列化方式采用jackson
        template.setValueSerializer(jackson2JsonRedisSerializer);
        // hash的value序列化方式采用jackson
        template.setHashValueSerializer(jackson2JsonRedisSerializer);
        template.afterPropertiesSet();

        return template;
    }

class Redis02SpringbootApplicationTests {
    @Autowired
    @Qualifier("redisTemplate")
    private RedisTemplate redisTemplate;
    @Test
    void contextLoads() {

    }
    @Test
    public void test() throws JsonProcessingException {
        //真实开发一般都使用json来传递对象
        User user = new User("你好", 3);
        redisTemplate.opsForValue().set("user",user);
        System.out.println(redisTemplate.opsForValue().get("user"));
    }

}

在企业开发中，我们80%的情况下，都不会使用原生的方式编写代码我们通常会使用工具类来减少代码的重复

工具类在https://blog.csdn.net/qq_52329552/article/details/121734522

Redis.conf讲解

启动的时候，就通过配置文件

单位

1、配置文件unit单位对大小写不敏感

包含

就好比我们学习Spring、import、include

网络配置

bind 127.0.0.1 绑定的ip
protected-mode yes 保护模式
port 6379 端口号设置

通用GENERAL

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 " " 日志文件的位置名
databases 16 数据库的数量 默认16个
always-show-logo yes 是否显示logo

快照

持久化，在规定的时间内，执行了多少次操作，则会持久化

redis是内存数据库，如果没有持久化数据断电即失！

如果3600秒内如果至少有一个key进行了修改我们就持久化操作
如果300秒内如果至少有一百个key进行了修改我们就持久化操作
# save 3600 1
# save 300 100
# save 60 10000

stop-writes-on-bgsave-error yes 持久化如果出错，是否还需要继续工作！

redbcompression yes 是否压缩rdb文件，需要消耗cpu资源

rdbchecksum yes 保存rdb文件的时候，进行错误的检查效验

dir ./ rdb文件保存从目录

REPLICATION赋值，我们后面讲解主从复制的时候在进行讲解

SECURITY安全

设置redis登录密码
方式一vim  redis.conf在SECURITY中写入
repuirepass "密码"
方式二登录redis
127.0.0.1:6379> auth 123456 redis     密码验证
OK
127.0.0.1:6379> config get requirepass 获取密码
1) "requirepass"
2) "123456"
127.0.0.1:6379> config set repuirepass " " 设置密码语句
当设置密码了则需要验证

限制CLIENTS

maxclients 10000 设置能连接上客户端最大数
maxmemory  redis配置最大的内存容量
maxmemory-policy noeciction #内存达到上限之后处理策略
maxmemory-policy noviction (内存到达上限后的处理策略)　　

1、volatile-lru：只对设置了过期时间的key进行LRU（默认值）

2、allkeys-lru：删除LRU算法的key

3、volatile-random：随机删除即将过期的key

4、allkeys-random：随机删除

5、volatile-ttl：删除即将过期的

6、noeviction：永不过期，返回错误

APPEND ONLY 模式

appendonly no   默认不开启aof模式 默认是使用rdb持久化方式，在大部分情况下rdb完全够用
appendfilename "appendonly.aof" 持久化的文件名字 .rdb文件

# appendfsync always 每次修改了都会写入sync 速度比较慢
appendfsync everysec 每秒执行一次sync，可能会丢失一秒的数据
# appendfsync no	 不执行 sync 这个时候操作系统自己同步数据 速度最快

Redis持久化

Raedis是内存数据库，如果不将内存中的数据状态保存的磁盘，那么一旦服务进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化功能！

RDB

在指定事件间隔将内存中的数据集快照写入磁盘，也就是行话讲的快照Snapshot快照，它恢复是将快照文件直接读到内存里。

Redis会单独创建(fork)一个子进程来进程持久化，会先将数据写入一个临时文件中，待持久化过程结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模的数据的恢复，且对于数据恢复的完整性不是非常敏感，那么RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化后数据可能丢失。我们默认的就是RDB一般情况下不需要修改配置！

有时候在生产环境我们会将这个文件进行备份

rdb保存的文件是 dump.rdb 都是在我们的配置文件中进行配置的！

在60秒内进行五条数据修改就会触发
首先进入usr/local/bin中
可以看到有一个dump.rdb
rm -rf dump.rd删除其文件

127.0.0.1:6379> save
OK
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> set k5 v5
OK
127.0.0.1:6379> set k6 v6
OK
127.0.0.1:6379> set k7 v7
OK
127.0.0.1:6379> shutdown
not connected> exit

可以看到产生了一个新的rdb文件

触发机制

1、save的规则满足的情况下，会自动触发rdb规则
2、执行flushall命令，也会触发rdb规则
3、退出redis、也会产生rdb规则

备份就会自动生成一个dump文件

如何恢复rdb文件

1、只需要将rdb文件放到redis启动目录下，redis启动的时候会自动检查dump.rdb恢复其中的数据
2、查看需要存放的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"  如果在这个目录下存在dump.rdb文件，启动的时候就会自动恢复其中的数据
127.0.0.1:6379> 

几乎自动默认的配置就够用了但是我们还需要去学习

优点：

1、适合大规模数据恢复 dump.rdb
2、如果对数据的完整性不高

缺点：

1、需要一定的时间间隔！如果redis意外宕机了，这个最后一次修改数据就没有了！
2、fork进程的时候会占用一定内存空间！

AOF(Append Only File)

以日志形式来记录每个写操作，将redis执行过的所有指令记录下来（读操作不记录），只许追加文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容写指令从前后执行一次以完成数控的恢复工作

将我们所有命令记录下来，history，恢复的时候在执行一遍

默认是不开启的，我们需要手动进行配置！我们只需要将appendonly改成yes即可

重启就可以生效了

如果这个配置文件aof有错误这个时候redis，是启动不起来的。我们就需要修复这个aof文件

redis给我们提供了这样一个工具redis-check-aof  --fix

重写规则

aof默认就是文件的无限的追加，文件会越来越大！

如果这个aof文件2大于64m，fork一个新的进程来将我们文件进行重写

aof优点和缺点

优点：

1、每一次修改都同步，文件的完整性会更加的好！
2、每秒同步一次，可能会丢失一次数据
3、从不同步，效率最高的

缺点

1、相对于数据文件来说，aof远远大于rdb，修复速度比rdb慢
2、Aof运行小角落也比rdb慢，所以我们redis默认操作就是rdb

Redis发布订阅

Redis发布订阅(pub/sub)是一种消息通信模式：发送(pub)发送消息，订阅者(sub)接收消息

Redis客户端可以订阅任意数量的频道

订阅/发布消息图：

第一个：消息发布者，第二个：频道，第三个：消息订阅者！

下图展示了频道channel1，以及订阅这个频道的三个客户端–client2、cilent5和client1之间的关系

当有新消息通过PUBLISH命令发送给频道channel1时，这个消息就会被发送给订阅它的三个客户端：

这些命令被广泛用于构建时通信应用，比如网络聊天室和实时广播、实时提醒

序号	命令及描述
1	PUSUBSCRIBE pattern [patten…] 订阅一个或多个符合给定模式的频道
2	PUBSUB subcommand[argument[argument]] 将信息发送到指定的频道
3	PUBLISH channel message 将信息发送到指定的频道(消息发送者)
4	PUNSUBSCRIBE[patten[patten]] 退订所有给定模式的频道
5	SUBSCRIBE channel[channel…] 订阅给定一个或多个频道的信息
6	UNSUNSCRIBE[channel [channel…]] 指退订给定的频道

测试

订阅端
127.0.0.1:6379> subscribe tang			订阅一个频道
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "tang"
3) (integer) 1
等待接收信息
1) "message"  消息
2) "tang"     那个频道的消息
3) "hello tang" 消息内容
1) "message"
2) "tang"
3) "hello redis"

发送端
127.0.0.1:6379> publish tang "hello tang"   发布者发布消息到频道
(integer) 1
127.0.0.1:6379> publish tang "hello redis"  
(integer) 1
127.0.0.1:6379> 

原理

Redis是使用c实现的，通过分析Redis源码里的pubsub.c文件，了解发布和订阅机制的底层实现，籍此加深对redis的理解，Redis通过PUBLSH、SUBSCRIBE和PSUBSRIBE等命令发布和订阅功能。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OZnQP2r8-1638704868533)(C:\Users\你在教我作事？\Desktop\lianbiao.png)]

微信：

通过SUBSCRIBE命令订阅某频道后，redis-server里维护了一个字段，字典的键就是一个个频道！，而字典的值则是一个链表，链表中保存了所有订阅这个channel的客户端SUBSCRIBE命令的关键，就是将客户端添加到给定channel的订阅链表中

通过PUBLISH命令向订阅者发送消息，redis-server会使用给定的频道作为键，在它维护的channel字典中查找记录了订阅这个频道的所有客户端链表，遍历=这个链表，将消息发布给所有订阅者。

Pub/Sub从字面上理解就是发布(Publish)和订阅(Subscribe)，在redis中，你可以设定某一个key值进行消息发布及消息订阅，当key值上进行消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是作用实时消息系统，比如聊天、群聊

使用场景：

1、实时交流沟通

2、实时聊天

3、订阅关注系统

稍微复杂消息我们会使用消息中间键

Redis主从复制

概念

主从复制，是指将一台Redis服务器的数据，复制到其它的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower)

注意：数据的复制是单向的，只能由主节点到从节点Master以写为主，Slave以读为主

主从复制的作用主要包括：

1、数据冗余：主从复制实现了数据的备份，是持久化之外的一种数据冗余方式

2、故障恢复：当主节点出现了问题时，可以由从节点提供服务，实现快速故障恢复；实际上是一种服务的冗余

3、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，有从节点分担读负载，可以大大提高Redis服务器的并发量

4、高科用于基石：处理上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是提高Redis高可用的基础

一般来说，要将Redis运用于工程项目中，只使用一台Redis的万万不能的，原因如下：

1、从数据结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大

2、从容量上，当个Redis服务器内存容量是有限的，就算一台Redis服务器内存容量为256G，也不能将所有的内存用作Redis存储内存，电商网站上的商品，一般都是一次上传，无数次浏览的，说得专业点就算“多读少写”。

对于这种场景，我们可以使用：

主从复制，读写分离！80%操作都是在进行读操作!减缓服务器的压力！架构中经常使用！一主二从！

环境配置

只配置从库，不用配置主库

127.0.0.1:6379> info replication      查看当前库信息
# Replication
role:master   角色maaster
connected_slaves:0  没有从机
master_failover_state:no-failover
master_replid:5ec6fca9afe93e60bd423b03e2a90eaa67bdb95c
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

复制三个配置文件

[root@iZbp13y8ibecb98ib9msjpZ tconfig]# cp redis.conf redis1.conf
[root@iZbp13y8ibecb98ib9msjpZ tconfig]# cp redis.conf redis2.conf
[root@iZbp13y8ibecb98ib9msjpZ tconfig]# cp redis.conf redis3.conf

修改三个配置文件

[root@iZbp13y8ibecb98ib9msjpZ tconfig]# vim redis1.conf 
^[[A[root@iZbp13y8ibecb98ib9msjpZ tconfig]# vim redis2.conf 
[root@iZbp13y8ibecb98ib9msjpZ tconfig]# vim redis3.conf 
分别是
1、端口号
2、pid名字
3、log文件名字
4、dump.rdb文件名字

修改完毕之后，启动我们三个redis服务器，可以通过进程信息查看！

一主二从

默认情况下，每台redis都是主机：我们一般情况下配置从机

认老大！一主(79)二从(80,81)

端口：81信息

127.0.0.1:6381> SLAVEOF 127.0.0.1 6379          slaveof host 6379 找谁当老大
OK
127.0.0.1:6381> info replication                可以看到主机的信息
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:1
slave_read_repl_offset:1
slave_repl_offset:1
master_sync_total_bytes:-1
master_sync_read_bytes:0
master_sync_left_bytes:-1
master_sync_perc:-0.00
master_sync_last_io_seconds_ago:0
master_link_down_since_seconds:-1
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:5aefb5ee9e0215e8454222db5da4c6673a80c8e3
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
127.0.0.1:6381> 

主机信息

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:5ec6fca9afe93e60bd423b03e2a90eaa67bdb95c
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
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=wait_bgsave,offset=0,lag=0
slave1:ip=127.0.0.1,port=6380,state=wait_bgsave,offset=0,lag=0
master_failover_state:no-failover
master_replid:b91a8cd31256e483dc2b7ebe61b429ab8b7838a4
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:0
127.0.0.1:6379> 

真实的主从配置应该在配置文件中配置，这样的话是永久，我们这里使用的是命令是暂时的

细节了解：

注：主机可以写，从机只能读不能写！主机中所有信息

主机

从机

测试：

主机断开操作。从机依旧连接到主机，但是没有写操作，这个时候如果主机回来了从机依旧可以恢复写信息

如果是使用命令行，来配置的主从，这个时候如果重启了，就会变回主机！只要变为从机，立马就会从主机中获取值！

复制原理

Slave启动成功连接到master后会发送一个sync命令

Master接到命令，启动后台的磁盘进程，同时收集所有接收到的用于修改数据命令集，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步

全量复制：而slave服务在接收到数据库文件后，将其存盘并加载到内存中。

增量复制：Master继承将新的所有收集到的修改命令依次传给slave，完成同步

但是只要重新连接到master，一次完全同步（全量复制）将被自动执行

链路模式

这个也可以完成层层链路

如果没有老大了这个时候能不能选择一个老大吗？

谋朝篡位

当主机断开连接我们可以使用 slaveof no one让自己变成主机！其它节点可以手动连接到这个主节点
127.0.0.1:6381> SLAVEOF no one
OK
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:23c327dd0ab478a6f023d0d2146b2b551bc019e2
master_replid2:80bb309d806777782b5ea1a43ab53353ac307ed1
master_repl_offset:1743
second_repl_offset:1744
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:362
repl_backlog_histlen:1382
127.0.0.1:6381> 

如果这个时候老大修复了，那就重新连接

哨兵模式(自动选举老大)

概述：

从原本的主从复制来说，如果主机宕掉了，需要手动设置一台从机为一个新的主机，但是这种手动的配置需要人工干预，耗费时间和人力，并且在人工干预的时间内还会造成服务不可用的情况，对于开发者来说这不是一种好的解决方案。Redis从2.8开始出现了哨兵模式

哨兵模式可以理解为谋权篡位的自动版，可以在后台监视主机是否故障，如果发生了故障就会以投票的方式在从机中选出一个作为主机

Redis提供了哨兵的命令，并且它是一个特殊的模式，它会创建出一个完全独立于Redis服务器的进程，一个哨兵可以对多台服务器进行监控，并且可以有多个哨兵，每个哨兵会定时发送PING命令给服务器，并且还要在一定时间内得到服务器的响应，得到响应之后哨兵模式才会判定你现在状态正常。如果在规定的时间内它发送的请求主机没有得到响应，那么哨兵便会初步判断，当前主机是主观下线，其余的哨兵发现这台主机没有在规定时间内响应数据，那么便会以每秒一次的频率对主机进行判断，它确实是主观下线了，那么主机就会被标记为客观下线，主机挂掉之后，哨兵便会通过投票的方式在挂掉的主机下的从机中选出一个作为新主机

这里哨兵只有两个作用

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器
• 当哨兵检测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让他们切换主机

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

测试

我们目前的状态是一主二从

1、配置哨兵配置文件(sentinel.conf)

sentinel monitor 被监控的名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1

后面的数字一代表主机挂了，slave头票看让谁接替成为主机，票数多的就会成为主机！

2、启动哨兵！

[root@iZbp13y8ibecb98ib9msjpZ bin]# redis-sentinel tconfig/sentinel.conf

20379:X 05 Dec 2021 17:06:03.253 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
20379:X 05 Dec 2021 17:06:03.254 # Redis version=6.2.6, bits=64, commit=00000000, modified=0, pid=20379, just started
20379:X 05 Dec 2021 17:06:03.254 # Configuration loaded
20379:X 05 Dec 2021 17:06:03.254 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.2.6 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 20379
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           https://redis.io       
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

20379:X 05 Dec 2021 17:06:03.302 # Sentinel ID is 8b233d6c719d1980b9772a2908c0091f02057fef
20379:X 05 Dec 2021 17:06:03.302 # +monitor master myredis 127.0.0.1 6379 quorum 1
20379:X 05 Dec 2021 17:06:03.354 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379

如果Master断开了那么这个时候就会从从机中随机选择一个

如果主机此时会来了，只能归并到新的主机下，当做从机，这就是哨兵模式的规则！

哨兵模式优缺点

优点

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内存数据库中内衣，也就是缓存没有命中，于是就向持久层数据库中查询。发现也没有，于是本次查询失败。当很多的时候，缓存都没有名字，于是都去请求了持久化数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透

解决方案

布隆过滤器

布隆过滤器是一种数据结构，对所有可能查询的参数hash形式存储，在控制层进行效验，不符合则丢弃，从而避免了对底层存储系统查询的压力：

缓存空对象

当存储层不命中后，即使返回的空对象也将存储其缓存起来，同时会设置一个过期，之后在访问这个数据会将从缓存中获取，保护了后端数据源

但是这个方法会存在两个问题

1、如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键；

2、即使对空值设置了过期时间，还是会存在缓冲层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响

缓存击穿(数据量太大，缓存过期！)

概述

缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对着一个点进行访问，当这个key在失效的瞬间，持续的大并发就被穿破缓存，直接请求数据库，就像在一个屏障上开了一个洞。
当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库查询最新数据，并且回写缓存，会导致数据库瞬间压力过大

比如热搜排行上，一个热点新闻被同时大量访问就可能导致缓存击穿。

解决方案

设置热点数据永不过期
从缓存层面来看，没有设置过期时间，所以不会出现任店key过期后产生的问题

加互斥锁
分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其它线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁考验很大

缓存雪崩

概念

大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩。

解决方案

redis高可用
这个思想的含义是，既然redis有肯挂掉，那我多增设几台redis，这样一台挂掉之后其它的还可以继续工作，其实就是搭建的集群(异地多活)

限流降级
这个解决方案的思想，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其它线程等待

数据预热
数据加热的含义就是在正式部署之前，我先把肯的数据预先访问一遍，这样部分肯大量访问的数据就会加载到缓冲中。在即将发送大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽力均匀