带你彻底了解redis

柔光的暖阳◎ 2023-10-11 17:37 51阅读 0赞

#### 文章目录 ####

*  1.redis是什么
 *  2.redis的五种数据类型
 *   *  2.1 String
     *  2.2 Hash
     *  2.3 List
     *  2.4 Set
     *  2.5 Zset
 *  3.Redis 缓存在项目中的使用
 *   *  3.1 添加依赖
     *  3.2 配置文件application.properties
     *  3.3 创建user实体
     *  3.4 RedisTemplate 的使用方式
     *  3.5 使用 Spring Cache 集成 Redis
 *  4.缓存问题
 *   *  4.1 缓存一致性问题
     *  4.2 缓存雪崩
     *  4.3 缓存穿透和缓存击穿
 *  5.Redis 为何这么快
 *  6.Redis 和 Memcached 的区别
 *  7.Redis淘汰策略
 *  8.Redis持久化
 *   *  8.1 RDB
     *  8.2 AOF
     *   *  AOF同步策略
 *  9.主从复制
 *   *  9.1 复制过程
     *  9.2 数据同步
     *  9.3 全量复制
     *  9.4 部分复制
 *  10.哨兵
 *   *  10.1 主从复制会存在哪些问题
     *  10.2 哨兵有哪些功能？
     *  10.3 哨兵的工作原理
 *  11.聊聊 Redis 的 zset ，它是怎么实现的？
 *  12.Redis的多线程模型怎么理解
 *  13.Redis的热key和大value问题
 *  14.redis中的大key如何去处理
 *   *  14.1 什么是redis大key
     *  14.2 如何找到大key
     *  14.3 如何删除大key
 *  15 4种Redis集群方案及优缺点对比
 *  16.Redis中有哪些阻塞点以及如何解决
 *  17.Redis常见的使用场景
 *   *  11.1 缓存
     *  11.2 数据共享分布式
     *  11.3 分布式锁
     *  11.4 全局ID
     *  11.5 计数器
     *  11.6 限流
     *  11.7 位统计
     *  11.8 购物车
     *  11.9 用户消息时间线 timeline
     *  11.10 消息队列
     *  11.11 抽奖
     *  11.12 点赞、签到、打卡
     *  11.13 商品标签
     *  11.14 商品筛选
     *  11.15 用户关注、推荐模型
     *  11.16 排行榜

最近把redis所有常见的问题都给大家整理了一下，本文将会带着大家从redis的五种数据结构，到redis在项目中具体使用，再到redis更新策略和雪崩，击穿，穿透等方面深入了解一下。

## 1.redis是什么 ##

Redis 是 C 语言开发的一个开源的（遵从 BSD 协议）高性能键值对（key-value）的内存数据库，可以用作数据库、缓存、消息中间件等。

它是一种 NoSQL（not-only sql，泛指非关系型数据库）的数据库。

Redis 作为一个内存数据库具有以下特点：

*  性能优秀，数据在内存中，读写速度非常快，支持并发 10W QPS。
 *  单进程单线程，是线程安全的，采用 IO 多路复用机制。
 *  丰富的数据类型，支持字符串（strings）、散列（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）等。
 *  支持数据持久化（rdb和aof两种，后面会详细说明）。
 *  可以将内存中数据保存在磁盘中，重启时加载。
 *  主从复制，哨兵，高可用。
 *  可以用作分布式锁（如setnx或redsession）。
 *  可以作为消息中间件使用，支持发布订阅。

上面提到redis和其他key-val数据库相比，有个很明显的特征是支持多种类型的数据结构，下面我们具体谈谈这五种数据类型

## 2.redis的五种数据类型 ##

在了解这5种数据类型之前，我们有必要先看看Redis 内部内存管理是如何描述这5种数据类型的。  
![在这里插入图片描述][8ce738d75960407dacd8067b08090bb3.jpeg_pic_center]

从上图可以看出首先Redis内部使用一个**redisObject** 对象来表示所有的 key 和 value。

redisObject 最主要的信息如上图所示：type 表示一个 value 对象具体是何种数据类型，encoding 是不同数据类型在 Redis 内部的存储方式。

> 比如：type=string 表示 value 存储的是一个普通字符串，那么 encoding 可以是 raw 或者 int。

有了以上知识做支撑，我们再看看这五种具体的数据类型：

### 2.1 String ###

是 Redis 最基本的类型，可以理解成与 Memcached一模一样的类型，一个 Key 对应一个 Value。Value 不仅是 String，也可以是数字。

> String 类型是二进制安全的，意思是 Redis 的 String 类型可以包含任何数据，比如 jpg 图片或者序列化的对象。String 类型的值最大能存储 512M。

**底层数据结构：**  
string的底层实现可以是int、raw、embstr。

int 编码是用来保存整数值，raw编码是用来保存长字符串，而embstr是用来保存短字符串。

*  int，存储 8 个字节的长整型(long，2^63-1)。
 *  raw，存储大于 44 个字节的字符串(3.2 版本之前是 39 字节)
 *  embstr, 代表 embstr 格式的 SDS(Simple Dynamic String 简单动态字符串)，存储小于 44 个字节的字符串。

当 int 编码保存的值不再是整数，或大小超过了long的范围时，自动转化为raw。

对于 embstr 编码，由于 Redis 没有对其编写任何的修改程序（embstr 是只读的），在对embstr对象进行修改时，都会先转化为raw再进行修改，因此，只要是修改embstr对象，修改后的对象一定是raw的，无论是否达到了44个字节。

### 2.2 Hash ###

Hash是一个键值（key-value）的集合。Redis 的 Hash 是一个 String 的 Key 和 Value 的映射表，Hash 特别适合存储对象。常用命令：hget，hset，hgetall 等。

**底层数据结构：**  
hash的底层是 ziplist（压缩列表） 或者 hashtable（哈希表）  
当同时满足下面两个条件时，使用ziplist（压缩列表）：

*  哈希对象保存的所有键值对的键和值的字符串长度都小于64字节
 *  哈希对象保存的键值对的数量小于512个

不能满足这两个条件的时候使用 hashtable 哈希表

### 2.3 List ###

List 列表是简单的字符串列表，按照插入顺序排序。可以添加一个元素到列表的头部（左边）或者尾部（右边） 常用命令：lpush、rpush、lpop、rpop、lrange（获取列表片段）等。

> 应用场景：List 应用场景非常多，也是 Redis 最重要的数据结构之一，比如 Twitter 的关注列表，粉丝列表都可以用 List 结构来实现。
> 
> 数据结构：List 就是链表，可以用来当消息队列用。Redis 提供了 List 的 Push 和 Pop 操作，还提供了操作某一段的 API，可以直接查询或者删除某一段的元素。
> 
> 实现方式：Redis List 的是实现是一个双向链表，既可以支持反向查找和遍历，更方便操作，不过带来了额外的内存开销。

**底层数据结构：**  
list底层的数据结构可以是 ziplist(压缩列表) 和 linkedlist(双端链表)  
当同时满足下面两个条件时，使用ziplist（压缩列表）：

*  列表对象保存的所有字符串元素的长度都小于64字节
 *  列表保存的元素少于512个

不能满足这两个条件的时候使用 linkedlist(双端链表)

### 2.4 Set ###

Set 是 String 类型的无序集合。集合是通过 hashtable 实现的。Set 中的元素是没有顺序的，而且是没有重复的。常用命令：sdd、spop、smembers、sunion 等。

> 应用场景：Redis Set 对外提供的功能和 List 一样是一个列表，特殊之处在于 Set 是自动去重的，而且 Set 提供了判断某个成员是否在一个 Set 集合中。

**底层数据结构：**  
set的底层是 intset（整数数组） 或者 hashtable（哈希表）。  
当set同时满足以下两个条件时，使用 intset（整数数组）：

*  集合对象保存的所有对象都是整数值
 *  集合对象保存的元素数量小于512个

不能满足这两个条件的就使用 hashtable（哈希表）

### 2.5 Zset ###

Zset 和 Set 一样是 String 类型元素的集合，且不允许重复的元素。常用命令：zadd、zrange、zrem、zcard 等。

> 使用场景：Sorted Set 可以通过用户额外提供一个优先级（score）的参数来为成员排序，并且是插入有序的，即自动排序。
> 
> 当你需要一个有序的并且不重复的集合列表，那么可以选择 Sorted Set 结构。
> 
> 和 Set 相比，Sorted Set关联了一个 Double 类型权重的参数 Score，使得集合中的元素能够按照 Score 进行有序排列，Redis 正是通过分数来为集合中的成员进行从小到大的排序。
> 
> 实现方式：Redis Sorted Set 的内部使用 HashMap 和跳跃表（skipList）来保证数据的存储和有序，HashMap 里放的是成员到 Score 的映射。
> 
> 而跳跃表里存放的是所有的成员，排序依据是 HashMap 里存的 Score，使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

**底层数据结构：**  
zset的底层是 ziplist（压缩列表）或者skiplist（跳表）  
当zset同时满足以下两个条件时，对象使用 ziplist 编码：

*  有序集合的所有元素长度都小于64字节
 *  有序集合的元素数量小于128个

不能满足上面两个条件的使用 skiplist 编码。

--------------------

下面我们对这5种数据类型总结一下：  
![在这里插入图片描述][3911ada840d741608261049fc2316cab.png_pic_center]

接着我们继续看看在实际的项目开发中，redis是如何使用的

## 3.Redis 缓存在项目中的使用 ##

我们在日常开发中，一般通过两种方式去实现redis缓存的增删改查操作：

*  直接通过 RedisTemplate 来使用
 *  使用 Spring Cache 集成 Redis

### 3.1 添加依赖 ###

无论你打算使用哪一种方式去使用缓存，都加入以下依赖

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-pool2</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.session</groupId>
            <artifactId>spring-session-data-redis</artifactId>
        </dependency>
    
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>

我使用的SpringBoot版本为：**2.6.2**  
上面有几个关键依赖，我简单说明一下：

*  **spring-boot-starter-data-redis**：在 Spring Boot 2.x 以后底层不再使用 Jedis，而是换成了 Lettuce。
 *  **commons-pool2**：用作 Redis 连接池，如不引入启动会报错。
 *  **spring-session-data-redis**：Spring Session 引入，用作共享 Session。

### 3.2 配置文件application.properties ###

server.servlet.session.timeout=30ms
    spring.cache.type=redis
    spring.redis.host=192.168.1.2
    spring.redis.port=6379
    spring.redis.password=
    # redis默认情况下有16个分片，这里配置具体使用的分片，默认为0
    spring.redis.database=0
    # 连接池最大连接数(使用负数表示没有限制),默认8
    spring.redis.lettuce.pool.max-active=8

### 3.3 创建user实体 ###

@Data
    public class User implements Serializable {
        
    
        private static final long serialVersionUID = 662692455422902539L;
    
        private Integer id;
    
        private String name;
    
        private Integer age;
    
        public User() {
        
        }
    
        public User(Integer id, String name, Integer age) {
        
            this.id = id;
            this.name = name;
            this.age = age;
        }
    }

### 3.4 RedisTemplate 的使用方式 ###

> 默认情况下的模板只能支持 RedisTemplate<String, String>，也就是只能存入字符串，所以自定义模板很有必要。

添加配置类 RedisCacheConfig.java：

import org.springframework.boot.autoconfigure.AutoConfigureAfter;
    import org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration;
    import org.springframework.context.annotation.Bean;
    import org.springframework.context.annotation.Configuration;
    import org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory;
    import org.springframework.data.redis.core.RedisTemplate;
    import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
    import org.springframework.data.redis.serializer.StringRedisSerializer;
    
    import java.io.Serializable;
    
    @Configuration
    @AutoConfigureAfter(RedisAutoConfiguration.class)
    public class RedisCacheConfig {
        
    
        @Bean
        public RedisTemplate<String, Serializable> redisCacheTemplate(LettuceConnectionFactory connectionFactory) {
        
    
            RedisTemplate<String, Serializable> template = new RedisTemplate<>();
            template.setKeySerializer(new StringRedisSerializer());
            template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
            template.setConnectionFactory(connectionFactory);
            return template;
        }
    }

下面简单的进行测试一下：

import com.example.redisdemo.po.User;
    import lombok.extern.slf4j.Slf4j;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.data.redis.core.RedisTemplate;
    import org.springframework.web.bind.annotation.RequestMapping;
    import org.springframework.web.bind.annotation.RestController;
    
    import java.io.Serializable;
    
    @RestController
    @RequestMapping("/user")
    @Slf4j
    public class UserController {
        
        @Autowired
        private RedisTemplate<String, Serializable> redisCacheTemplate;
    
        @RequestMapping("/test")
        public void test() {
        
            redisCacheTemplate.opsForValue().set("userkey", new User(1, "ninesun", 24));
            User user = (User) redisCacheTemplate.opsForValue().get("userkey");
            log.info("当前获取对象：{}", user.toString());
        }
    }

### 3.5 使用 Spring Cache 集成 Redis ###

> Spring Cache 具备很好的灵活性，不仅能够使用 SPEL（spring expression language）来定义缓存的 Key 和各种 Condition，还提供了开箱即用的缓存临时存储方案，也支持和主流的专业缓存如 EhCache、Redis、Guava 的集成。

定义接口UserService.java：

public interface UserService {
        
        User save(User user);
    
        void delete(int id);
    
        User get(Integer id);
    }

接口实现类 UserServiceImpl.java：

import com.example.redisdemo.po.User;
    import com.example.redisdemo.service.UserService;
    import lombok.extern.slf4j.Slf4j;
    import org.springframework.cache.annotation.CacheEvict;
    import org.springframework.cache.annotation.CachePut;
    import org.springframework.cache.annotation.Cacheable;
    import org.springframework.stereotype.Service;
    import java.util.HashMap;
    import java.util.Map;
    
    @Service
    @Slf4j
    public class UserServiceImpl implements UserService {
        
    
        /**
         * 此处使用UserMap模拟数据库的存储操作
         */
        private static Map<Integer, User> userMap = new HashMap<>();
    
        static {
        
            userMap.put(1, new User(1, "肖战", 25));
            userMap.put(2, new User(2, "王一博", 26));
            userMap.put(3, new User(3, "杨紫", 24));
        }
    
    
        @CachePut(value = "user", key = "#user.id")
        @Override
        public User save(User user) {
        
            userMap.put(user.getId(), user);
            log.info("进入save方法，当前存储对象：{}", user.toString());
            return user;
        }
    
        @CacheEvict(value = "user", key = "#id")
        @Override
        public void delete(int id) {
        
            userMap.remove(id);
            log.info("进入delete方法，删除成功");
        }
    
        @Cacheable(value = "user", key = "#id")
        @Override
        public User get(Integer id) {
        
            log.info("进入get方法，当前获取对象：{}", userMap.get(id) == null ? null : userMap.get(id).toString());
            return userMap.get(id);
        }
    }

里面有三个核心注解：

*  @Cachable:

> @Cacheable 是一个既可以应用于方法级别，也可用于类级别的注解。自spring3.1开始就通过它实现了缓存管理。  
> @Cacheable的作用就是从数据库里获取一次数据后就会直接放在缓存里，下次调用时不再连接数据库而是直接从缓存中获取。  
> 为了通俗易懂的理解，举个栗子：  
> 一个方法,getBooksByUsernameAndLanguage(String username, int language)，显然，是一个获取数据库里所有我的英文书对象的方法，返回应该是一个列表。如果这个函数的返回值很大，而且会在页面上被经常调用，那么每一次调用都要重新连接数据库并返回一个数据量庞大的list，可能页面响应和资源占用会比较大。而我们希望的是，第一次调用这个方法时，返回的数据能被放到服务器端的缓存里，以便于后面要调用这个方法时，能直接从缓存里取到，这样就不用再查数据库占用资源了。而@Cacheable的作用就是这个。

@Cacheable注解只有三个属性，以该代码段为例

@Cacheable(value = "CACHE_BOOK",key = "#username", condition = "#language = 1")
    public List<Book> getBooksByUsernameAndLanguage(String username, int language) {
        
         return bookList;
    }

> value : 必须要的。就是个自己取的名字，通过它指明了第一次调用这个方法时返回的bookList将被存在内存的哪里。  
> key ： 可选。要使用SpEL表达式，这里与参数username对应，当传入的username值变了的话就不去取缓存里的数据了，而是执行getBooksByUsernameAndLanguage方法。（这是必须的，因为username变了，返回值也就变了，缓存里的数据不符合了，因此这个选项很重要）。spring默认用方法的签名来当做key。  
> condition：方法返回的结果bookList，要不要缓存起来？condition就添加了一个限定条件。这个例子中，只有传入的语言代码是1，返回的bookList才会被缓存起来，如果给language传了别的值，那么bookList是不会缓存起来的。

--------------------

@CachePut

> 执行顺序，是先调用目标方法，然后再将数据存放在缓存中。（原理：就是把缓存重新更新，然后当再次获取缓存的内容时候，就会自动的进行新的缓存获取，所以也不需要进入函数内进行内容的获取）

@CachePut(value = "user", key = "#user.id")
        @Override
        public User save(User user) {
        
            userMap.put(user.getId(), user);
            log.info("进入save方法，当前存储对象：{}", user.toString());
            return user;
        }

> Cache的存放有一定的规则那就是key值的选择，默认情况下是根据函数参数，比如上面第一个函数参数为Id的缓存，第二个函数的参数为user，如果没有定义key，那么就会造成这个缓存信息会不相符，导致查询的缓存数据是失败的，没有更新。所以在上面我们进行定义了@CachePut的key值为返回结果的Id属性，刚好和上面一致，所以整个缓存可以正常的更新使用。

--------------------

@CacheEvict

> @CacheEvict是用来清除缓存的，有以下属性：
> 
>  *  value：缓存位置名称，不能为空，同上
>  *  key：缓存的key，默认为空，同上
>  *  condition：触发条件，只有满足条件的情况才会清除缓存，默认为空，支持SpEL
>  *  allEntries：true表示清除value中的全部缓存，默认为false

--------------------

启动类要加上一个注解开启缓存：

@EnableCaching

![在这里插入图片描述][4f7a45ce951144279df6705cf316b80a.png_pic_center]

接下来进行一个简单的测试

import com.example.redisdemo.po.User;
    import com.example.redisdemo.service.UserService;
    import lombok.extern.slf4j.Slf4j;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.data.redis.core.RedisTemplate;
    import org.springframework.util.StringUtils;
    import org.springframework.web.bind.annotation.PathVariable;
    import org.springframework.web.bind.annotation.RequestMapping;
    import org.springframework.web.bind.annotation.RestController;
    
    import java.io.Serializable;
    
    @RestController
    @RequestMapping("/user1")
    @Slf4j
    public class UserController1 {
        
        @Autowired
        private UserService userService;
    
    
        @RequestMapping("/add")
        public void add() {
        
            User user = userService.save(new User(4, "李现", 30));
            log.info("添加的用户信息：{}", user.toString());
        }
    
        @RequestMapping("/delete")
        public void delete() {
        
            userService.delete(4);
        }
    
        @RequestMapping("/get/{id}")
        public void get(@PathVariable("id") String idStr) throws Exception {
        
            if (StringUtils.isEmpty(idStr)) {
        
                throw new Exception("id为空");
            }
            Integer id = Integer.parseInt(idStr);
            User user = userService.get(id);
            log.info("获取的用户信息：{}", user.toString());
        }
    }

①先调用添加接口：http://localhost:8080/user1/add  
![在这里插入图片描述][d9b1781fd37c4098af267b515fdf69c8.png_pic_center]

②调用查询接口：http://localhost:8080/user1/get/4 查询 id=4 的用户信息  
③调用删除接口删除Id=4的信息

## 4.缓存问题 ##

### 4.1 缓存一致性问题 ###

缓存和数据库数据一致性问题：分布式环境下非常容易出现缓存和数据库间数据一致性问题，针对这一点，如果项目对缓存的要求是强一致性的，那么就不要使用缓存。

我们只能采取合适的策略来降低缓存和数据库间数据不一致的概率，而无法保证两者间的强一致性。

合适的策略包括合适的缓存更新策略，更新数据库后及时更新缓存、缓存失败时增加重试机制。  
更详细的数据库和缓存一致性问题可以阅读一下：[《如何保证数据库和缓存双写一致性》][Link 1]

### 4.2 缓存雪崩 ###

缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。

和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

目前电商首页以及热点数据都会去做缓存，一般缓存都是定时任务去刷新，或者查不到之后去更新缓存的，定时任务刷新就有一个问题：

> 举个栗子：如果首页所有 Key 的失效时间都是 12 小时，中午 12 点刷新的，我零点有个大促活动大量用户涌入，假设每秒 6000 个请求，本来缓存可以抗住每秒 5000 个请求，但是缓存中所有 Key 都失效了。
> 
> 此时 6000 个/秒的请求全部落在了数据库上，数据库必然扛不住，真实情况可能 DBA 都没反应过来直接挂了。
> 
> 此时，如果没什么特别的方案来处理，DBA 很着急，重启数据库，但是数据库立马又被新流量给打死了。
> 
> 同一时间大面积失效，瞬间 Redis 跟没有一样，那这个数量级别的请求直接打到数据库几乎是灾难性的。
> 
> 如果没做熔断等策略基本上就是瞬间挂一片的节奏，你怎么重启用户都会把你打挂

解决方案：

*  缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
    
        setRedis（key, value, time+Math.random()*10000）;
 *  如果缓存数据库是分布式部署，将热点数据均匀分布在不同的缓存数据库中。
 *  设置热点数据永远不过期。

### 4.3 缓存穿透和缓存击穿 ###

缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。

解决方案：

>  *  接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；Redis 里还有一个高级用法布隆过滤器（Bloom Filter）这个也能很好的预防缓存穿透的发生。  
>     它的原理也很简单，就是利用高效的数据结构和算法快速判断出你这个 Key 是否在数据库中存在，不存在你 return 就好了，存在你就去查 DB 刷新 KV 再 return。
>  *  从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击。

缓存击穿嘛，这个跟缓存雪崩有点像，但是又有一点不一样，缓存雪崩是因为大面积的缓存失效，打崩了 DB。

而缓存击穿不同的是缓存击穿是指一个 Key 非常热点，在不停地扛着大量的请求，大并发集中对这一个点进行访问，当这个 Key 在失效的瞬间，持续的大并发直接落到了数据库上，就在这个 Key 的点上击穿了缓存。

解决方案：

*  设置热点数据永远不过期。
 *  加互斥锁，互斥锁参考代码如下  
    ![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center][]  
    代码大致思路就是：

> 首先从缓存中获取数据，如果数据不存在，我们则去获取锁，这把锁 只需要能够互斥，可重入即可，最简单的就是redis的setnx来实现，获取锁资源以后，从数据库读取数据，同时将数据更新至缓存，然后释放锁；如果获取锁资源失败，我们就让其隔一段时间之后重新尝试去获取锁资源。

## 5.Redis 为何这么快 ##

官方提供的数据可以达到 100000+ 的 QPS（每秒内的查询次数），有人就会很好奇它那么快，是不是因为多线程的缘故。

但是redis实际上是**单进程单线程**的模型，因为 Redis 完全是基于内存的操作，CPU 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是机器内存的大小或者网络带宽。  
既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章的采用单线程的方案了（毕竟采用多线程会有很多麻烦）。

既然redis是单线程了，为什么还会那么快呢？

>  *  Redis 完全基于内存，绝大部分请求是纯粹的内存操作，非常迅速，数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度是 O(1)。
>  *  数据结构简单，对数据操作也简单。
>  *  采用单线程，避免了不必要的上下文切换和竞争条件，不存在多线程导致的 CPU 切换，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有死锁问题导致的性能消耗。
>  *  使用多路复用 IO 模型，非阻塞 IO。

为什么现在的 缓存方案大多都是基于 Redis 的缓存方案而不用 Memcached 呢？

## 6.Redis 和 Memcached 的区别 ##

*  **存储方式上**：Memcache 会把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。Redis 有部分数据存在硬盘上，这样能保证数据的持久性。
 *  **数据支持类型上**：Memcache 对数据类型的支持简单，只支持简单的 key-value，，而 Redis 支持五种数据类型。
 *  **使用底层模型不同**：它们之间底层实现方式以及与客户端之间通信的应用协议不一样。Redis 直接自己构建了 VM 机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
 *  **Value 的大小**：Redis 可以达到 1GB，而 Memcache 只有 1MB。

## 7.Redis淘汰策略 ##

*  volatile-Iru:从已设置过期时间的数据集(server.db\[ i\].expires)中挑选最近最少使用的数据淘汰
 *  volatile-ttl:从已设置过期时间的数据集(server.db\[ i\].expires）中挑选将要过期的数据淘汰
 *  volatile-random:从已设置过期时间的数据集(server.db\[ i\].expires）中任意选择数据淘汰
 *  allkeys-lru:从数据集(server.db\[ i\].dict)中挑选最近最少使用的数据淘汰
 *  allkeys-random:从数据集(server.db\[ i\].dict)中任意选择数据淘汰
 *  no-enviction(驱逐)∶禁止驱逐数据

Redis 4.0 加入了 LFU（least frequency use）淘汰策略，包括 volatile-lfu 和 allkeys-lfu，通过统计访问频率，将访问频率最少，即最不经常使用的 KV 淘汰。

数据淘汰内部实现:

*  1.消极方法（passive way）：
    
     *  在主键被访问时如果发现它失效，就删除它；
     *  触发时机：在实现GET,MGET，HGET，LRANGE等所有涉及到读取命令时都会调用
 *  2.积极方法（active way）：
    
     *  周期性的从设置了失效时间的主键中，选择一部分失效的主键删除
     *  触发时机：redis的时间事件，即每隔一段时间就中断一下，完成一些操作指令

## 8.Redis持久化 ##

Redis 为了保证效率，数据缓存在了内存中，但是会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件中，以保证数据的持久化。

Redis 的持久化策略有两种：

*  RDB：快照形式是直接把内存中的数据保存到一个 dump 的文件中，定时保存，保存策略。
 *  AOF：把所有的对 Redis 的服务器进行修改的命令都存到一个文件里，命令的集合。

### 8.1 RDB ###

Redis 默认是快照 RDB 的持久化方式。

> 当 Redis 重启的时候，它会优先使用 AOF 文件来还原数据集，因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。你甚至可以关闭持久化功能，让数据只在服务器运行时存。

下面在来谈一谈RDB 是怎么工作的

默认 Redis 是会以快照"RDB"的形式将数据持久化到磁盘的一个二进制文件 dump.rdb。

工作原理简单说一下：当 Redis 需要做持久化时，Redis 会 fork 一个子进程，子进程将数据写到磁盘上一个临时 RDB 文件中。

当子进程完成写临时文件后，将原来的 RDB 替换掉，这样的好处是可以 copy-on-write。

RDB 的优点是：这种文件非常适合用于备份：比如，你可以在最近的 24 小时内，每小时备份一次，并且在每个月的每一天也备份一个 RDB 文件。

这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。RDB 非常适合灾难恢复。

RDB 的缺点是：如果你需要尽量避免在服务器故障时丢失数据，那么RDB不合适你。

既然RDB都说了，就顺便在介绍一下AOF

### 8.2 AOF ###

使用 AOF 做持久化，每一个写命令都通过 write 函数追加到 appendonly.aof 中，配置方式如下：

appendfsync yes   
    appendfsync always     #每次有数据修改发生时都会写入AOF文件。
    appendfsync everysec   #每秒钟同步一次，该策略为AOF的缺省策略。

AOF 可以做到全程持久化，只需要在配置中开启 appendonly yes。这样 Redis 每执行一个修改数据的命令，都会把它添加到 AOF 文件中，当 Redis 重启时，将会读取 AOF 文件进行重放，恢复到 Redis 关闭前的最后时刻。

#### AOF同步策略 ####

aof缓冲区数据写入aof文件时的同步策略：

**appendfsync always/eversec/no aof缓冲区数据写入aof文件时的同步策略。**

涉及操作系统的write命令、fsync命令、io缓冲区：

*  **always** 一旦aof缓冲区有数据时，就调用fsync命令强制往aof文件写数据（redis性能最差，数据可控性最好）
 *  **eversec** （默认）一旦aof缓冲区有数据时，就调用write命令往io缓冲区写数据，同时每秒调用一次fsync命令强制将io缓冲区的数据写入到aof文件（redis性能、数据可控性适中）
 *  **no** 一旦aof缓冲区有数据时，就调用wirte命令往io缓冲区写数据。由操作系统定期或当io缓冲区填满时，自动将io缓冲区的数据写入到aof文件（redis性能最好，数据可控性最差）

总结：always只调用fsync，no只调用write，eversec既调用wirte，又每秒调用一次fsync

write命令和fsync命令的区别：

*  **wirte**命令只能确定数据成功写入io缓冲区。数据是否成功写入aof文件，是由操作系统定期或当io缓冲区填满时，自动将io缓冲区的数据写入到aof文件。所以在io缓冲区的数据存在断电数据丢失的风险。
 *  **fsync**命令具有强制将io缓冲区数据写入到aof文件的机制，可以确定数据是否成功写入aof文件。

java中write即write命令，flush即fsync命令。两个命令的使用是由于操作系统的机制决定的。

使用 AOF 的优点是会让 Redis 变得非常耐久。可以设置不同的 Fsync 策略，AOF的默认策略是每秒钟 Fsync 一次，在这种配置下，就算发生故障停机，也最多丢失一秒钟的数据。

缺点是对于相同的数据集来说，AOF 的文件体积通常要大于 RDB 文件的体积。根据所使用的 Fsync 策略，AOF 的速度可能会慢于 RDB。

说了那么多，我们具体该使用哪一个呢？

无论是选择 方案还是技术时，抛开场景都是扯淡。所以如果你非常关心你的数据，但仍然可以承受数分钟内的数据丢失，那么可以只使用 RDB 持久。

AOF 将 Redis 执行的每一条命令追加到磁盘中，处理巨大的写入会降低Redis的性能，所以你为了追求数据的容灾和完整性的同时不知道你是否可以接受性能的下降。

数据库备份和灾难恢复：定时生成 RDB 快照非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度快。

> 当然了，Redis 支持同时开启 RDB 和 AOF，系统重启后，Redis 会优先使用 AOF 来恢复数据，这样丢失的数据会最少。

## 9.主从复制 ##

我们会在很多的存储方案上采取主从复制，如数据库的主从复制，来分摊访问压力：[《mysql设置主从数据库的同步》][mysql]

Redis 单节点存在单点故障问题，为了解决单点问题，一般都需要对 Redis 配置从节点，然后使用**哨兵**来监听主节点的存活状态，如果主节点挂掉，从节点能继续提供缓存功能，下面说说 Redis 主从复制的过程和原理吗？

Redis主从配置结合哨兵模式能解决单点故障问题，提高 Redis 可用性。

从节点仅提供读操作，主节点提供写操作。对于读多写少的状况，可给主节点配置多个从节点，从而提高响应效率。

### 9.1 复制过程 ###

关于复制过程，大致分为以下几步：

*  从节点执行 slaveof\[masterIP\]\[masterPort\]，保存主节点信息。
 *  从节点中的定时任务发现主节点信息，建立和主节点的 Socket 连接。
 *  从节点发送 Ping 信号，主节点返回 Pong，两边能互相通信。
 *  连接建立后，主节点将所有数据发送给从节点（**数据同步**）。
 *  主节点把当前的数据同步给从节点后，便完成了复制的建立过程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

### 9.2 数据同步 ###

数据同步的过程如下：

> Redis 2.8 之前使用 sync\[runId\]\[offset\] 同步命令，Redis 2.8 之后使用 psync\[runId\]\[offset\] 命令。

两者不同在于，Sync 命令仅支持全量复制过程，Psync 支持全量和部分复制。

介绍同步之前，先介绍几个概念：

*  **runId**：每个 Redis 节点启动都会生成唯一的 uuid，每次 Redis 重启后，runId 都会发生变化。
 *  **offset**：主节点和从节点都各自维护自己的主从复制偏移量 offset，当主节点有写入命令时，offset=offset+命令的字节长度。  
    从节点在收到主节点发送的命令后，也会增加自己的 offset，并把自己的 offset 发送给主节点。这样，主节点同时保存自己的 offset 和从节点的 offset，通过对比 offset 来判断主从节点数据是否一致。
 *  **repl\_backlog\_size**：保存在主节点上的一个固定长度的先进先出队列，默认大小是 1MB。

主节点发送数据给从节点过程中，主节点还会进行一些写操作，这时候的数据存储在复制缓冲区中。

从节点同步主节点数据完成后，主节点将缓冲区的数据继续发送给从节点，用于部分复制。

Redis 主从同步包括三个阶段。  
![在这里插入图片描述][1d915d75fb654c0abc8feb6aaa9d3e6e.png_pic_center]

第一阶段：主从库间建立连接、协商同步。

*  从库向主库发送 psync 命令，告诉它要进行数据同步。
 *  主库收到 psync 命令后,响应 FULLRESYNC 命令（它表示第一次复制采用的是全量复制），并带上主库 runID 和主库目前的复制进度 offset 。

第二阶段：主库把数据同步到从库，从库收到数据后，完成本地加载

*  主库执行 bgsave 命令，生成 RDB 文件，接着将文件发给从库。从库接收到RDB 文件后，会先清空当前数据库，然后加载 RDB 文件。
 *  主库把数据同步到从库的过程中，新来的写操作，会记录到 replication buffer 。

第三阶段，主库把新写的命令，发送到从库。

*  主库完成RDB 发送后，会把 replication buffer 中的修改操作发给从库，从库再重新执行这些操作。这样主从库就实现同步啦。

主节点响应写命令时，不但会把命名发送给从节点，还会写入复制积压缓冲区，用于复制命令丢失的数据补救。

Psync 的执行流程如下图所示：  
![在这里插入图片描述][a0da85df1d854534a0d6a8f3d6b6cd9b.jpeg_pic_center]

从节点发送 psync\[runId\]\[offset\] 命令，主节点有三种响应：

*  FULLRESYNC：第一次连接，进行全量复制
 *  CONTINUE：进行部分复制
 *  ERR：不支持 psync 命令，进行全量复制

下面在具体说下全量复制和部分复制的过程：

### 9.3 全量复制 ###

全量复制的流程如下图所示：  
![在这里插入图片描述][500a57605f85421fb1d82896f9bbb799.jpeg_pic_center]

从节点发送 psync ? -1 命令（因为第一次发送，不知道主节点的 runId，因为是第一次复制，所以 offset=-1）。

主节点发现从节点是第一次复制，返回 FULLRESYNC \{runId\} \{offset\}，runId 是主节点的 runId，offset 是主节点目前的 offset。

从节点接收主节点信息后，保存到 info 中。

主节点在发送 FULLRESYNC 后，启动 bgsave 命令，生成 RDB 文件（数据持久化）。

主节点发送 RDB 文件给从节点。到从节点加载数据完成这段期间主节点的写命令放入缓冲区。

从节点清理自己的数据库数据。

从节点加载 RDB 文件，将数据保存到自己的数据库中。如果从节点开启了 AOF，从节点会异步重写 AOF 文件。

### 9.4 部分复制 ###

①部分复制主要是 Redis 针对全量复制的过高开销做出的一种优化措施，使用 psync\[runId\]\[offset\] 命令实现。

当从节点正在复制主节点时，如果出现网络闪断或者命令丢失等异常情况时，从节点会向主节点要求补发丢失的命令数据，主节点的复制积压缓冲区将这部分数据直接发送给从节点。

这样就可以保持主从节点复制的一致性。补发的这部分数据一般远远小于全量数据。

②主从连接中断期间主节点依然响应命令，但因复制连接中断命令无法发送给从节点，不过主节点内的复制积压缓冲区依然可以保存最近一段时间的写命令数据。

③当主从连接恢复后，由于从节点之前保存了自身已复制的偏移量和主节点的运行 ID。因此会把它们当做 psync 参数发送给主节点，要求进行部分复制。

④主节点接收到 psync 命令后首先核对参数 runId 是否与自身一致，如果一致，说明之前复制的是当前主节点。

之后根据参数 offset 在复制积压缓冲区中查找，如果 offset 之后的数据存在，则对从节点发送+COUTINUE 命令，表示可以进行部分复制。因为缓冲区大小固定，若发生缓冲溢出，则进行全量复制。

⑤主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。

上面我们也提到了使用哨兵来监听主节点的存活状态，那么哨兵具体是什么，他又如何进行监听的呢？

## 10.哨兵 ##

首先我们先探讨一下主从复制会遇到哪些问题？

### 10.1 主从复制会存在哪些问题 ###

*  一旦主节点宕机，从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
 *  主节点的写能力受到单机的限制。
 *  主节点的存储能力受到单机的限制。
 *  原生复制的弊端在早期的版本中也会比较突出，比如：Redis 复制中断后，从节点会发起 psync。  
    此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时，可能会造成毫秒或秒级的卡顿。

对于以上问题主流的解决方案就是本章的主题：**哨兵**

### 10.2 哨兵有哪些功能？ ###

Redis Sentinel（哨兵）的架构图如下图所示：  
![在这里插入图片描述][9fb4f403a275473a81d01c0dcc1a7da8.jpeg_pic_center]

Redis Sentinel（哨兵）主要功能包括主节点存活检测、主从运行情况检测、自动故障转移、主从切换。

Redis Sentinel 最小配置是一主一从。Redis 的 Sentinel 系统可以用来管理多个 Redis 服务器。

该系统可以执行以下四个任务：

*  **监控**：不断检查主服务器和从服务器是否正常运行。
 *  **通知**：当被监控的某个 Redis 服务器出现问题，Sentinel 通过 API 脚本向管理员或者其他应用程序发出通知。
 *  **自动故障转移**：当主节点不能正常工作时，Sentinel 会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点，这样人工干预就可以免了。
 *  **配置提供者**：在 Redis Sentinel 模式下，客户端应用在初始化时连接的是 Sentinel 节点集合，从中获取主节点的信息。

### 10.3 哨兵的工作原理 ###

①每个 Sentinel 节点都需要定期执行以下任务：每个 Sentinel 以每秒一次的频率，向它所知的主服务器、从服务器以及其他的 Sentinel 实例发送一个 PING 命令，如下图所示  
![在这里插入图片描述][abbffe407ffc4b018aba25564485cc02.jpeg_pic_center]

②如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 所指定的值，那么这个实例会被 Sentinel 标记为主观下线。如下图所示  
![在这里插入图片描述][15315a2904b647ca8c4bdd02bdecc860.jpeg_pic_center]

③如果一个主服务器被标记为主观下线，那么正在监视这个服务器的所有 Sentinel 节点，要以每秒一次的频率确认主服务器的确进入了主观下线状态。如下图所示  
![在这里插入图片描述][09476b36107e4f3a8fcc78f8b1a87893.jpeg_pic_center]

④如果一个主服务器被标记为主观下线，并且有足够数量的 Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个主服务器被标记为客观下线。如下图所示  
![在这里插入图片描述][3d2ab0975ca24a8782579d891def6c7b.jpeg_pic_center]

⑤一般情况下，每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。

当一个主服务器被标记为客观下线时，Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率，会从 10 秒一次改为每秒一次。如下图所示  
![在这里插入图片描述][e6d7f7e002b34b80895f758ee08d439f.jpeg_pic_center]

⑥Sentinel 和其他 Sentinel 协商客观下线的主节点的状态，如果处于 SDOWN 状态，则投票自动选出新的主节点，将剩余从节点指向新的主节点进行数据复制。

⑦当没有足够数量的 Sentinel 同意主服务器下线时，主服务器的客观下线状态就会被移除。

当主服务器重新向 Sentinel 的 PING 命令返回有效回复时，主服务器的主观下线状态就会被移除。

Redis的原理和常见的问题差不多就这么多了，下面我们在继续讨论一下Redis常见使用场景。

## 11.聊聊 Redis 的 zset ，它是怎么实现的？ ##

zset 是Redis 常用数据类型之一，它的成员是有序排列的，一般用于排行榜类型的业务场景，比如 QQ 音乐排行榜、礼物排行榜等等。

*  它的简单格式举例： zadd key score member \[score  
    member …\]，zrank key member
 *  它的底层内部编码：ziplist（压缩列表）、skiplist（跳跃表）

当 zset 满足以下条件时使用 压 缩 列表：

*  当成员的数量小于128 个；
 *  每个 member （成员）的字符串长度都小于 64 个字节。

压 缩 列表做简单介绍，它由以下五部分组成  
![在这里插入图片描述][151acfb5df82443695cc7886cc7759c1.png_pic_center]

*  zlbytes 是一个无符号整数，表示当前 ziplist 占用的总字节数；
 *  zltail 指的是压缩列表尾部元素相对于压缩列表起始元素的偏移量。
 *  zllen 指 ziplist 中 entry 的数量。当 zllen 比 2^16 - 2 大时，需要完全遍历entry 列表来获取 entry 的总数目。
 *  entry 用来存放具体的数据项（score 和 member），长度不定，可以是字节数组或整数，entry 会根据成员的数量自动扩容。 -zlend 是一个单字节的特殊值，等于 255，起到标识 ziplist 内存结束点的作用。
 *

和 Set 相比，Sorted Set关联了一个 Double 类型权重的参数 Score，使得集合中的元素能够按照 Score 进行有序排列，Redis 正是通过分数来为集合中的成员进行从小到大的排序。

实现方式：Redis Sorted Set 的内部使用 **HashMap** 和**跳跃表**（skipList）来保证数据的存储和有序，HashMap 里放的是成员到 Score 的映射。

而跳跃表里存放的是所有的成员，排序依据是 HashMap 里存的 Score，使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

skiplist（跳跃表）在链表的基础上，增加了**多级索引**，通过索引位置的几个跳转，实现数据的快速定位,其插入、删除、查找的时间复杂度均为 O(logN)。

## 12.Redis的多线程模型怎么理解 ##

Redis在6.0支持的多线程并不是说指令操作的多线程，而是针对于网络IO的一个多线程，也就是说在Redis的命令操作里，它仍然是线程安全的。

同时Redis是直接基于内存操作，其本身的性能瓶颈取决于三个维度：

*  网络带宽
 *  CPU
 *  机器自身的内存

但是真正影响性能的问题是网络和内存，而Redis6.0的多线程本质上是解决网络IO的一个处理效率的问题，在Redis6.0之前，Redis Server端去处理接受客户端请求的时候，Socket连接的建立和指定的数据读取、解析、执行、写回都是由同一个线程来处理的，在这种方式里面呢，客户端请求比较多的时候，单个线程的网络处理效率太慢，导致客户端的请求处理效率非常低，于是在Redis 6.0中对于网络IO的处理方案改成了多线程，通过多线程并行的方式来提升网络IO的处理效率，但是对于客户端指定的执行过程还是采用单线程的方式来执行，值得我们注意的是Redis6.0 里面的多线程默认是关闭的，需要在redis.conf中修改一个叫io-threads-do-reads的配置才能开启。

另外之所以指令执行不使用多线程我认为有两个方面的原因：

*  内存IO的操作本身不存在性能瓶颈，redis在数据结构上已经做了非常非常多的优化 。
 *  如果指令的执行使用了多线程，那么Redis为了解决线程安全问题，需要对数据操作增加锁的同步，不仅仅增加了复杂度，还会影响性能，代价太大 不合算。

## 13.Redis的热key和大value问题 ##

正常情况下，在redis的分布式集群中，数据都是比较均匀的分布在每一个结点上，请求呢也会均匀的分布每一个分片上，但是一些特殊的场景中，比如爬虫，攻击，热点商品等，最典型的就是明星的绯闻，吃瓜群众纷纷去留言，就很容易导致评论的这个功能崩溃，这些短时间内，某些key访问量过大，然后请求到同一台数据分片上，最终会导致该分片不堪重负，最终导致缓存雪崩，进而引发我们的服务雪崩。

怎么检测热key呢？

常规呢就是根据业务以往的数据做一个判定，比如说我们的促销活动，商品秒杀，热门话题等，我们可以写一个方法去判定如果见到某个key的QPS(每秒访问量)达到了1000，此时我们就要注意了，这个key很有可能就是个热key

如何解决热key问题呢？

硬件上我们可以扩容，增加分片，副本多了，自然压力就分担了一些。

还有一种就是使用二级缓存，把热点数据放到我们JVM的本地缓存中，本地缓存可以使用caffeine，ehcache，guava，这样的话就可以将缓存的数据直接读到本地缓存了，当然了你甚至只可以直接将数据直接读到HashMap中，而不需要在去请求redis了，就省去了一个远程的io调用，当然我们也可以使用一些框架，比如说jd-hotkey，它会自动检测我们的热key，并且转为jvm本地缓存。

## 14.redis中的大key如何去处理 ##

redis的大key在我们的线上环境是经常发生的，如果我们不做任何处理直接删除，会对我们的业务造成一些阻塞，严重的会影响我们的整体的一个请求，进而将redis的连接耗尽。

大key对于高并发下的分布式缓存来说是致命的，所以一定要及时处理

### 14.1 什么是redis大key ###

*  String类型的值>10KB
 *  hash,set,list,zset元素个数超过5000个

满足以上条件之一，我们就称它为redis的大key

### 14.2 如何找到大key ###

*  String类型通过命令查找

redis-cli -h 127.0.0.1 -p 6379
    -a 'password' -- bigkeys

上面这个命令会在我们的控制台直接输出大key

*  借助第三方工具：Rdb Tools工具

执行以下命令：

rdb dump.rdb -c memory --bytes 10240 -f redis.csv

通过上面这个命令也可以找到大key

### 14.3 如何删除大key ###

找到大key之后，我们就要对其删除，我们看一下如何删除大key

直接删除大key会造成阻塞，因为redis是单线程执行，阻塞期间其他所有请求都有可能会超时，超时越来越多，最终可能会导致redis的连接耗尽，产生各种异常。

所以我们尽量在低峰期删除，如在凌晨，观察QPS，在QPS小于我们所规定的阈值的时候，在进行删除，该方案无法彻底解决阻塞

我们还可以分批次进行删除：

*  对于hash类型，可以使用hscan扫描
 *  对于集合类型（set），采用srandmember每次随机取数据进行删除
 *  对于zset类型，可以使用zremrangebyrank直接删除
 *  对于list类型，直接pop即可

当然，我们还可以使用异步删除法：用unlink代替del来删除，这样redis会将这个key放入一个异步线程中，进行删除，这种方式不会阻塞线程。

当然了，大key对redis的影响远不止这些，还有对持久化操作的影响，由于篇幅较长，所以我单独拿出来讲解，[《Redis 的大 Key 对持久化有什么影响？》][Redis _ Key]

## 15 4种Redis集群方案及优缺点对比 ##

[https://blog.csdn.net/zhiyikeji/article/details/127499090?spm=1001.2014.3001.5501][https_blog.csdn.net_zhiyikeji_article_details_127499090_spm_1001.2014.3001.5501]

## 16.Redis中有哪些阻塞点以及如何解决 ##

[https://blog.csdn.net/zhiyikeji/article/details/127572678?spm=1001.2014.3001.5501][https_blog.csdn.net_zhiyikeji_article_details_127572678_spm_1001.2014.3001.5501]

## 17.Redis常见的使用场景 ##

![在这里插入图片描述][80788f47b1284773b7e727bb9d09455e.png_pic_center]

### 11.1 缓存 ###

热点数据缓存（例如：报表、明星热点），对象缓存、全页缓存、可以提升热点数据的访问数据。

### 11.2 数据共享分布式 ###

String 类型，因为 Redis 是分布式的独立服务，可以在多个应用之间共享  
例如：分布式 Session

<dependency>
     <groupId>org.springframework.session</groupId>
     <artifactId>spring-session-data-redis</artifactId>
    </dependency>

### 11.3 分布式锁 ###

*  基于 REDIS 的 SETNX()

public static boolean getLock(String key) {
        
        Long flag = jedis.setnx(key, "1");
        if (flag == 1) {
        
            jedis.expire(key, 10);
        }
        return flag == 1;
    }
    
    public static void releaseLock(String key) {
        
        jedis.del(key);
    }

*  基于 REDLOCK 做分布式锁
 *  基于 REDISSON 做分布式锁

### 11.4 全局ID ###

int类型，incrby，利用原子性  
如：分库分表的场景，一次性拿一段

incrby userid 1000

### 11.5 计数器 ###

int类型，incr方法

例如：文章的阅读量、微博点赞数、允许一定的延迟，先写入Redis再定时同步到数据库

### 11.6 限流 ###

int类型，incr方法

以访问者的ip和其他信息作为key，访问一次增加一次计数，超过次数则返回false

### 11.7 位统计 ###

String类型的bitcount

字符是以8位二进制存储的

set k1 a
    setbit k1 6 1
    setbit k1 7 0
    get k1
    /* 
    6 7 代表的a的二进制位的修改
    a 对应的ASCII码是97，转换为二进制数据是01100001
    b 对应的ASCII码是98，转换为二进制数据是01100010
    
    因为bit非常节省空间（1 MB=8388608 bit），可以用来做大数据量的统计。
    */

例如：在线用户统计，留存用户统计

setbit onlineusers 01
    setbit onlineusers 11
    setbit onlineusers 20

支持按位与、按位或等等操作

BITOPANDdestkeykey[key...] ，对一个或多个 key 求逻辑并，并将结果保存到 destkey 。
    BITOPORdestkeykey[key...] ，对一个或多个 key 求逻辑或，并将结果保存到 destkey 。
    BITOPXORdestkeykey[key...] ，对一个或多个 key 求逻辑异或，并将结果保存到 destkey 。
    BITOPNOTdestkeykey ，对给定 key 求逻辑非，并将结果保存到 destkey 。

计算出7天都在线的用户

BITOP "AND" "7_days_both_online_users" "day_1_online_users" 
    "day_2_online_users" ...  "day_7_online_users"

### 11.8 购物车 ###

String 或 hash。所有String可以做的hash都可以做

> key：用户id；field：商品id；value：商品数量。  
> \+1：hincr  
> \-1：hdecr  
> 删除：hdel  
> 全选：hgetall  
> 商品数：hlen

### 11.9 用户消息时间线 timeline ###

list，双向链表，直接作为timeline就好了。插入有序

### 11.10 消息队列 ###

> List提供了两个阻塞的弹出操作：blpop/brpop，可以设置超时时间

blpop：blpop key1 timeout 移除并获取列表的第一个元素，如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。

brpop：brpop key1 timeout 移除并获取列表的最后一个元素，如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。

上面的操作。其实就是java的阻塞队列。

队列：先进先出：rpush blpop，左头右尾，右边进入队列，左边出队列

栈：先进后出：rpush brpop

### 11.11 抽奖 ###

自带一个随机获得值

spop myset

### 11.12 点赞、签到、打卡 ###

![在这里插入图片描述][736274257c964af8b15febb7a4bf159b.png_pic_center]

假如上面的微博ID是t1001，用户ID是u3001

先带大家简单了解一个指令：**sadd**

> 如：sadd A 1 2 3 qqq  
> 表示在A集合中添加了\[1,2,3,qqq\]  
> ![在这里插入图片描述][cdb181fb9af04463a295da3ee35af17a.png_pic_center]

> 再比如：sadd A:1 q w e r  
> ![在这里插入图片描述][83bee3364a1e4f608c6f82dc5e6a77a9.png_pic_center]

> ![在这里插入图片描述][9480f201929240d4bd47dcd46950487c.png_pic_center]

用 like:t1001 来维护 t1001 这条微博的所有点赞用户

*  点赞了这条微博：sadd like:t1001 u3001
 *  取消点赞：srem like:t1001 u3001
 *  是否点赞：sismember like:t1001 u3001
 *  点赞的所有用户：smembers like:t1001
 *  点赞数：scard like:t1001

相比较于数据库的操作，这种方式实现起来更快更简单

### 11.13 商品标签 ###

假如我们用 tags:i5001 来维护商品所有的标签

*  sadd tags:i5001 画面清晰细腻
 *  sadd tags:i5001 真彩清晰显示屏
 *  sadd tags:i5001 流程至极

### 11.14 商品筛选 ###

// 获取差集
    sdiff set1 set2
    
    // 获取交集（intersection ）
    sinter set1 set2
    
    // 获取并集
    sunion set1 set2

我们以iphone14产品上市为例：

sadd brand:apple iPhone14
    
    sadd brand:ios iPhone14
    
    sad screensize:6.0-6.24 iPhone14
    
    sad screentype:lcd iPhone 14

如果我们要实现筛选商品，苹果的、ios的、屏幕在6.0-6.24之间的，屏幕材质是LCD屏幕

sinter brand:apple brand:ios screensize:6.0-6.24 screentype:lcd

### 11.15 用户关注、推荐模型 ###

我们则需要两个列表：

*  列表1：follow：表示自己关注的对象列表
 *  列表2：fans：表示关注自己对象列表

假如有A B C三个用户：  
A关注了B：

sadd A:follow B
    sadd B:fans A

![在这里插入图片描述][7c64ead3ed4e4bd9926ae8052e4fcf1f.png_pic_center]

B关注C

sadd B:follow C
    sadd C:fans B

### 11.16 排行榜 ###

如：实现id 为6001 的新闻点击数加1：

zincrby hotNews:20220613 1 n6001

![在这里插入图片描述][1de3f2e7b787491a862c0f9e91e41b24.png_pic_center]

获取今天点击最多的15条：  
自己可以用上面的指令在多弄几条新闻id

zrevrange  hotNews:20220613 0 15 withscores

![在这里插入图片描述][2e29666daaea469f97ec9d8df997b63c.png_pic_center]

[8ce738d75960407dacd8067b08090bb3.jpeg_pic_center]: https://img-blog.csdnimg.cn/8ce738d75960407dacd8067b08090bb3.jpeg#pic_center
[3911ada840d741608261049fc2316cab.png_pic_center]: https://img-blog.csdnimg.cn/3911ada840d741608261049fc2316cab.png#pic_center
[4f7a45ce951144279df6705cf316b80a.png_pic_center]: https://img-blog.csdnimg.cn/4f7a45ce951144279df6705cf316b80a.png#pic_center
[d9b1781fd37c4098af267b515fdf69c8.png_pic_center]: https://img-blog.csdnimg.cn/d9b1781fd37c4098af267b515fdf69c8.png#pic_center
[Link 1]: https://blog.csdn.net/zhiyikeji/article/details/123940351
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]: https://img-blog.csdnimg.cn/ff1f01221c3f4559b78d9eadfde51146.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAWk5pbmVTdW4=,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center
[mysql]: https://blog.csdn.net/zhiyikeji/article/details/121970369
[1d915d75fb654c0abc8feb6aaa9d3e6e.png_pic_center]: https://img-blog.csdnimg.cn/1d915d75fb654c0abc8feb6aaa9d3e6e.png#pic_center
[a0da85df1d854534a0d6a8f3d6b6cd9b.jpeg_pic_center]: https://img-blog.csdnimg.cn/a0da85df1d854534a0d6a8f3d6b6cd9b.jpeg#pic_center
[500a57605f85421fb1d82896f9bbb799.jpeg_pic_center]: https://img-blog.csdnimg.cn/500a57605f85421fb1d82896f9bbb799.jpeg#pic_center
[9fb4f403a275473a81d01c0dcc1a7da8.jpeg_pic_center]: https://img-blog.csdnimg.cn/9fb4f403a275473a81d01c0dcc1a7da8.jpeg#pic_center
[abbffe407ffc4b018aba25564485cc02.jpeg_pic_center]: https://img-blog.csdnimg.cn/abbffe407ffc4b018aba25564485cc02.jpeg#pic_center
[15315a2904b647ca8c4bdd02bdecc860.jpeg_pic_center]: https://img-blog.csdnimg.cn/15315a2904b647ca8c4bdd02bdecc860.jpeg#pic_center
[09476b36107e4f3a8fcc78f8b1a87893.jpeg_pic_center]: https://img-blog.csdnimg.cn/09476b36107e4f3a8fcc78f8b1a87893.jpeg#pic_center
[3d2ab0975ca24a8782579d891def6c7b.jpeg_pic_center]: https://img-blog.csdnimg.cn/3d2ab0975ca24a8782579d891def6c7b.jpeg#pic_center
[e6d7f7e002b34b80895f758ee08d439f.jpeg_pic_center]: https://img-blog.csdnimg.cn/e6d7f7e002b34b80895f758ee08d439f.jpeg#pic_center
[151acfb5df82443695cc7886cc7759c1.png_pic_center]: https://img-blog.csdnimg.cn/151acfb5df82443695cc7886cc7759c1.png#pic_center
[Redis _ Key]: https://blog.csdn.net/zhiyikeji/article/details/127242746?spm=1001.2014.3001.5501
[https_blog.csdn.net_zhiyikeji_article_details_127499090_spm_1001.2014.3001.5501]: https://blog.csdn.net/zhiyikeji/article/details/127499090?spm=1001.2014.3001.5501
[https_blog.csdn.net_zhiyikeji_article_details_127572678_spm_1001.2014.3001.5501]: https://blog.csdn.net/zhiyikeji/article/details/127572678?spm=1001.2014.3001.5501
[80788f47b1284773b7e727bb9d09455e.png_pic_center]: https://img-blog.csdnimg.cn/80788f47b1284773b7e727bb9d09455e.png#pic_center
[736274257c964af8b15febb7a4bf159b.png_pic_center]: https://img-blog.csdnimg.cn/736274257c964af8b15febb7a4bf159b.png#pic_center
[cdb181fb9af04463a295da3ee35af17a.png_pic_center]: https://img-blog.csdnimg.cn/cdb181fb9af04463a295da3ee35af17a.png#pic_center
[83bee3364a1e4f608c6f82dc5e6a77a9.png_pic_center]: https://img-blog.csdnimg.cn/83bee3364a1e4f608c6f82dc5e6a77a9.png#pic_center
[9480f201929240d4bd47dcd46950487c.png_pic_center]: https://img-blog.csdnimg.cn/9480f201929240d4bd47dcd46950487c.png#pic_center
[7c64ead3ed4e4bd9926ae8052e4fcf1f.png_pic_center]: https://img-blog.csdnimg.cn/7c64ead3ed4e4bd9926ae8052e4fcf1f.png#pic_center
[1de3f2e7b787491a862c0f9e91e41b24.png_pic_center]: https://img-blog.csdnimg.cn/1de3f2e7b787491a862c0f9e91e41b24.png#pic_center
[2e29666daaea469f97ec9d8df997b63c.png_pic_center]: https://img-blog.csdnimg.cn/2e29666daaea469f97ec9d8df997b63c.png#pic_center