redis

Redis

一、Redis 概述

Redis 介绍

• Redis 是一个开源的 key-value 存储系统。
• 和 Memcached 类似，它支持存储的 value 类型相对更多，包括 string (字符串)、list (链表)、set (集合)、zset (sorted set –有序集合) 和 hash（哈希类型）。
• 这些数据类型都支持 push/pop、add/remove 及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。
• 在此基础上，Redis 支持各种不同方式的排序。
• 与 memcached 一样，为了保证效率，数据都是缓存在内存中。
• 区别的是 Redis 会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件。
• 并且在此基础上实现了 master-slave (主从) 同步。应用场景配合关系型数据库做高速缓存

应用场景

• 高频次，热门访问的数据，降低数据库IO。

• 分布式架构，做 session 共享。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-B988ytJN-1685623857784)(null)]

多样的数据结构存储持久化数据

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-E0FVwM4b-1685623858077)(null)]

相关技术

Redis 使用的是单线程 + 多路 IO 复用技术：

多路复用是指使用一个线程来检查多个文件描述符（Socket）的就绪状态，比如调用 select 和 poll 函数，传入多个文件描述符，如果有一个文件描述符就绪，则返回，否则阻塞直到超时。得到就绪状态后进行真正的操作可以在同一个线程里执行，也可以启动线程执行（比如使用线程池）。

串行 vs 多线程 + 锁（memcached） vs 单线程 + 多路 IO 复用 (Redis)（与 Memcache 三点不同：支持多数据类型，支持持久化，单线程 + 多路 IO 复用） 。

二、Key键操作

keys * # 查看当前所有key
exists key # 判断某个Key是否存在
type key # 查看你的key是什么类型
del key # 删除指定的key数据
unlink key # 根据value选择非阻塞删除,仅将Keys从Keyspace元数据中删除，真正的删除会在后续异步操作
expire key 10 # 10秒钟：为给定的Key设置过期时间
ttl key # 查看还有多少秒过期，-1表示永不过期，-2表示已过期
select 0 # 切换数据库命令
dbsize # 查看当前数据库的key的数量
flushdb # 清空当前库

三、常用数据类型

1、String字符串

常用命令

set key1 value # 设置Key值
get key2 value # 获取Key值
append <key><value> # 将给定的<value>追加到原值的末尾
strlen <key> # 获取值的长度
setnx <key><value> # 只有在Key不存在时，设置key的值
incr <key> # 将key中储存的数字值加1；只能对数字值操作，如果为空，新增值为1
decr <key> # 将Key中储存的数字值减1
incrby / decrby <key><步长> # 将Key中储存的数字值增减。自定义步长。
mset <key1><value1><key2><value2>... # 同时设置一个或多个key-value对
mget <key1><key2><key3> # 同时获取一个或多个value
msetnx <key1><value1><key2><value2> # 同时设置一个或多个key-value对，当且仅当所有给定Key都不存在
setex <key><过期时间><value> # 设置键值的同时，设置过期时间，单位秒

2、List列表

底层是个双向链表存储

常用命令

lpush / rpush <key><value1><value2><value3>... # 从左边 / 右边插入一个或多个值
lpop / rpop <key> # 从左边 / 右边吐出一个值。值在键在，值亡键亡
rpoplpush <key1><key2> # 从<key1>列表右边吐出一个值，插入到<key2>列表左边
lrange <key><start><stop> # 按照索引下标获得元素(从左到右)

3、Set集合

Redis的set是String类型的无序集合。它底层其实是一个value为null的hash表。

常用命令

sadd <key><value1><value2>... # 将一个或多个member元素加入到集合Key中，已经存在的member元素被忽略
smembers <key> # 取出该集合的所有值
sismember <key><value> # 判断集合<key>是否为含有该<value>值，有1，没有0
scard <key> # 返回该集合的元素个数
srem <key><value1><value2>... #删除集合中的某个元素
spop <key> # 随机从该集合中吐出一个值
srandmember <key><n> # 随机从该集合中取出n个值，不会从集合中删除
smove <souce><destination>value # 把集合中一个值从一个集合移动到另一个集合
sinter <key1><key2> #返回两个集合的交集元素
sunion <key1><key2> # 返回两个集合的并集元素
sdiff <key1><key2> # 返回两个集合的差集元素(key1中的，不包含key2中的)

4、Hash

Redis hash 是一个string类型的field 和 value的映射表，hash特别适合存储对象

类似Java里面的Map

常用命令

hset <key><field><value> # 给<key>集合中的 <field>键赋值<value>
hget <key1><field>从<key1>集合<field>取出value
hmset <key1><field1><value1><field2><value2>...# 批量设置hash的值
hexists <key1><field> # 查看哈希表key中，给定域field是否存在
hkeys <key>列出该hash集合的所有field
hvals <key>列出该hash集合的所有value
hincrby <key><field><increment>为hash表 key中的域field的值加上增量1 -1

5、Zset有序集合

略：

四、配置文件详解

配置文件在redis.conf里面

bind 192.168.1.100 10.0.0.1
bind 127.0.0.1 如果不注释即只能通过本地访问
# bind 127.0.0.1 可通过其他主机访问

protected-mode yes # 开启redis的保护模式 远程不可以访问
protected-mode no # 远程可以访问

五、SpringBoot整合Redis

导入依赖

<!--redis-->
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>

    <!--线程池pool-->
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-pool2</artifactId>
    </dependency>

配置文件

spring:
  redis:
    host: localhost
    port: 6379
    database: 0
#连接超时时间
    connect-timeout: 1800000
    lettuce:
      pool:
#连接池最大连接数(使用负值表示没有限制)
        max-active: 20
#最大阻塞等待时间(负数表示没限制)
        max-wait: -1
#连接池中的最大空闲连接
        max-idle: 5
#连接池中的最小空闲连接
        min-idle: 0

Redis Key Value 序列化

package redis.config;

import org.springframework.cache.annotation.CachingConfigurerSupport;
import org.springframework.cache.annotation.EnableCaching;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.StringRedisSerializer;

/**
 * redis序列化
 */
@EnableCaching
@Configuration
public class RedisConfig extends CachingConfigurerSupport {

    @Bean
    public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory connectionFactory) {
        RedisTemplate<Object, Object> redisTemplate = new RedisTemplate<>();

        //默认的Key序列化器为：JdkSerializationRedisSerializer
        redisTemplate.setKeySerializer(new StringRedisSerializer()); // key序列化
        redisTemplate.setValueSerializer(new GenericJackson2JsonRedisSerializer()); // value序列化

        redisTemplate.setConnectionFactory(connectionFactory);
        return redisTemplate;
    }
}

六、事务和锁机制(简单操作)

1、事务定义

Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化，按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求打断。

Redis事务的主要作用就是串联多个命令防止别的命令插队。

Multi 、Exec 、discard

从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec 后，Redis会将之前的命令队列中的命令依次执行。

组队的过程中可以通过discard来放弃组队。

事务的错误处理（2种情况）

1、组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消。

实战操作

2、如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会被执行成功！

实战操作

2、为什么要做成事务

想想一个场景：有很多人有你的账户，同时去参加双十一抢购。

事务冲突的问题
例子

• 一个请求想给金额减 8000；

• 一个请求想给金额减 5000；

• 一个请求想给金额减 1000。

最终我们可以发现，总共金额是 10000，如果请求全部执行，那最后的金额变为 - 4000，很明显不合理。

悲观锁

悲观锁 (Pessimistic Lock)，顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会 block 直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

乐观锁

乐观锁 (Optimistic Lock)，顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis 就是利用这种 check-and-set 机制实现事务的。

3、演示乐观锁和事务特性

WATCH key [key …]

在执行 multi 之前，先执行 watch key1 [key2]，可以监视一个 (或多个) key ，如果在事务执行之前这个 (或这些) key 被其他命令所改动，那么事务将被打断。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UIHagQjp-1685623857820)(null)]

unwatch

取消 WATCH 命令对所有 key 的监视。如果在执行 WATCH 命令之后，EXEC 命令或 DISCARD 命令先被执行了的话，那么就不需要再执行 UNWATCH 了。

Redis 事务三特性

• 单独的隔离操作 ：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

• 没有隔离级别的概念 ：队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行。

• 不保证原子性 ：事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚 。

4、秒杀案例

①、案例

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OZtvQwBA-1685623857967)(null)]

核心代码

/**
     * 秒杀案例
     * @return
     */
    @GetMapping("/ms")
    public String msTest(){
        String productId = "12345";
        String userId = "";
        Random random = new Random();
        for(int i = 0; i < 4; i++){
            int num = random.nextInt(10);
            userId+=num;
        }
        boolean b = Test.doMs(userId, productId);
        String result = String.valueOf(b);
        return result;
    }

public class Test {

    public static boolean doMs(String userId ,String productId){
        //判断是否为空
        if(null == userId || null == productId){
            return false;
        }
        //连接redis
        Jedis jedis = new Jedis("localhost", 6379);
        //设置库存Key
        String kcKey = "kc:" + productId;

        //设置秒杀成功用户key
        String userKey = "user:" + productId;

        //判断库存是否为null,如果为null则秒杀还没有开始
        String kc = jedis.get(kcKey);
        if(null == kc){
            System.out.println("秒杀还没有开始哦！");
            jedis.close();
            return false;
        }
        //判断用户是否重复秒杀
        if(jedis.sismember(userKey, userId)){
            System.out.println("您已经重复秒杀，不能再秒杀！");
            jedis.close();
            return false;
        }
        //判断库存是否<1,<1则秒杀结束
        if(Integer.parseInt(kc) <= 0){
            System.out.println("没货了，秒杀结束");
            jedis.close();
            return false;
        }

        //秒杀过程
        //库存-1
        jedis.decr(kcKey);
        //用户+1
        jedis.sadd(userKey,userId);
        System.out.println("秒杀成功了！");
        jedis.close();
        return true;
    }
}

控制台输出

秒杀成功了！
秒杀成功了！
秒杀成功了！
秒杀成功了！
秒杀成功了！
秒杀成功了！
秒杀成功了！
秒杀成功了！
秒杀成功了！
秒杀成功了！
没货了，秒杀结束
没货了，秒杀结束

②、redis 事务 — 秒杀并发模拟

使用工具 ab 模拟测试：

• CentOS6 默认安装

• CentOS7 需要手动安装

通过 ab 测试

im postfile 模拟表单提交参数， 以 & 符号结尾，存放当前目录。

内容：prodid=0101&

执行：ab -n 2000 -c 200 -k -p ~/postfile -T application/x-www-form-urlencoded

访问：http://192.168.2.115:8081/Seckill/doseckill

③、超卖、连接超时、库存遗留问题

库存数量错误

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0yxQ8plG-1685623854840)(null)]

超卖问题

利用乐观锁淘汰用户，解决超卖问题。

核心代码

public class SecKill_redis {

	public static void main(String[] args) {
		Jedis jedis =new Jedis("192.168.44.168",6379);
		System.out.println(jedis.ping());
		jedis.close();
	}

	//秒杀过程
	public static boolean doSecKill(String uid,String prodid) throws IOException {
		//1 uid和prodid非空判断
		if(uid == null || prodid == null) {
			return false;
		}

		//2 连接redis
		//Jedis jedis = new Jedis("192.168.44.168",6379);
		//通过连接池得到jedis对象
		JedisPool jedisPoolInstance = JedisPoolUtil.getJedisPoolInstance();
		Jedis jedis = jedisPoolInstance.getResource();

		//3 拼接key
		// 3.1 库存key
		String kcKey = "sk:"+prodid+":qt";
		// 3.2 秒杀成功用户key
		String userKey = "sk:"+prodid+":user";

		//监视库存
		jedis.watch(kcKey);

		//4 获取库存，如果库存null，秒杀还没有开始
		String kc = jedis.get(kcKey);
		if(kc == null) {
			System.out.println("秒杀还没有开始，请等待");
			jedis.close();
			return false;
		}

		// 5 判断用户是否重复秒杀操作
		if(jedis.sismember(userKey, uid)) {
			System.out.println("已经秒杀成功了，不能重复秒杀");
			jedis.close();
			return false;
		}

		//6 判断如果商品数量，库存数量小于1，秒杀结束
		if(Integer.parseInt(kc)<=0) {
			System.out.println("秒杀已经结束了");
			jedis.close();
			return false;
		}

		//7 秒杀过程
		//使用事务
		Transaction multi = jedis.multi();

		//组队操作
		multi.decr(kcKey);
		multi.sadd(userKey,uid);

		//执行
		List<Object> results = multi.exec();

		if(results == null || results.size()==0) {
			System.out.println("秒杀失败了....");
			jedis.close();
			return false;
		}

		//7.1 库存-1
		//jedis.decr(kcKey);
		//7.2 把秒杀成功用户添加清单里面
		//jedis.sadd(userKey,uid);

		System.out.println("秒杀成功了..");
		jedis.close();
		return true;
	}
}

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zoRmvsWT-1685623858042)(null)]

连接超时，通过连接池解决

节省每次连接 redis 服务带来的消耗，把连接好的实例反复利用。通过参数管理连接的行为，代码见项目中：

连接池参数：

• MaxTotal：控制一个 pool 可分配多少个 jedis 实例，通过 pool.getResource () 来获取；如果赋值为 - 1，则表示不限制；如果 pool 已经分配了 MaxTotal 个 jedis 实例，则此时 pool 的状态为 exhausted。

• maxIdle：控制一个 pool 最多有多少个状态为 idle (空闲) 的 jedis 实例；

• MaxWaitMillis：表示当 borrow 一个 jedis 实例时，最大的等待毫秒数，如果超过等待时间，则直接抛 JedisConnectionException；

• testOnBorrow：获得一个 jedis 实例的时候是否检查连接可用性（ping ()）；如果为 true，则得到的 jedis 实例均是可用的。

解决库存遗留问题

LUA 脚本在 Redis 中的优势

• 将复杂的或者多步的 redis 操作，写为一个脚本，一次提交给 redis 执行，减少反复连接 redis 的次数，提升性能。

• LUA 脚本是类似 redis 事务，有一定的原子性，不会被其他命令插队，可以完成一些 redis 事务性的操作。

• 但是注意 redis 的 lua 脚本功能，只有在 Redis 2.6 以上的版本才可以使用。

• 利用 lua 脚本淘汰用户，解决超卖问题，redis 2.6 版本以后，通过 lua 脚本解决争抢问题，实际上是 redis 利用其单线程的特性，用任务队列的方式解决多任务并发问题。

七、Redis 主从复制

主机数据更新后根据配置和策略， 自动同步到备机的 master/slaver 机制，Master 以写为主，Slave 以读为主，主从复制节点间数据是全量的。

作用：

• 读写分离，性能扩展

• 容灾快速恢复

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rBWZYku8-1685623857931)(null)]

复制原理

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

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

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

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

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

哨兵模式 (sentinel)

反客为主：当一个 master 宕机后，后面的 slave 可以立刻升为 master，其后面的 slave 不用做任何修改。用 slaveof no one 指令将从机变为主机。而哨兵模式是反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

当主机挂掉，从机选举产生新的主机

• 哪个从机会被选举为主机呢？根据优先级别：slave-priority 。

• 原主机重启后会变为从机。

复制延时

由于所有的写操作都是先在 Master 上操作，然后同步更新到 Slave 上，所以从 Master 同步到 Slave 机器有一定的延迟，当系统很繁忙的时

候，延迟问题会更加严重，Slave 机器数量的增加也会使这个问题更加严重。

故障恢复

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kxZMlaie-1685623854814)(null)]

• 优先级：在 redis.conf 中默认 slave-priority 100，值越小优先级越高。

• 偏移量：指获得原主机数据最全的概率。

• runid：每个 redis 实例启动后都会随机生成一个 40 位的 runid。

八、Redis 集群（cluster 模式）

Redis 集群（包括很多小集群）实现了对 Redis 的水平扩容，即启动 N 个 redis 节点，将整个数据库分布存储在这 N 个节点中，每个节点存储总数据的 1/N，即一个小集群存储 1/N 的数据，每个小集群里面维护好自己的 1/N 的数据。

Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

该模式的 redis 集群特点是：分治、分片。

问题

• 容量不够，redis 如何进行扩容？

• 并发写操作， redis 如何分摊？

• 另外，主从模式，薪火相传模式，主机宕机，导致 ip 地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。

• 之前通过代理主机来解决，但是 redis3.0 中提供了解决方案。就是无中心化集群配置。

集群连接

普通方式登录：可能直接进入读主机，存储数据时，会出现 MOVED 重定向操作，所以，应该以集群方式登录。

集群登录：redis-cli -c -p 6379 采用集群策略连接，设置数据会自动切换到相应的写主机.

redis cluster 如何分配这六个节点？

• 一个集群至少要有三个主节点。
• 选项 –cluster-replicas 1 ：表示我们希望为集群中的每个主节点创建一个从节点。
• 分配原则尽量保证每个主数据库运行在不同的 IP 地址，每个从库和主库不在一个 IP 地址上。

什么是 slots？
一个 Redis 集群包含 16384 个插槽（hash slot），数据库中的每个键都属于这 16384 个插槽的其中一个。集群使用公式 CRC16 (key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16 (key) 语句用于计算键 key 的 CRC16 校验和 。

集群中的每个节点负责处理一部分插槽。 举个例子， 如果一个集群可以有主节点， 其中：

• 节点 A 负责处理 0 号至 5460 号插槽。
• 节点 B 负责处理 5461 号至 10922 号插槽。
• 节点 C 负责处理 10923 号至 16383 号插槽。

在集群中录入值
在 redis-cli 每次录入、查询键值，redis 都会计算出该 key 应该送往的插槽，如果不是该客户端对应服务器的插槽，redis 会报错，并告知应前往的 redis 实例地址和端口。

redis-cli 客户端提供了 –c 参数实现自动重定向。如 redis-cli -c –p 6379 登入后，再录入、查询键值对可以自动重定向。不在一个 slot 下的键值，是不能使用 mget,mset 等多键操作。

故障恢复

• 如果主节点下线？从节点能否自动升为主节点？注意：15 秒超时

• 主节点恢复后，主从关系会如何？主节点回来变成从机。

如果所有某一段插槽的主从节点都宕掉，redis 服务是否还能继续？

• 如果某一段插槽的主从都挂掉，而 cluster-require-full-coverage 为 yes ，那么整个集群都挂掉。

• 如果某一段插槽的主从都挂掉，而 cluster-require-full-coverage 为 no ，那么，该插槽数据全都不能使用，也无法存储。

Redis 集群优点

• 实现扩容

• 分摊压力

• 无中心配置相对简单

Redis 集群不足

• 多键操作是不被支持的。

• 多键的 Redis 事务是不被支持的，lua 脚本不被支持。

• 由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至 redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

九、Redis 应用问题解决

①、缓存穿透

问题描述

key 对应的数据在数据源并不存在，每次针对此 key 的请求从缓存获取不到，请求都会压到数据源（数据库），从而可能压垮数据源。比如:用一个不存在的用户 id 获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

缓存穿透发生的条件：

• 应用服务器压力变大
• redis 命中率降低
• 一直查询数据库，使得数据库压力太大而压垮

其实 redis 在这个过程中一直平稳运行，崩溃的是我们的数据库（如 MySQL）。

缓存穿透发生的原因：黑客或者其他非正常用户频繁进行很多非正常的 url 访问，使得 redis 查询不到数据库。

解决方案

• 对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。

• 设置可访问的名单（白名单）：使用 bitmaps 类型定义一个可以访问的名单，名单 id 作为 bitmaps 的偏移量，每次访问和 bitmap 里面的 id 进行比较，如果访问 id 不在 bitmaps 里面，进行拦截，不允许访问。

• 采用布隆过滤器：布隆过滤器（Bloom Filter）是 1970 年由布隆提出的。它实际上是一个很长的二进制向量 (位图) 和一系列随机映射函数（哈希函数）。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。

• 进行实时监控：当发现 Redis 的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务。

②、缓存击穿

问题描述

key 对应的数据存在，但在 redis 中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端数据库加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端数据库压垮。

缓存击穿的现象：

• 数据库访问压力瞬时增加，数据库崩溃
• redis 里面没有出现大量 key 过期
• redis 正常运行

缓存击穿发生的原因：redis 某个 key 过期了，大量访问使用这个 key（热门 key）。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QGYoGLD3-1685623857856)(null)]

解决方案

key 可能会在某些时间点被超高并发地访问，是一种非常 “热点” 的数据。

• 预先设置热门数据：在 redis 高峰访问之前，把一些热门数据提前存入到 redis 里面，加大这些热门数据 key 的时长。

• 实时调整：现场监控哪些数据热门，实时调整 key 的过期时长。

• 使用锁：

  • 就是在缓存失效的时候（判断拿出来的值为空），不是立即去 load db。
  • 先使用缓存工具的某些带成功操作返回值的操作（比如 Redis 的 SETNX）去 set 一个 mutex key。
  • 当操作返回成功时，再进行 load db 的操作，并回设缓存，最后删除 mutex key；
  • 当操作返回失败，证明有线程在 load db，当前线程睡眠一段时间再重试整个 get 缓存的方法。

③、缓存雪崩

问题描述

key 对应的数据存在，但在 redis 中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端数据库加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端数据库压垮。

缓存雪崩与缓存击穿的区别在于这里针对很多 key 缓存，前者则是某一个 key 正常访问。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SYSeuHXj-1685623857895)(null)]

缓存失效瞬间：

解决方案

• 构建多级缓存架构：nginx 缓存 + redis 缓存 + 其他缓存（ehcache 等）。

• 使用锁或队列：用加锁或者队列的方式来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上，该方法不适用高并发情况。

• 设置过期标志更新缓存：记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际 key 的缓存。

• 将缓存失效时间分散开：比如可以在原有的失效时间基础上增加一个随机值，比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

④、分布式锁

问题描述

随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程的特点以及分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的 Java API 并不能提供分布式锁的能力。为了解决这个问题就需要一种跨 JVM 的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

• 分布式锁主流的实现方案：

• 基于数据库实现分布式锁

• 基于缓存（Redis 等）

• 基于 Zookeeper

根据实现方式，分布式锁还可以分为类 CAS 自旋式分布式锁以及 event 事件类型分布式锁：

• 类 CAS 自旋式分布式锁：询问的方式，类似 java 并发编程中的线程获询问的方式尝试加锁，如 mysql、redis。
• 另外一类是 event 事件通知进程后续锁的变化，轮询向外的过程，如 zookeeper、etcd。

每一种分布式锁解决方案都有各自的优缺点：

• 性能：redis 最高

• 可靠性：zookeeper 最高

解决方案：使用 redis 实现分布式锁

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6ZKACObE-1685623858006)(null)]

• setnx：通过该命令尝试获得锁，没有获得锁的线程会不断等待尝试。

• set key ex 3000nx：设置过期时间，自动释放锁，解决当某一个业务异常而导致锁无法释放的问题。但是当业务运行超过过期时间时，开辟监控线程增加该业务的运行时间，直到运行结束，释放锁。

• uuid：设置 uuid，释放前获取这个值，判断是否自己的锁，防止误删锁，造成没锁的情况。

⑤、RedLock

Redlock 是一种算法，Redlock 也就是 Redis Distributed Lock，可用实现多节点 redis 的分布式锁。RedLock 官方推荐，Redisson 完成了对 Redlock 算法封装。

此种方式具有以下特性：

• 互斥访问：即永远只有一个 client 能拿到锁。
• 避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使锁定资源的服务崩溃或者分区，仍然能释放锁。
• 容错性：只要大部分 Redis 节点存活（一半以上），就可以正常提供服务

RedLock 原理（了解）

• 获取当前 Unix 时间，以毫秒为单位。

• 依次尝试从 N 个实例，使用相同的 key 和随机值获取锁。在步骤 2，当向 Redis 设置锁时，客户端应该设置一个网连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为 10 秒，则超时时间应该在5-50 毫秒之间。这样可以避免服务器端 Redis 已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试另外一个 Redis 实例。

• 客户端使用当前时间减去开始获取锁时间（步骤 1 记录的时间）就得到获取锁使用的时间。当且仅当从大多数（这里是 3 个节点）的 Redis 节点都取到锁，并且使用的时间小于锁失效时间时，锁才算获取成功。

• 如果取到了锁，key 的真正有效时间等于有效时间减去获取锁所使用的时间（步骤 3 计算的结果）。
  g-ESR4aN4j-1685623854128)]

• setnx：通过该命令尝试获得锁，没有获得锁的线程会不断等待尝试。

• set key ex 3000nx：设置过期时间，自动释放锁，解决当某一个业务异常而导致锁无法释放的问题。但是当业务运行超过过期时间时，开辟监控线程增加该业务的运行时间，直到运行结束，释放锁。

• uuid：设置 uuid，释放前获取这个值，判断是否自己的锁，防止误删锁，造成没锁的情况。

⑤、RedLock

Redlock 是一种算法，Redlock 也就是 Redis Distributed Lock，可用实现多节点 redis 的分布式锁。RedLock 官方推荐，Redisson 完成了对 Redlock 算法封装。

此种方式具有以下特性：

• 互斥访问：即永远只有一个 client 能拿到锁。
• 避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使锁定资源的服务崩溃或者分区，仍然能释放锁。
• 容错性：只要大部分 Redis 节点存活（一半以上），就可以正常提供服务

RedLock 原理（了解）

• 获取当前 Unix 时间，以毫秒为单位。
• 依次尝试从 N 个实例，使用相同的 key 和随机值获取锁。在步骤 2，当向 Redis 设置锁时，客户端应该设置一个网连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为 10 秒，则超时时间应该在5-50 毫秒之间。这样可以避免服务器端 Redis 已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试另外一个 Redis 实例。
• 客户端使用当前时间减去开始获取锁时间（步骤 1 记录的时间）就得到获取锁使用的时间。当且仅当从大多数（这里是 3 个节点）的 Redis 节点都取到锁，并且使用的时间小于锁失效时间时，锁才算获取成功。
• 如果取到了锁，key 的真正有效时间等于有效时间减去获取锁所使用的时间（步骤 3 计算的结果）。
• 如果因为某些原因，获取锁失败（没有在至少 N/2+1 个 Redis 实例取到锁或者取锁时间已经超过了有效时间），客户端应该在所有的 Redis 实例上进行解锁（即便某些 Redis 实例根本就没有加锁成功）。