• Rides手册
  • 基础面试题
    • 什么是redis?
    • Reids的特点
    • Rides得优缺点
    • Redis 的应用场景
    • 使用redis有哪些好处？
    • Redis数据类型
      • String 类型
      • Hash 类型
      • List 类型
      • Set 类型
      • ZSet 类型
    • 缓存有那些类型
      • 本地缓存
      • 分布式缓存
      • 多级缓存
    • 你为什么需要使用Rides
    • 为什么redis需要把所有数据放到内存中?
    • 缓存数据淘汰算法
      • 不可能实现的算法 OPT
      • 无脑算法 FIFO
      • 常见算法 LRU
      • LFU算法
    • Redis内存维护策略
      • 为数据设置超时时间
      • 采用 LRU 算法动态将不用的数据删除
    • Redis是单线程还是多线程？Redis为什么这么快？
    • Rides中得高级数据类型
    • Memcache和Rides对比
      • Memcache
      • Redis
      • 两者对比
    • 为什么要用 redis 而不用 map/guava 做缓存?
    • Rides有那些数据结构
    • 如果有大量的key需要设置同一时间过期，一般需要注意什么？
    • 使用过Redis分布式锁么，它是什么回事？
    • 假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如何将它们全部找出来？
    • 如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？
    • 使用过Redis做异步队列么，你是怎么用的？
    • Redis是怎么持久化的？服务主从数据怎么交互的？
    • 那如果突然机器掉电会怎样？
    • RDB的原理是什么？
    • Redis 持久化
      • 什么是 Redis 持久化？
      • RDB
      • AOF
    • Redis的同步机制了解么？
    • 是否使用过Redis集群，集群的高可用怎么保证，集群的原理是什么？
    • Redis雪崩了解么？
    • 缓存穿透
  • 如何解决上面遇到的问题
    • 缓存击穿
    • Rides为什么那么快
    • 既然提到了单机会有瓶颈，那你们是怎么解决这个瓶颈的？
    • 他们之间是怎么进行数据交互的？以及Redis是怎么进行持久化的？Redis数据都在内存中，一断电或者重启不就没有了嘛？
    • 那这两种机制各自优缺点是啥？
      • 优点：
      • 缺点：
      • 优点：
      • 缺点：
    • 那两者怎么选择？
    • 你提到了高可用，Redis还有其他保证集群高可用的方式么？
    • 能说一下主从之间的数据怎么同步的么？
    • 数据传输的时候断网了或者服务器挂了怎么办啊？
    • 那说了这么多你能说一下他的内存淘汰机制么，来手写一下LRU代码？
    • 为啥不扫描全部设置了过期时间的key呢？
    • 如果一直没随机到很多key，里面不就存在大量的无效key了？
    • 键的过期删除策略
    • 最后就是如果的如果，定期没删，我也没查询，那可咋整？
    • redis的并发竞争问题如何解决?
    • redis常见性能问题和解决方案
    • Redis主从架构中数据丢失吗
      • 集群产生脑裂：
    • 如何解决主从架构数据丢失问题？
    • Redis高可用方案如何实现？
    • 什么是Redis的事务
    • Redis事务的相关命令
    • Redis事务执行的三个阶段
    • Redis事务的特性
    • Redis事务为什么不支持回滚？
    • Rides是单线程的还是多线程的
      • 为什么在最开始Rides被设计为单线程
      • 多线程的使用场景
      • 多线程的弊端
      • Rides多路复用
      • 为什么Redis 6.0 引入多线程
    • 如何保证缓存与数据库双写时的数据一致性？
      • 先更新数据库，后删除缓存
      • 先删除缓存，后更新数据库
    • Redis 缓存雪崩、缓存击穿、缓存穿透
      • 缓存雪崩
      • 缓存击穿
      • 缓存穿透
    • Redis 事务
      • 事务简介
      • 常用命令
      • Redis 事务总结

Rides手册

基础面试题

什么是redis?

redis是一个高性能的key-value数据库，它是完全开源免费的，而且redis是一个NOSQL类型数据库，是为了解决高并发、高扩展，大数据存储等一系列的问题而产生的数据库解决方案，是一个非关系型的数据库

Reids的特点

Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。

因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。

Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。

另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的memcached来用。

Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

String类型：一个String类型的value最大可以存储512M

List类型：list的元素个数最多为2^32-1个，也就是4294967295个。

Set类型：元素个数最多为2^32-1个，也就是4294967295个。

Hash类型：键值对个数最多为2^32-1个，也就是4294967295个。

Sorted set类型：跟Set类型相似。

面试回答

• 性能极高 - Redis 读速度 110000次/s，写的速度是 81000次/s。
• 丰富的数据类型 - Redis 支持的类型 String， Hash 、List 、Set 及 Ordered Set 数据类型操作。
• 原子性 - Redis 的所有操作都是原子性的，意思就是要么成功，要么失败。
  • 单个操作时原子性的，多个操作也支持事务，即原子性，通过 MULTI 和 EXEC 指令包起来。
• 丰富的特性 - Redis 还支持 publis/subscribe，通知，key 过期等等特性。
• 高速读写 ，redis 使用自己实现的分离器，代码量很短，没有使用 lock(MySQL),因此效率非常高

Rides得优缺点

优点：

• 读写性能好，读的速度可达110000次/s，写的速度可达81000次/s。
• 支持数据持久化，有AOF和RDB两中持久化方式
• 数据结构丰富，支持String、List、Set、Hash等结构
• 支持事务，Redis所有的操作都是原子性的，并且还支持几个操作合并后的原子性执行，原子性指操作要么成功执行，要么失败不执行，不会执行一部分。
• 支持主从复制，主机可以自动将数据同步到从机，进行读写分离。

缺点：

• 因为Redis是将数据存到内存中的，所以会受到内存大小的限制，不能用作海量数据的读写
• Redis不具备自动容错和恢复功能，主机或从机宕机会导致前端部分读写请求失败，需要重启机器或者手动切换前端的IP才能切换
• 持久化：Redis 直接将数据存储到内存中，要将数据保存到磁盘上，Redis 可以使用两种方式实现持久化过程。
  • 定时快照(snapshot)：每隔一段时间将整个数据库写到磁盘上，每次均是写全部数据，代价非常高。
  • 第二种方式基于语句追加（aof）：只追踪变化的数据，但是追加的 log 可能过大，同时所有的操作均重新执行一遍，回复速度慢。
• 耗内存 、占用内存过高。

Redis 的应用场景

可以作为数据库，缓存热点数据(经常被查询，但是不经常被修改或者删除的数据)和消息中间件等大部分功能。

Redis 常用的场景示例如下：

1、缓存

缓存现在几乎是所有大中型网站都在用的必杀技，合理利用缓存提升网站的访问速度，还能大大降低数据库的访问压力。Redis 提供了键过期功能，也提供了灵活的键淘汰策略，所以，现在 Redis 用在缓存的场合非常多。

2、排行榜

Redis 提供的有序集合数据类结构能够实现复杂的排行榜应用。

3、计数器

视频网站的播放量，每次浏览 +1，并发量高时如果每次都请求数据库操作无疑有很大挑战和压力。Redis 提供的 incr 命令来实现计数器功能，内存操作，性能非常好，非常适用于这些技术场景。

4、分布式会话

相对复杂的系统中，一般都会搭建 Redis 等内存数据库为中心的 session 服务，session 不再由容器管理，而是由 session 服务及内存数据管理。

5、分布式锁

在并发高的场合中，可以利用 Redis 的 setnx 功能来编写分布式的锁，如果设置返回 1，说明获取锁成功，否则获取锁失败。

6、社交网络

点赞、踩、关注/被关注，共同好友等是社交网站的基本功能，社交网站的访问量通常来说比较大，而且传统的关系数据库不适合这种类型的数据，Redis 提供的哈希，集合等数据结构能很方便的实现这些功能。

7、最新列表

Redis 列表结构，LPUSH 可以在列表头部插入一个内容 ID 作为关键字，LTRIM 可以用来限制列表的数量，这样列表永远为 N ，无需查询最新的列表，直接根据 ID 去到对应的内容也即可。

8、消息系统

消息队列是网站经常用的中间件，如 ActiveMQ，RabbitMQ，Kafaka 等流行的消息队列中间件，主要用于业务解耦，流量削峰及异步处理试试性低的业务。Redis 提供了发布/订阅及阻塞队列功能，能实现一个简单的消息队列系统。另外，这个不能和专业的消息中间件相比。

使用redis有哪些好处？

速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)

支持丰富数据类型，支持string，list，set，sorted set，hash

Redis数据类型

String 类型

String 类型是 Redis 最基本的数据类型，一个键最大能存储 512 MB。

String 数据结构是最简单的 key-value 类型，value 既可以是 string，也可以是数字，是包含很多种类型的特殊类型。

String 类型是二进制安全的。意思是 redis 的 string 可以包含任何数据。

比如序列化的对象进行存储，比如一张图片进行二进制存储，比如一个简单的字符串，数值等等。

String 命令

1、复制语法：

 SET KEY_NAME VALUE : (说明：多次设置 name 会覆盖)
  (Redis SET 命令用于设置给定 key 的值。如果 key 已经存储值，SET 就要写旧值，且无视类型)。
  
2、命令：

SETNX key1 value：(not exist) 如果 key1 不存在，则设置 并返回1。
如果 key1 存在，则不设置并返回 0;

(解决分布式锁  方案之一，只有在 key 不存在时设置 key 的值。
setnx (SET if not exits)命令在指定的key不存在时，为key设置指定的值)。

SETEX key1 10 lx :(expired)设置 key1 的值为 lx ,过期时间为 10 秒，10 秒后 key1 清除（ key 也清除）

SETEX key1 10 lx :(expired) 设置 key1 的值为 lx，过期时间为 10 秒，10 秒后 key1 清除(key 也清除)

SETRANG STRING range value : 替换字符串

3、取值语法：

GET KEY_NAME : Redis GET 命令用于获取指定 key 的值。
如果 key 不存在，返回 nil。如果key存储的值不是字符串类型，返回一个错误。

GETRANGE  key start end : 用于获取存储在指定key中字符串的子字符串。
字符串的截取范围由 start 和 end 两个偏移量来决定(包括 start 和 end 在内)

GETBIT key offset ：对 key 所存储的字符串值，获取指定偏移量上的为(bit)；
GETTEST语法 ：GETSET KEY_NAME VALUE : GETSET 命令用于设置指定 key 的值，并返回key的旧值。当 key 不存在是，返回 null

STRLEN key :返回 key 所存储的字符串值的长度

4、删除语法：

DEL KEY_NAME : 删除指定的key，如果存在，返回数字类型。

5、批量写：MSET K1 V1 K2 V2 ... (一次性写入多个值)

6、批量读：MGET K1 K2 K3


7、GETSET NAME VALUE : 一次性设置和读取(返回旧值，写上新值)

8、自增/自减：

INCR KEY_Name : Incr 命令将key中存储的数组值增1。
如果 key 不存在，那么key的值会先被初始化为0，然后在执行INCR操作

自增:INCRBY KEY_Name ：增量值Incrby 命令将key中存储的数字加上指定的增量值
自减：DECR KEY_Name 或 DECYBY KEY_NAME 减值：DECR 命令将key中存储的数字减少1

：(注意这些key对应的必须是数字类型字符串，否则会出错。)

字符串拼接：APPEND  KEY_NAME VALUE
:Append 命令用于为指定的key追加至末尾，如果不存在，为其赋值

字符串长度 ：STRLEN key
    
##########################    
 setex   (set with expire) #设置过期时间
 setnx   (set if not exist) #不存在设置 在分布式锁中会常常使用！

string 应用场景

• 1、String通常用于保存单个字符串或JSON字符串数据
• 2、因String是二进制安全的，所以你完全可以把一个图片文件的内容作为字符串来存储
• 3、计数器(常规 key-value 缓存应用。常规计数：微博数，粉丝数)

Hash 类型

Hash 类型是 String 类型的 field 和 value 的映射表，或者说是一个 String 集合。hash 特别适合用于存储对象，相比较而言，将一个对象类型存储在 Hash 类型比存储在 String 类型里占用更少的内存空间，并对整个对象的存取。可以看成具有 KEY 和 VALUE 的 MAP 容器，该类型非常适合于存储值对象的信息。

如：uname,upass,age 等。该类型的数据仅占用很少的磁盘空间(相比于 JSON ).

Redis 中每一个 hash 可以存储 2 的 32 次方 -1 键值对(40 多亿)

Hash 命令

常用命令

1、赋值语法：
 1、 HSET KEY FIELD VALUE   ： 为指定的 KEY,设定 FILD/VALUE
 2、 HMSET KEY FIELD VALUE [FIELD1，VALUE]... : 同时将多个 field-value(域-值)对设置到哈希表 key 中。

2、取值语法：

    HGET KEY FIELD  :获取存储在HASH中的值，根据 FIELD 得到 VALUE
    HMGET KEY FIELD [FIELD1]   :获取 key 所有给定字段的值
    HGETALL KEY     :返回 HASH 表中所有的字段和值
        
 HKEYS KEY : 获取所有哈希表中的字段
 HLEN  KEY : 获取哈希表中字段的数量

3、删除语法：
     HDEL KEY FIELD[FIELD2]  :删除一个或多个 HASH 表字段
 
4、其它语法：
     HSETNX KEY FIELD VALUE : 只有在字段 field 不存在时，设置哈希表字段的值
     
     HINCRBY KEY FIELD INCREMENT :为哈希 key 中的指定字段的整数值加上增量 increment。
         
     HINCRBYFLOAT KEY FIELD INCREMENT  :为哈希表 key 中的指定字段的浮点数值加上增量 increment
         
     HEXISTS KEY FIELD  : 查看哈希表中 key 中，指定的字段是否存在

Hash 的应用场景 ：(存储一个用户信息对象数据)

• 常用于存储一个对象

• 为什么不用 string 存储一个对象

  hash 值最接近关系数据库结构的数据类型，可以将数据库一条记录或程序中一个对象转换成 hashmap 存放在 redis 中。

  用户 ID 为查找的 key，存储的 value 用户对象包含姓名，年龄，生日等信息，如果用普通的 key/value 结构来存储，主要有以下 2 种方式：

第一种方式将用户 ID 作为查找 key，把其他信息封装成为一个对象以序列化的方式存储，这种方式增加了序列化/反序列化的开销，并且在需要修改其中一项信息时，需要把整个对象取回，并且修改操作需要对并发进行保护，引入 CAS 等复杂问题。

第二种方法是这个用户信息对象有多少成员就存成多少个 key-value 对，用用户 ID+ 对应属性的名称作为唯一标识来取的对应属性的值，虽然省去了序列化开销和并发问题，但是用户ID 重复存储，如果存在大量这样的数据，内存浪费还是非常可观的。

Redis 提供的 Hash 很好的解决了这个问题，Redis 的 Hash 实际内部存储的 Value 为一个 HashMap。

List 类型

List 类型是一个链表结构的集合，其主要功能有 push、pop、获取元素等。更详细的说，List 类型是一个双端链表的结构，我们可以通过相关的操作进行集合的头部或者尾部添加和删除元素，List 的设计是非常简单精巧，既可以为栈，又可以作为队列，满足绝大多数的需求。

常用命令

1、赋值语法： 
 LPUSH KEY VALUE1 [VALUE2] :将一个或多个值插入到列表头部（从左侧添加）
    RPUSH KEY VALUE1 [VALUE2] ：在列表中添加一个或多个值（从有侧添加）
 LPUSHX KEY VAKUE :将一个值插入到已存在的列表头部。如果列表不在，操作无效
 RPUSHX KEY VALUE :一个值插入已经在的列表尾部（最右边）。如果列表不在，操作无效
2、取值语法：
 LLEN KEY   :获取列表长度
    LINDEX KEY INDEX :通过索引获取列表中的元素
 LRANGE KEY START STOP :获取列表指定范围内的元素

描述：返回列表中指定区间的元素，区间以偏移量 START 和 END 指定。

其中 0 表示列表的第一个元素，1 表示列表的第二个元素，以此类推。。。

也可以使用负数下标，以 -1 表示列表的最后一个元素，-2 表示列表的倒数第二个元素，依次类推

start：页大小（页数-1）

stop：（页大小页数）-1

3、删除语法：
 LPOP KEY 移除并获取列表的第一个元素（从左侧删除）
 RPOP KEY 移除列表的最后一个元素，返回值为移除的元素（从右侧删除）

 BLPOP key1 [key2]timeout 移除并获取列表的第一个元素，如果列表没有元素会阻塞列表知道等待超时或发现可弹出元素为止。
4、修改语法：
 LSET KEY INDEX VALUE :通过索引设置列表元素的值
 LINSERT KEY BEFORE|AFTER WORIL VALUE ：在列表的元素前或者后 插入元素 描述：将值 value 插入到列表 key 当中，位于值 world 之前或之后。

高级命令

高级语法：
 RPOPLPUSH source destiation : 移除列表的最后一个元素，并将该元素添加到另外一个列表并返回
 示例描述：
  RPOPLPUSH a1  a2  : a1的最后元素移到a2的左侧
  RPOPLPUSH a1  a1  ： 循环列表，将最后元素移到最左侧
   BRPOPLPUSH source destination timeout  :从列表中弹出一个值，将弹出的元素插入到另外一个列表中并返回它；
如果列表没有元素会阻塞列表知道等待超时或发现可弹出的元素为止。

List 的应用场景

项目应用于：1、对数据量大的集合数据删除；2、任务队列

1、对数据量大的集合数据删减

列表数据显示，关注列表，粉丝列表，留言评论等.....分页，热点新闻等

利用 LRANG 还可以很方便的实现分页的功能，在博客系统中，每篇博文的评论也可以存入一个单独的 list 中。

2、任务队列

(list 通常用来实现一个消息队列，而且可以确认表先后顺序，不必像 MySQL 那样还需要通过 ORDER BY 来进行排序)

任务队列介绍(生产者和消费者模式：)

    在处理 web 客户端发送的命令请求时，某些操作的执行时间可能会比我们预期的更长一些，通过将待执行任
  务的相关信息放入队列里面，并在之后队列进行处理，用户可以推迟执行那些需要一段时间才能完成的操作，
  这种将工作交个任务处理器来执行的做法被称为任务队列（task queue）。
    
RPOPLPUSH source destination

 移除列表的最后一个元素，并将该元素添加到另一个列表并返回

Set 类型

Redis 的 Set 是 String 类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。Redis 中集合是通过哈希表实现的，set 是通过 hashtable 实现的

集合中最大的成员数为 2^32 -1,类似于 JAVA 中的 Hashtable 集合。

命令

1、复制语法：
    SADD KEY member1 [member2]:向集合添加一个或多个成员
    
2、取值语法：
    SCARD KEY :获取集合的成员数
    SMEMBERS KEY ：返回集合中的所有成员
    SISMEMBER  KEY  MEMBER  :判断 member 元素是否是集合 key 的成员(开发中：验证是否存在判断)
    SRANDMEMBER KEY [COUNT] :返回集合中一个或对个随机数
        
3、删除语法：
      SREM key member1 [member2] : 移除集合中一个或多个成员
      SPOP key [count] : 移除并返回集合中的一个随机元素
      SMOVE source destination member :将member 元素从Source集合移动到destination集合中

4、差集语言：
   SDIFF  key1  [key2]  :返回给定所有集合的差集
   SDIFFSTORE destination key1 [key2]  :返回给定所有集合的茶几并存储在destination中

5、交集语言：          
    SUNION key1 [key2] : 返回所有给定集合的并集
    SUNIONSTORE destination key1 [key2] :所有给定集合的并集存储在 destinatiion集合中

ZSet 类型

有序集合(sorted set)

简介

1、Redis 有序集合和集合一样也是 string 类型元素的集合，且不允许重复的成员。

2、不同的是每个元素都会关联一个 double 类型的分数。redis 正是通过分数来为集合中的成员进行从小到大的排序。

3、有序集合的成员是唯一的，但分数（score）却可以重复。

4、集合是通过哈希表实现的。集合中最大的成员数为 2^32 -1。Redis 的 ZSet 是有序，且不重复。

（很多时候，我们都将 redis 中的有序结合叫做 zsets，这是因为在 redis 中，有序集合相关的操作指令都是以 z 开头的）

命令

1、复制语法：
 ZADD KEY score1 member1 【score2 member2】  ：向有序集合添加一个或多个成员，或者更新已经存在成员的分数

2、取值语法：
 ZCARD key ：获取有序结合的成员数
    ZCOUNT key min max :计算在有序结合中指定区间分数的成员数
###############################################################
127.0.0.1:6379> ZADD kim 1 tian
(integer) 0
127.0.0.1:6379> zadd kim 2 yuan 3 xing
(integer) 2
127.0.0.1:6379> zcount kim 1 2
(integer) 2
127.0.0.1:6379> 
###############################################################
    ZRANK  key member  :返回有序集合中指定成员的所有
    ZRANGE KEY START STOP  [WITHSCORES]:通过索引区间返回有序集合成指定区间内的成员(低到高)
 ZRANGEBYSCORE KEY MIN MAX [WITHSCORES] [LIMIT] :通过分数返回有序集合指定区间内的成员
 ZREVRANGE KEY START STOP [WITHSCORES] :返回有序集中是定区间内的成员，通过索引，分数从高到底
 ZREVERANGEBYSCORE KEY MAX MIN [WITHSCORES] :返回有序集中指定分数区间的成员，分数从高到低排序

删除语法：
 DEL KEY   : 移除集合
 ZREM key member [member...] 移除有序集合中的一个或多个成员
 ZREMRANGEBYSCORE KEY MIN MAX  :移除有序集合中给定的分数区间的所有成员。
 ZREMRANGEBYSCORE KEY MIN MAX  :移除有序集合中给定的分数区间的所有成员。
 
ZINCRBY KEY INCREMENT MEMBER :增加 member 元素的分数 increment，返回值是更改后的分数

HyperLogLog

常用命令

PFADD key element [element ...] : 添加指定元素到 HyperLoglog 中

PFCOUNT KEY [key ...] :返回给定 HyperLogLog的基数估算值

PFMERGE destkey sourcekey [sourcekey ...] :将过个HyperLogLog 合并为一个HyperLoglog

应用场景

基数不大，数据量不大就用不上，会有点大材小用浪费空间

有局限性，就是指能统计基数数量，而没办法去知道具体的内容是什么

统计注册 IP 数
统计每日访问 IP 数
统计页面实时 UV 数
统计在线用户数
统计用户每天搜索不同词条的个数
统计真实文章阅读数

缓存有那些类型

缓存是高并发场景下提高热点数据访问性能的一个有效手段，在开发项目时会经常使用到。

缓存的类型分为：

• 本地缓存：通常使用HashMap
• 分布式缓存:Rides数据库
• 多级缓存

本地缓存

本地缓存就是在进程的内存中进行缓存，比如我们的 JVM 堆中，可以用 LRUMap 来实现，也可以使用 Ehcache 这样的工具来实现。

本地缓存是内存访问，没有远程交互开销，性能最好，但是受限于单机容量，一般缓存较小且无法扩展。

分布式缓存

分布式缓存可以很好得解决这个问题。

分布式缓存一般都具有良好的水平扩展能力，对较大数据量的场景也能应付自如。

缺点就是需要进行远程请求，性能不如本地缓存。

多级缓存

为了平衡这种情况，实际业务中一般采用多级缓存，本地缓存只保存访问频率最高的部分热点数据，其他的热点数据放在分布式缓存中。

在目前的一线大厂中，这也是最常用的缓存方案，单考单一的缓存方案往往难以撑住很多高并发的场景。

你为什么需要使用Rides

这里回答在实时数仓中为什么使用Rides缓存。

因为我们在做实时计算的时候，数据一般是存储在Hbase数据库中，向一些维度表，如果我们实时计算的时候，需要使用维度表，如果这个时候取Hbase数据库中查询数据的时候，他是基于mr计算模型的，延迟很高，而我们实时计算需要低延迟，所以这个时候就不得不考虑使用一个缓存，将一些热点数据存储在缓存中，这样效率更高。

为什么redis需要把所有数据放到内存中?

Redis为了达到最快的读写速度将数据都读到内存中，并通过异步的方式将数据写入磁盘。所以redis具有快速和数据持久化的特征。如果不将数据放在内存中，磁盘I/O速度为严重影响redis的性能。在内存越来越便宜的今天，redis将会越来越受欢迎。

如果设置了最大使用的内存，则数据已有记录数达到内存限值后不能继续插入新值。

缓存数据淘汰算法

不管是本地缓存还是分布式缓存，为了保证较高性能，都是使用内存来保存数据，由于成本和内存限制，当存储的数据超过缓存容量时，需要对缓存的数据进行剔除。

不可能实现的算法 OPT

OPT（OPTimal Replacement，OPT）算法，其所选择的被淘汰的数据将是以后永不使用的，或是在最长（未来）时间内不再被访问的数据。

未来发生的事情是无法预测的，所以该算法从根本上来说是无法实现的，OPT算法对于内存缓存来说，能够提供最高的cache命中（cache hite）率，通过OPT算法也可以衡量其他缓存淘汰的算法的优劣。

无脑算法 FIFO

FIFO（First Input First Output，FIFO）算法算是一种很无脑的淘汰算法，实现起来也很简单，即每次淘汰最先被缓存的数据。

FIFO算法很少会应用在实际项目中，因为该算法并未考虑数据的 “热度”，一般来说，应该是越热的数据越应该晚点淘汰出去，而FIFO算法并未考虑到这一点，所以，该算法的cache命中率一般会比较低。

常见算法 LRU

LRU（Least Recently Used，LRU）算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。

LRU最友好的数据模型为具有时间局部性的请求队列，每访问一个已缓存的节点，就将该节点转移到队列头部，每次淘汰时，以此淘汰队列尾部节点

采用队列实现的话，每转移一个节点，都需要遍历该队列，为了提高查找效率，通常会采用Hashmap+双向链表来实现LRU算法。

使用双向链表记录访问的时间，因为链表的插入效率比较高，所以新插入的元素在前面，旧的数据存储在后面，使用哈希表记录缓存（key,value)，哈希表的查找效率近似于o(1)，发生冲突最坏查询效率也是o(n)，同时哈希表中得记录 (key, (value, key_ptr))，key_ptr 是key在链表中的地址，为了能在O(1)时间内找到该节点，并把节点提升到表头。链表中的key，能快速找到hash中的value，并删除。

LFU算法

为了解决LRU算法未考虑频率因素的问题，人们在此基础上又提出了LRU-K算法，其中，K代表最近使用的次数，因此LRU可以认为是LRU-1算法，其核心思想是将 “最近使用过1次”的判断标准扩展为“最近使用过K次”。

相比LRU，LRU-K需要多维护一个访问历史队列，用于记录所有缓存数据被访问的历史。只有当数据的访问次数达到K次的时候，才将数据放入缓存。当需要淘汰数据时，LRU-K会淘汰第K次访问时间距当前时间最大的数据。

LFU算法是LRU算法的改进

LRU对于循环出现的数据，缓存命中不高
比如，这样的数据，1，1，1，2，2，2，3，4，1，1，1，2，2，2.....
当走到3，4的时候，1，2会被淘汰掉，但是后面还有很多1，2

LFU对于交替出现的数据，缓存命中不高
比如，1，1，1，2，2，3，4，3，4，3，4，3，4，3，4，3，4......
由于前面被（1(3次)，2(2次)）
3加入把2淘汰，4加入把3淘汰，3加入把4淘汰，然而3，4才是最需要缓存的，1去到了3次，谁也淘汰不了它了。

一般的剔除策略有 FIFO 淘汰最早数据、LRU 剔除最近最少使用、和 LFU 剔除最近使用频率最低的数据几种策略。

• noeviction:返回错误，当内存限制达到并且客户端尝试执行会让更多内存被使用的命令（大部分的写入指令，但DEL和几个例外）

• allkeys-lru: 尝试回收最少使用的键（LRU），使得新添加的数据有空间存放。

• volatile-lru: 尝试回收最少使用的键（LRU），但仅限于在过期集合的键,使得新添加的数据有空间存放。

• allkeys-random: 回收随机的键使得新添加的数据有空间存放。

• volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。

• volatile-ttl: 回收在过期集合的键，并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放

如果没有键满足回收的前提条件的话，策略volatile-lru, volatile-random以及volatile-ttl就和noeviction 差不多了。

Redis内存维护策略

redis 作为优秀的中间缓存件，时常会存储大量的数据，即使采取了集群部署来动态扩容，也应该及时的整理内存，维持系统性能。

在 redis 中有两种解决方案

为数据设置超时时间

//设置过期时间
expire key time(以秒为单位)--这是最常用的方式
setex(String key, int seconds, String value) --字符串独有的方式

1、除了字符串自己独有设置过期时间的方法外，其他方法都需要依靠 expire 方法来设置时间
2、如果没有设置时间，那缓存就是永不过期
3、如果设置了过期时间，之后又想让缓存永不过期没使用persist key

采用 LRU 算法动态将不用的数据删除

内存管理的一种页面置换算法，对于在内存中但又不用的数据块(内存块)叫做 LRU，
操作系统会根据哪些数据属于 LRU 而将其移除内存而腾出空间来加载另外的数据。

1.volatile-lru：设定超时时间的数据中，删除最不常使用的数据

2.allkeys-lru：查询所有的 key 对最近最不常使用的数据进行删除，这是应用最广泛的策略。

3.volatile-random：在已经设定了超时的数据中随机删除。

4.allkeys-random：查询所有的 key，之后随机删除。

5.volatile-ttl：查询全部设定超时时间的数据，之后排序，将马上要过期的数据进行删除操作。

6.noeviction：如果设置为该属性，则不会进行删除操作，如果内存溢出则报错返回。

7.volatile-lfu：从所有配置了过期时间的键中驱逐使用频率最少的键

8.allkeys-lfu：从所有键中驱逐使用频率最少的键

Redis是单线程还是多线程？Redis为什么这么快？

Redis6.0之前是单线程的，为什么Redis6.0之前采用单线程而不采用多线程呢？

简单来说，就是Redis官方认为没必要，单线程的Redis的瓶颈通常在CPU的IO，而在使用Redis时几乎不存在CPU成为瓶颈的情况。使用Redis主要的瓶颈在内存和网络，并且使用单线程也存在一些优点，比如系统的复杂度较低，可为维护性较高，避免了并发读写所带来的一系列问题。

Redis为什么这么快主要有以下几个原因：

• 运行在内存中
• 数据结构简单
• 使用多路IO复用技术
• 单线程实现，单线程避免了线程切换、锁等造成的性能开销。

Rides中得高级数据类型

Bitmap：位图，是一个以位为单位的数组，数组中只能存储1或0，数组的下标在Bitmap中叫做偏移量。Bitmap实现统计功能，更省空间。

面试中常问的布隆过滤器就有用到这种数据结构，布隆过滤器可以判断出哪些数据一定不在数据库中，所以常被用来解决Redis缓存穿透问题。

Memcache和Rides对比

Memcache

注意后面会把 Memcache 简称为 MC。

先来看看 MC 的特点：

• MC 处理请求时使用多线程异步 IO 的方式，可以合理利用 CPU 多核的优势，性能非常优秀；
• MC 功能简单，使用内存存储数据；
• MC 的内存结构以及钙化问题我就不细说了，大家可以查看官网了解下；
• MC 对缓存的数据可以设置失效期，过期后的数据会被清除；
• 失效的策略采用延迟失效，就是当再次使用数据时检查是否失效；
• 当容量存满时，会对缓存中的数据进行剔除，剔除时除了会对过期 key 进行清理，还会按 LRU 策略对数据进行剔除。

另外，使用 MC 有一些限制，这些限制在现在的互联网场景下很致命，成为大家选择Redis、MongoDB的重要原因：

• key 不能超过 250 个字节；
• value 不能超过 1M 字节；
• key 的最大失效时间是 30 天；
• 只支持 K-V 结构，不提供持久化和主从同步功能。

Redis

先简单说一下 Redis 的特点，方便和 MC 比较。

• 与 MC 不同的是，Redis 采用单线程模式处理请求。这样做的原因有 2 个：
  • 一个是因为采用了非阻塞的异步事件处理机制；
  • 另一个是缓存数据都是内存操作 IO 时间不会太长，单线程可以避免线程上下文切换产生的代价。
• Redis 支持持久化，所以 Redis 不仅仅可以用作缓存，也可以用作 NoSQL 数据库。
• 相比 MC，Redis 还有一个非常大的优势，就是除了 K-V 之外，还支持多种数据格式，例如 list、set、sorted set、hash 等。
• Redis 提供主从同步机制，以及 Cluster 集群部署能力，能够提供高可用服务。

两者对比

对于 redis 和 memcached 的区别有下面四点。

1. redis支持更丰富的数据类型（支持更复杂的应用场景）：Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。memcache支持简单的数据类型，String。
2. Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用,而Memecache把数据全部存在内存之中。
3. 集群模式：memcached没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是 redis 目前是原生支持 cluster 模式的.
4. Memcached是多线程，非阻塞IO复用的网络模型；Redis使用单线程的多路 IO 复用模型。

1640848524876

1647861653223

相同点：

• 两者的读写性能都比较高
• 都是基于内存的数据库，通常被当作缓存使用
• 都有过期策略
• 都是基于C语言实现

为什么要用 redis 而不用 map/guava 做缓存?

缓存分为本地缓存和分布式缓存。以 Java 为例，使用自带的 map 或者 guava 实现的是本地缓存，最主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束，并且在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性。

使用 redis 或 memcached 之类的称为分布式缓存，在多实例的情况下，各实例共用一份缓存数据，缓存具有一致性。缺点是需要保持 redis 或 memcached服务的高可用，整个程序架构上较为复杂。

这也是在Flink流式处理项目种使用Rides作为缓存的原因，为了保证数据的一致性。

Rides有那些数据结构

Rides中基础的数据结构有：String、Hash、List、Set、SortedSet。

但是还有一些高级的数据类型，比如Bitmaps，HyperLogLog，GEO。

通常还会使用BloomFilter。

如果有大量的key需要设置同一时间过期，一般需要注意什么？

如果大量的key过期时间设置的过于集中，到过期的那个时间点，Redis可能会出现短暂的卡顿现象。严重的话会出现缓存雪崩，我们一般需要在时间上加一个随机值，使得过期时间分散一些。

电商首页经常会使用定时任务刷新缓存，可能大量的数据失效时间都十分集中，如果失效时间一样，又刚好在失效的时间点大量用户涌入，就有可能造成缓存雪崩

使用过Redis分布式锁么，它是什么回事？

分布式锁的实现方案有：

• 基于mysql的乐观锁
• 基于Rides的分布式锁
• 基于zookeeper的分布式锁。

首先，为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：

1. 互斥性，在任意时刻，只有一个客户端能持有锁。
2. 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
3. 具有容错性。只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。
4. 解铃还须系铃人：加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。
5. 锁最好还是一把公平锁
6. 获取锁和释放锁的性能需要好。

setnx将 key 的值设为 value，当且仅当 key 不存在。 若给定的 key 已经存在，则 SETNX 不做任何动作。 SETNX 是SET if Not eXists的简写。

127.0.0.1:6379> expire lock 10
(integer) 1
127.0.0.1:6379> ttl lock
8
127.0.0.1:6379> get lock
(nil)

基于Rides的分布式锁

1640431577210

redis实现分布式锁问题

如果出现了这么一个问题：如果setnx是成功的，但是expire设置失败，那么后面如果出现了释放锁失败的问题，那么这个锁永远也不会被得到，业务将被锁死？

之所以产生这样的情况，是因为这两个命令的执行不是原子操作的，如果是原子操作，就不会发生这样的问题。

解决的办法：使用set的命令，同时设置锁和过期时间

set参数：

set key value [EX seconds] [PX milliseconds] [NX|XX]
EX seconds：设置失效时长，单位秒
PX milliseconds：设置失效时长，单位毫秒
NX：key不存在时设置value，成功返回OK，失败返回(nil)
XX：key存在时设置value，成功返回OK，失败返回(nil)

这个命令相当于把上面获取锁和释放锁的命令组成一个原子操作。

假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如何将它们全部找出来？

使用keys指令可以扫出指定模式的key列表。

如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？

这个时候你要回答Redis关键的一个特性：Redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。

这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

不过，增量式迭代命令也不是没有缺点的： 举个例子， 使用 SMEMBERS 命令可以返回集合键当前包含的所有元素， 但是对于 SCAN 这类增量式迭代命令来说， 因为在对键进行增量式迭代的过程中， 键可能会被修改， 所以增量式迭代命令只能对被返回的元素提供有限的保证 。

使用过Redis做异步队列么，你是怎么用的？

一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。

可不可以不用sleep呢？

list还有个指令叫blpop，在没有消息的时候，它会阻塞住直到消息到来。

能不能生产一次消费多次呢？

使用pub/sub主题订阅者模式，可以实现 1:N 的消息队列。

Redis是怎么持久化的？服务主从数据怎么交互的？

RDB做镜像全量持久化，AOF做增量持久化。因为RDB会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要AOF来配合使用。

在redis实例重启时，会使用RDB持久化文件重新构建内存，再使用AOF重放近期的操作指令来实现完整恢复重启之前的状态。

这里很好理解，把RDB理解为一整个表全量的数据，AOF理解为每次操作的日志就好了，服务器重启的时候先把表的数据全部搞进去，但是他可能不完整，你再回放一下日志，数据不就完整了嘛。不过Redis本身的机制是 AOF持久化开启且存在AOF文件时，优先加载AOF文件；AOF关闭或者AOF文件不存在时，加载RDB文件；加载AOF/RDB文件城后，Redis启动成功； AOF/RDB文件存在错误时，Redis启动失败并打印错误信息

那如果突然机器掉电会怎样？

取决于AOF日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。

在aof这种方式持久化时候，追加写日志的方式有三种：

• always(每次）
  • 每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用。
• everysec（每秒）
  • 每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高在系统突然宕机的情况下丢失1秒内的数据，，建议使用，也是默认配置
• no（系统控制）
  • 由操作系统控制每次同步到AOF文件的周期，整体过程不可控

RDB的原理是什么？

你给出两个词汇就可以了，fork和cow。fork是指redis通过创建子进程来进行RDB操作，cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。

Redis 持久化

什么是 Redis 持久化？

持久化就是把内存的数据写到磁盘中去，防止服务宕机内存数据丢失。

Redis 提供了两种持久化方式：RDB(默认)和 AOF

简介

数据存放于：

内存：高效，断电（关机）内存数据会丢失

硬盘：读写速度慢于内存，断电数据不会丢失

Redis 持久化存储支持两种方式：RDB 和 AOF。RDB 一定时间取存储文件，AOF 默认每秒去存储历史命令，

Redis 是支持持久化的内存数据库，也就是说 redis 需要经常将内存中的数据同步到硬盘来保证持久化。

RDB

RDB 是 Redis DataBase 缩写

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

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是所说的 snapshot 快照，它恢复是将磁盘中的数据直接读到内存里。

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

功能核心函数 rdbSave（生成 RDB 文件）和 rdbLoad（从文件加载内存）两个函数

• rdbSave：生成 RDB 文件
• rdbLoad：从文件夹杂内存

1640334929317

RDB : 是redis默认的持久化机制

快照是默认的持久化方式。这种方式就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。

优点：

• 快照保存数据极快，还原数据极快
• 适用于灾难备份

缺点：

• 小内存机器不适合使用，RDB机制符合要求就会照快照

快照条件：

1、服务器正常关闭：./bin/redis-cli shutdown
2、key满足一定条件，会进行快照
 vim redis.config 搜索save
 /save
save   900  1      //每秒900秒（15分钟）至少1个key发生变化，产生快照
save   300  10     //每300秒  （5分钟）至少10个key发生变化，产生快照
save   60   10000  //每60秒（1分钟）至少10000个key发生变化，产生快照

AOF

由于快照方式是在一定间隔时间做一次的，所以如果 redis 意外 down 掉的话，就会丢失最后一个快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用 aof 持久化方式。

Append-only file：aof 比 rdb 有更好的持久化性，是由于在使用 aof 持久化方式时，redis 会将每一个收到的命令都通过 write 函数追加到文件中（默认是 appendonly.aof)。当 redis 重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

1640334941212

每当执行服务器（定时）任务或者函数时， flushAppendOnlyFile 函数都会被调用，这个函数执行以下两个工作 ，aof 写入保存：

WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件。

SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。

有三种方式如下（默认是：每秒 fsync 一次）

• appendonly yes //启用 aof 持久化方式
• # appendfsync always //收到写命令就立即写入磁盘，最慢，但是保证完全的持久化
• appendfysnceverysec //每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中
• # appendfysnc no //完全依赖 os，性能孔，持久化没保证

产生的问题：

aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用 incr test 命令 100 次，文件中必须保存全部的 1000 条命令，其实有 99 条都是多余的。

Redis的同步机制了解么？

Redis可以使用主从同步，从从同步。第一次同步时，主节点做一次bgsave，并同时将后续修改操作记录到内存buffer，待完成后将RDB文件全量同步到复制节点，复制节点接受完成后将RDB镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。

后续的增量数据通过AOF日志同步即可，有点类似数据库的binlog。

是否使用过Redis集群，集群的高可用怎么保证，集群的原理是什么？

Redis Sentinal 着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务。

Redis Cluster 着眼于扩展性，在单个redis内存不足时，使用Cluster进行分片存储。

Redis雪崩了解么？

1. 系统平稳运行过程中，忽然数据库连接量激增
2. 应用服务器无法及时处理请求
3. 大量408，500错误页面出现
4. 客户反复刷新页面获取数据
5. 数据库崩溃
6. 应用服务器崩溃
7. 重启应用服务器无效
8. Redis服务器崩溃
9. Redis集群崩溃
10. 重启数据库后再次被瞬间流量放倒

举个简单的例子：如果所有首页的Key失效时间都是12小时，中午12点刷新的，我零点有个秒杀活动大量用户涌入，假设当时每秒 6000 个请求，本来缓存在可以扛住每秒 5000 个请求，但是缓存当时所有的Key都失效了。此时 1 秒 6000 个请求全部落数据库，数据库必然扛不住，它会报一下警，真实情况可能DBA都没反应过来就直接挂了。

1640432503225

处理缓存雪崩简单，在批量往Redis存数据的时候，把每个Key的失效时间都加个随机值就好了，这样可以保证数据不会在同一时间大面积失效

setRedis（Key，value，time + Math.random() * 10000）；

或者设置热点数据永远不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，那你刷下缓存就完事了，不要设置过期时间），电商首页的数据也可以用这个操作，保险。

如果Redis是集群部署，将热点数据均匀分布在不同的Redis库中也能避免全部失效的问题

缓存穿透

缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，我们数据库的 id 都是1开始自增上去的，如发起为id值为 -1 的数据或 id 为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大，严重会击垮数据库。

1640432778786

像这种你如果不对参数做校验，数据库id都是大于0的，我一直用小于0的参数去请求你，每次都能绕开Redis直接打到数据库，数据库也查不到，每次都这样，并发高点就容易崩掉了。

如何解决上面遇到的问题

缓存穿透我会在接口层增加校验，比如用户鉴权校验，参数做校验，不合法的参数直接代码Return，比如：id 做基础校验，id <=0的直接拦截等。

还有我记得Redis还有一个高级用法布隆过滤器（Bloom Filter）这个也能很好的防止缓存穿透的发生，他的原理也很简单就是利用高效的数据结构和算法快速判断出你这个Key是否在数据库中存在，不存在你return就好了，存在你就去查了DB刷新KV再return。

缓存击穿

• 系统平稳运行过程中
• 数据库连接量瞬间激增
• Redis服务器无大量key过期
• Redis内存平稳，无波动
• Redis服务器CPU正常
• 数据库崩溃

缓存雪崩是因为大面积的缓存失效，打崩了DB，而缓存击穿不同的是缓存击穿是指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个完好无损的桶上凿开了一个洞。

缓存穿透类似偷袭，绕过radis，袭击数据库。缓存击穿类似正面硬刚，一直进攻一个地方，直到失效时一起涌入攻击数据库。缓存雪崩类似鬼子进村。

缓存击穿的话，设置热点数据永远不过期。或者加上互斥锁就能搞定了

Rides为什么那么快

关系型数据库跟Redis本质上的区别

1640433477178

Redis采用的是基于内存，采用的是单进程单线程模型的 KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。

• 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。它的，数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；
• 数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；
• 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
• 使用多路I/O复用模型，非阻塞IO；
• 使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

Rides既然是单线程的，那么现在服务器都是多核心的，会浪费性能吧

是的他是单线程的，但是，我们可以通过在单机开多个Redis实例

既然提到了单机会有瓶颈，那你们是怎么解决这个瓶颈的？

我们用到了集群的部署方式也就是Redis cluster，并且是主从同步读写分离，类似Mysql的主从同步，Redis cluster 支撑 N 个 Redis master node，每个master node都可以挂载多个 slave node。

这样整个 Redis 就可以横向扩容了。如果你要支撑更大数据量的缓存，那就横向扩容更多的 master 节点，每个 master 节点就能存放更多的数据了。

他们之间是怎么进行数据交互的？以及Redis是怎么进行持久化的？Redis数据都在内存中，一断电或者重启不就没有了嘛？

是的，持久化的话是Redis高可用中比较重要的一个环节，因为Redis数据在内存的特性，持久化必须得有，我了解到的持久化是有两种方式的。

• RDB：RDB 持久化机制，是对 Redis 中的数据执行周期性的持久化。
• AOF：AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像Mysql中的binlog。

两种方式都可以把Redis内存中的数据持久化到磁盘上，然后再将这些数据备份到别的地方去，RDB更适合做冷备，AOF更适合做热备，比如我杭州的某电商公司有这两个数据，我备份一份到我杭州的节点，再备份一个到上海的，就算发生无法避免的自然灾害，也不会两个地方都一起挂吧，这灾备也就是异地容灾。

tip：两种机制全部开启的时候，Redis在重启的时候会默认使用AOF去重新构建数据，因为AOF的数据是比RDB更完整的。

那这两种机制各自优缺点是啥？

我先说RDB吧

优点：

他会生成多个数据文件，每个数据文件分别都代表了某一时刻Redis里面的数据，这种方式，有没有觉得很适合做冷备，完整的数据运维设置定时任务，定时同步到远端的服务器，比如阿里的云服务，这样一旦线上挂了，你想恢复多少分钟之前的数据，就去远端拷贝一份之前的数据就好了。

RDB对Redis的性能影响非常小，是因为在同步数据的时候他只是fork了一个子进程去做持久化的，而且他在数据恢复的时候速度比AOF来的快。

缺点：

RDB都是快照文件，都是默认五分钟甚至更久的时间才会生成一次，这意味着你这次同步到下次同步这中间五分钟的数据都很可能全部丢失掉。AOF则最多丢一秒的数据，数据完整性上高下立判。

还有就是RDB在生成数据快照的时候，如果文件很大，客户端可能会暂停几毫秒甚至几秒，你公司在做秒杀的时候他刚好在这个时候fork了一个子进程去生成一个大快照，哦豁，出大问题。

我们再来说说AOF

优点：

上面提到了，RDB五分钟一次生成快照，但是AOF是一秒一次去通过一个后台的线程fsync操作，那最多丢这一秒的数据。

AOF在对日志文件进行操作的时候是以append-only的方式去写的，他只是追加的方式写数据，自然就少了很多磁盘寻址的开销了，写入性能惊人，文件也不容易破损。

AOF的日志是通过一个叫非常可读的方式记录的，这样的特性就适合做灾难性数据误删除的紧急恢复了，比如公司的实习生通过flushall清空了所有的数据，只要这个时候后台重写还没发生，你马上拷贝一份AOF日志文件，把最后一条flushall命令删了就完事了。

缺点：

一样的数据，AOF文件比RDB还要大。

AOF开启后，Redis支持写的QPS会比RDB支持写的要低，他不是每秒都要去异步刷新一次日志嘛fsync，当然即使这样性能还是很高，我记得ElasticSearch也是这样的，异步刷新缓存区的数据去持久化，为啥这么做呢，不直接来一条怼一条呢，那我会告诉你这样性能可能低到没办法用的，大家可以思考下为啥哟。

那两者怎么选择？

我全都要，你单独用RDB你会丢失很多数据，你单独用AOF，你数据恢复没RDB来的快，真出什么时候第一时间用RDB恢复，然后AOF做数据补全。

你提到了高可用，Redis还有其他保证集群高可用的方式么？

还有哨兵集群sentinel。

哨兵的作用

• 监控
  • 不断的检查master和slave是否正常运行。
  • master存活检测、master与slave运行情况检测
• 通知（提醒）
  • 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知
• 自动故障转移
  • 断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址

哨兵必须用三个实例去保证自己的健壮性的，哨兵+主从并不能保证数据不丢失，但是可以保证集群的高可用。

为啥必须要三个实例呢？我们先看看两个哨兵会咋样。

1640433980129

master宕机了 s1和s2两个哨兵只要有一个认为你宕机了就切换了，并且会选举出一个哨兵去执行故障，但是这个时候也需要大多数哨兵都是运行的。

那这样有啥问题呢？M1宕机了，S1没挂那其实是OK的，但是整个机器都挂了呢？哨兵就只剩下S2个裸屌了，没有哨兵去允许故障转移了，虽然另外一个机器上还有R1，但是故障转移就是不执行。

经典的哨兵集群是这样的：

1640434055277

M1所在的机器挂了，哨兵还有两个，两个人一看他不是挂了嘛，那我们就选举一个出来执行故障转移不就好了。

总结下哨兵组件的主要功能：

• 集群监控：负责监控 Redis master 和 slave 进程是否正常工作。
• 消息通知：如果某个 Redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
• 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
• 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

能说一下主从之间的数据怎么同步的么？

主从同步总的来说分为三步骤：

1. 建立连接阶段：建立socket连接
2. 数据同步阶段：
   1. 第一部分是rdb全量数据复制过程
   2. 第二部是缓冲区的部分复制过程
3. 命令传播阶段：就是master将接收到的命令发送给slave进行执行，保证数据的同步性。

主从同步和前面提到的数据持久化的RDB和AOF有着比密切的关系了。

我先说下为啥要用主从这样的架构模式，前面提到了单机QPS是有上限的，而且Redis的特性就是必须支撑读高并发的，那你一台机器又读又写，这谁顶得住啊，不当人啊！但是你让这个master机器去写，数据同步给别的slave机器，他们都拿去读，分发掉大量的请求那是不是好很多，而且扩容的时候还可以轻松实现水平扩容。

1640434174172

他们数据怎么同步的呢？

你启动一台slave 的时候，他会发送一个psync命令给master ，如果是这个slave第一次连接到master，他会触发一个全量复制。master就会启动一个线程，生成RDB快照，还会把新的写请求都缓存在内存中，RDB文件生成后，master会将这个RDB发送给slave的，slave拿到之后做的第一件事情就是写进本地的磁盘，然后加载进内存，然后master会把内存里面缓存的那些新命名都发给slave。

数据传输的时候断网了或者服务器挂了怎么办啊？

传输过程中有什么网络问题啥的，会自动重连的，并且连接之后会把缺少的数据补上的。

大家需要记得的就是，RDB快照的数据生成的时候，缓存区也必须同时开始接受新请求，不然你旧的数据过去了，你在同步期间的增量数据咋办？是吧？

那说了这么多你能说一下他的内存淘汰机制么，来手写一下LRU代码？

Rides中数据的删除方案，定时删除，惰性删除，定期删除三种，其中定期删除是定时删除和惰性删除的折中方案。

Redis的过期策略，是有定期删除+惰性删除两种。

定期好理解，默认100ms就随机抽一些设置了过期时间的key，去检查是否过期，过期了就删了。

为啥不扫描全部设置了过期时间的key呢？

假如Redis里面所有的key都有过期时间，都扫描一遍？那太恐怖了，而且我们线上基本上也都是会设置一定的过期时间的。全扫描跟你去查数据库不带where条件不走索引全表扫描一样，100ms一次，Redis累都累死了。

如果一直没随机到很多key，里面不就存在大量的无效key了？

好问题，惰性删除，见名知意，惰性嘛，我不主动删，我懒，我等你来查询了我看看你过期没，过期就删了还不给你返回，没过期该怎么样就怎么样。

键的过期删除策略

常见的过期删除策略是惰性删除、定期删除、定时删除。

• 惰性删除：只有访问这个键时才会检查它是否过期，如果过期则清除。**优点：**最大化地节约CPU资源。**缺点：**如果大量过期键没有被访问，会一直占用大量内存。
• 定时删除：为每个设置过期时间的key都创造一个定时器，到了过期时间就清除。**优点：**该策略可以立即清除过期的键。**缺点：**会占用大量的CPU资源去处理过期的数据。
• 定期删除：每隔一段时间就对一些键进行检查，删除其中过期的键。该策略是惰性删除和定时删除的一个折中，既避免了占用大量CPU资源又避免了出现大量过期键不被清除占用内存的情况。

Redis中同时使用了惰性删除和定期删除两种。

最后就是如果的如果，定期没删，我也没查询，那可咋整？

内存淘汰机制！

作为缓存系统都要定期清理无效数据，就需要一个主键失效和淘汰策略.

在Redis当中，有生存期的key被称为volatile。在创建缓存时，要为给定的key设置生存期，当key过期的时候（生存期为0），它可能会被删除。

1、影响生存时间的一些操作

生存时间可以通过使用 DEL 命令来删除整个 key 来移除，或者被 SET 和 GETSET 命令覆盖原来的数据，也就是说，修改key对应的value和使用另外相同的key和value来覆盖以后，当前数据的生存时间不同。

比如说，对一个 key 执行INCR命令，对一个列表进行LPUSH命令，或者对一个哈希表执行HSET命令，这类操作都不会修改 key 本身的生存时间。另一方面，如果使用RENAME对一个 key 进行改名，那么改名后的 key的生存时间和改名前一样。

RENAME命令的另一种可能是，尝试将一个带生存时间的 key 改名成另一个带生存时间的 another_key ，这时旧的 another_key (以及它的生存时间)会被删除，然后旧的 key 会改名为 another_key ，因此，新的 another_key 的生存时间也和原本的 key 一样。使用PERSIST命令可以在不删除 key 的情况下，移除 key 的生存时间，让 key 重新成为一个persistent key 。

2、如何更新生存时间

可以对一个已经带有生存时间的 key 执行EXPIRE命令，新指定的生存时间会取代旧的生存时间。过期时间的精度已经被控制在1ms之内，主键失效的时间复杂度是O（1），

EXPIRE和TTL命令搭配使用，TTL可以查看key的当前生存时间。设置成功返回 1；当 key 不存在或者不能为 key 设置生存时间时，返回 0 。

最大缓存配置 在 redis 中，允许用户设置最大使用内存大小 server.maxmemory 默认为0，没有指定最大缓存，如果有新的数据添加，超过最大内存，则会使redis崩溃，所以一定要设置。redis 内存数据集大小上升到一定大小的时候，就会实行数据淘汰策略。redis 提供 6种数据淘汰策略：

Redis是基于内存的，所以容量肯定是有限的，有效的内存淘汰机制对Redis是非常重要的。

当存入的数据超过Redis最大允许内存后，会触发Redis的内存淘汰策略。在Redis4.0前一共有6种淘汰策略。

• volatile-lru：当Redis内存不足时，会在设置了过期时间的键中使用LRU算法移除那些最少使用的键。（注：在面试中，手写LRU算法也是个高频题，使用双向链表和哈希表作为数据结构）
• volatile-ttl：从设置了过期时间的键中移除将要过期的
• volatile-random：从设置了过期时间的键中随机淘汰一些
• allkeys-lru：当内存空间不足时，根据LRU算法移除一些键
• allkeys-random：当内存空间不足时，随机移除某些键
• noeviction：当内存空间不足时，新的写入操作会报错

前三个是在设置了过期时间的键的空间进行移除，后三个是在全局的空间进行移除

在Redis4.0后可以增加两个

• volatile-lfu：从设置过期时间的键中移除一些最不经常使用的键（LFU算法：Least Frequently Used)）
• allkeys-lfu：当内存不足时，从所有的键中移除一些最不经常使用的键

这两个也是一个是在设置了过期时间的键的空间，一个是在全局空间。

使用策略规则：

1、 如果数据呈现幂律分布，也就是一部分数据访问频率高，一部分数据访问频率低，则使用allkeys-lru2、 如果数据呈现平等分布，也就是所有的数据访问频率都相同，则使用allkeys-random

三种数据淘汰策略：

ttl和random比较容易理解，实现也会比较简单。主要是Lru最近最少使用淘汰策略，设计上会对key 按失效时间排序，然后取最先失效的key进行淘汰

redis的并发竞争问题如何解决?

Redis为单进程单线程模式，采用队列模式将并发访问变为串行访问。Redis本身没有锁的概念，Redis对于多个客户端连接并不存在竞争，但是在Jedis客户端对Redis进行并发访问时会发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题，这些问题均是

由于客户端连接混乱造成。对此有2种解决方法：

• 客户端角度，为保证每个客户端间正常有序与Redis进行通信，对连接进行池化，同时对客户端读写Redis操作采用内部锁synchronized。
• 服务器角度，利用setnx实现锁。注：对于第一种，需要应用程序自己处理资源的同步，可以使用的方法比较通俗，可以使用synchronized也可以使用lock；第二种需要用到Redis的setnx命令，但是需要注意一些问题。

这个也是线上非常常见的一个问题，就是多客户端同时并发写一个key，可能本来应该先到的数据后到了，导致数据版本错了。或者是多客户端同时获取一个key，修改值之后再写回去，只要顺序错了，数据就错了。

而且redis自己就有天然解决这个问题的CAS类的乐观锁方案

1640852898342

redis常见性能问题和解决方案

Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照。

Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。

Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化,如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。

Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。

Redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。

Redis主从架构中数据丢失吗

Redis主从架构丢失主要有两种情况

• 异步复制同步丢失
• 集群产生脑裂数据丢失

下面分别简单介绍下这两种情况：

异步复制同步丢失：

Redis主节点和从节点之间的复制是异步的，当主节点的数据未完全复制到从节点时就发生宕机了，master内存中的数据会丢失。

如果主节点开启持久化是否可以解决这个问题呢？

答案是否定的，在master 发生宕机后，sentinel集群检测到主节点发生故障，重新选举新的主节点，如果旧的主节点在故障恢复后重启，那么此时它需要同步新主节点的数据，此时新的主节点的数据是空的（假设这段时间中没有数据写入）。那么旧主机点中的数据就会被刷新掉，此时数据还是会丢失。

集群产生脑裂：

简单来说，集群脑裂是指一个集群中有多个主节点，像一个人有两个大脑，到底听谁的呢？

例如，由于网络原因，集群出现了分区，master与slave节点之间断开了联系，哨兵检测后认为主节点故障，重新选举从节点为主节点，但主节点可能并没有发生故障。此时客户端依然在旧的主节点上写数据，而新的主节点中没有数据，在发现这个问题之后，旧的主节点会被降为slave，并且开始同步新的master数据，那么之前的写入旧的主节点的数据被刷新掉，大量数据丢失。

如何解决主从架构数据丢失问题？

在Redis的配置文件中，有两个参数如下：

min-slaves-to-write 1
min-slaves-max-lag 10

其中，min-slaves-to-write默认情况下是0，min-slaves-max-lag默认情况下是10。

上述参数表示至少有1个salve的与master的同步复制延迟不能超过10s，一旦所有的slave复制和同步的延迟达到了10s，那么此时master就不会接受任何请求。

通过降低min-slaves-max-lag参数的值，可以避免在发生故障时大量的数据丢失，一旦发现延迟超过了该值就不会往master中写入数据。

这种解决数据丢失的方法是降低系统的可用性来实现的。

Redis高可用方案如何实现？

常见的Redis高可用方案有以下几种：

• 数据持久化
• 主从模式
• Redis 哨兵模式

什么是Redis的事务

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

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

Redis事务的相关命令

Redis事务相关的命令主要有以下几种：

• DISCARD：命令取消事务，放弃执行事务队列内的所有命令，恢复连接为非 (transaction) 模式，如果正在使用 WATCH 命令监视某个(或某些) key，那么取消所有监视，等同于执行命令 UNWATCH 。
• EXEC：执行事务队列内的所有命令。
• MULTI：用于标记一个事务块的开始。
• UNWATCH：用于取消 WATCH命令对所有 key 的监视。如果已经执行过了EXEC或DISCARD命令，则无需再执行UNWATCH命令，因为执行EXEC命令时，开始执行事务，WATCH命令也会生效，而 DISCARD命令在取消事务的同时也会取消所有对 key 的监视，所以不需要再执行UNWATCH命令了
• WATCH：用于标记要监视的key，以便有条件地执行事务，WATCH命令可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行。

Redis事务执行的三个阶段

1. 开始事务（MULTI）
2. 命令入列
3. 执行事务（EXEC）

Redis事务的特性

• Redis事务不保证原子性，单条的Redis命令是原子性的，但事务不能保证原子性。
• Redis事务是有隔离性的，但没有隔离级别，事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。（顺序性、排他性）
• Redis事务不支持回滚，Redis执行过程中的命令执行失败，其他命令仍然可以执行。（一次性）

Redis事务为什么不支持回滚？

在Redis的事务中，命令允许失败，但是Redis会继续执行其它的命令而不是回滚所有命令，是不支持回滚的。

主要原因有以下两点：

• Redis 命令只在两种情况失败：

• • 语法错误的时候才失败（在命令输入的时候不检查语法）。

• 要执行的key数据类型不匹配：这种错误实际上是编程错误，这应该在开发阶段被测试出来，而不是生产上。

• 因为不需要回滚，所以Redis内部实现简单并高效。（在Redis为什么是单线程而不是多线程也用了这个思想，实现简单并且高效）

Rides是单线程的还是多线程的

为什么在最开始Rides被设计为单线程

Redis作为一个成熟的分布式缓存框架，它由很多个模块组成，如网络请求模块、索引模块、存储模块、高可用集群支撑模块、数据操作模块等。

很多人说Redis是单线程的，就认为Redis中所有模块的操作都是单线程的，其实这是不对的。

我们所说的Redis单线程，指的是"其网络IO和键值对读写是由一个线程完成的"，也就是说，Redis中只有网络请求模块和数据操作模块是单线程的。而其他的如持久化存储模块、集群支撑模块等是多线程的。

所以说，Redis中并不是没有多线程模型的，早在Redis 4.0的时候就已经针对部分命令做了多线程化。

那么，为什么网络操作模块和数据存储模块最初并没有使用多线程呢？

这个问题的答案比较简单！因为："没必要！"

为什么没必要呢？我们先来说一下，什么情况下要使用多线程？

多线程的使用场景

一个计算机程序在执行的过程中，主要需要进行两种操作分别是读写操作和计算操作。

其中读写操作主要是涉及到的就是I/O操作，其中包括网络I/O和磁盘I/O。计算操作主要涉及到CPU。

而多线程的目的，就是通过并发的方式来提升I/O的利用率和CPU的利用率。

那么，Redis需不需要通过多线程的方式来提升提升I/O的利用率和CPU的利用率呢？

首先，我们可以肯定的说，Redis不需要提升CPU利用率，因为Redis的操作基本都是基于内存的，CPU资源根本就不是Redis的性能瓶颈。

所以，通过多线程技术来提升Redis的CPU利用率这一点是完全没必要的。

那么，使用多线程技术来提升Redis的I/O利用率呢？是不是有必要呢？

Redis确实是一个I/O操作密集的框架，他的数据操作过程中，会有大量的网络I/O和磁盘I/O的发生。要想提升Redis的性能，是一定要提升Redis的I/O利用率的，这一点毋庸置疑。

但是，提升I/O利用率，并不是只有采用多线程技术这一条路可以走！、

多线程的弊端

Java中的多线程技术，如内存模型、锁、CAS等，这些都是Java中提供的一些在多线程情况下保证线程安全的技术。

线程安全：是编程中的术语，指某个函数、函数库在并发环境中被调用时，能够正确地处理多个线程之间的共享变量，使程序功能正确完成。

和Java类似，所有支持多线程的编程语言或者框架，都不得不面对的一个问题，那就是如何解决多线程编程模式带来的共享资源的并发控制问题。

虽然，采用多线程可以帮助我们提升CPU和I/O的利用率，但是多线程带来的并发问题也给这些语言和框架带来了更多的复杂性。而且，多线程模型中，多个线程的互相切换也会带来一定的性能开销。

所以，在提升I/O利用率这个方面上，Redis并没有采用多线程技术，而是选择了多路复用 I/O技术。

小结

Redis并没有在网络请求模块和数据操作模块中使用多线程模型，主要是基于以下四个原因：

• Redis 操作基于内存，绝大多数操作的性能瓶颈不在 CPU
• 使用单线程模型，可维护性更高，开发，调试和维护的成本更低
• 单线程模型，避免了线程间切换带来的性能开销
• 在单线程中使用多路复用 I/O技术也能提升Redis的I/O利用率

还是要记住：Redis并不是完全单线程的，只是有关键的网络IO和键值对读写是由一个线程完成的。

Rides多路复用

多路复用这个词，相信很多人都不陌生。我之前的很多文章中也够提到过这个词。

其中在介绍Linux IO模型的时候我们提到过它、在介绍HTTP/2的原理的时候，我们也提到过他。

那么，Redis的多路复用技术和我们之前介绍的又有什么区别呢？

这里先讲讲Linux多路复用技术，就是多个进程的IO可以注册到同一个管道上，这个管道会统一和内核进行交互。当管道中的某一个请求需要的数据准备好之后，进程再把对应的数据拷贝到用户空间中。

1640853692277

也就是说，通过一个线程来处理多个IO流。

IO多路复用在Linux下包括了三种，select、poll、epoll，抽象来看，他们功能是类似的，但具体细节各有不同。

其实，Redis的IO多路复用程序的所有功能都是通过包装操作系统的IO多路复用函数库来实现的。每个IO多路复用函数库在Redis源码中都有对应的一个单独的文件。

1640853762838

在Redis 中，每当一个套接字准备好执行连接应答、写入、读取、关闭等操作时，就会产生一个文件事件。因为一个服务器通常会连接多个套接字，所以多个文件事件有可能会并发地出现。

1640853801916

一旦有请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果。

所以，Redis选择使用多路复用IO技术来提升I/O利用率。

而之所以Redis能够有这么高的性能，不仅仅和采用多路复用技术和单线程有关，此外还有以下几个原因：

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。

2、数据结构简单，对数据操作也简单，如哈希表、跳表都有很高的性能。

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU

4、使用多路I/O复用模型

为什么Redis 6.0 引入多线程

2020年5月份，Redis正式推出了6.0版本，这个版本中有很多重要的新特性，其中多线程特性引起了广泛关注。

但是，需要提醒大家的是，Redis 6.0中的多线程，也只是针对处理网络请求过程采用了多线程，而数据的读写命令，仍然是单线程处理的。

但是，不知道会不会有人有这样的疑问：

Redis不是号称单线程也有很高的性能么？

不是说多路复用技术已经大大的提升了IO利用率了么，为啥还需要多线程？

主要是因为我们对Redis有着更高的要求。

根据测算，Redis 将所有数据放在内存中，内存的响应时长大约为 100 纳秒，对于小数据包，Redis 服务器可以处理 80,000 到 100,000 QPS，这么高的对于 80% 的公司来说，单线程的 Redis 已经足够使用了。

但随着越来越复杂的业务场景，有些公司动不动就上亿的交易量，因此需要更大的 QPS。

为了提升QPS，很多公司的做法是部署Redis集群，并且尽可能提升Redis机器数。但是这种做法的资源消耗是巨大的。

而经过分析，限制Redis的性能的主要瓶颈出现在网络IO的处理上，虽然之前采用了多路复用技术。但是我们前面也提到过，多路复用的IO模型本质上仍然是同步阻塞型IO模型。

下面是多路复用IO中select函数的处理过程：

1640853983372

从上图我们可以看到，在多路复用的IO模型中，在处理网络请求时，调用 select （其他函数同理）的过程是阻塞的，也就是说这个过程会阻塞线程，如果并发量很高，此处可能会成为瓶颈。

虽然现在很多服务器都是多个CPU核的，但是对于Redis来说，因为使用了单线程，在一次数据操作的过程中，有大量的CPU时间片是耗费在了网络IO的同步处理上的，并没有充分的发挥出多核的优势。

如果能采用多线程，使得网络处理的请求并发进行，就可以大大的提升性能。多线程除了可以减少由于网络 I/O 等待造成的影响，还可以充分利用 CPU 的多核优势。

所以，Redis 6.0采用多个IO线程来处理网络请求，网络请求的解析可以由其他线程完成，然后把解析后的请求交由主线程进行实际的内存读写。提升网络请求处理的并行度，进而提升整体性能。

但是，Redis 的多 IO 线程只是用来处理网络请求的，对于读写命令，Redis 仍然使用单线程来处理。

那么，在引入多线程之后，如何解决并发带来的线程安全问题呢？

这就是为什么我们前面多次提到的"Redis 6.0的多线程只用来处理网络请求，而数据的读写还是单线程"的原因。

Redis 6.0 只有在网络请求的接收和解析，以及请求后的数据通过网络返回给时，使用了多线程。而数据读写操作还是由单线程来完成的，所以，这样就不会出现并发问题了。

如何保证缓存与数据库双写时的数据一致性？

这是面试的高频题，需要好好掌握，这个问题是没有最优解的，只能数据一致性和性能之间找到一个最适合业务的平衡点

首先先来了解下一致性，在分布式系统中，一致性是指多副本问题中的数据一致性。一致性可以分为强一致性、弱一致性和最终一致性

• 强一致性：当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。强一致性对用户比较友好，但对系统性能影响比较大。
• 弱一致性：系统并不保证后续进程或者线程的访问都会返回最新的更新过的值。
• 最终一致性：也是弱一致性的一种特殊形式，系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。

大多数系统都是采用的最终一致性，最终一致性是指系统中所有的副本经过一段时间的异步同步之后，最终能够达到一个一致性的状态，也就是说在数据的一致性上存在一个短暂的延迟。

如果想保证缓存和数据库的数据一致性，最简单的想法就是同时更新数据库和缓存，但是这实现起来并不现实，常见的方案主要有以下几种：

• 先更新数据库，后更新缓存
• 先更新缓存，后更新数据库
• 先更新数据库，后删除缓存
• 先删除缓存，后更新数据库

乍一看，感觉第一种方案就可以实现缓存和数据库一致性，其实不然，更新缓存是个坑，一般不会有更新缓存的操作。因为很多时候缓存中存的值不是直接从数据库直接取出来放到缓存中的，而是经过一系列计算得到的缓存值，如果数据库写操作频繁，缓存也会频繁更改，所以更新缓存代价是比较大的，并且更改后的缓存也不一定会被访问就又要重新更改了，这样做无意义的性能消耗太大了。下面介绍删除缓存的方案

先更新数据库，后删除缓存

这种方案也存在一个问题，如果更新数据库成功了，删除缓存时没有成功，那么后面每次读取缓存时都是错误的数据。

解决这个问题的办法是删除重试机制，常见的方案有利用消息队列和数据库的日志

利用消息队列实现删除重试机制，如下图

1647863394750

先删除缓存，后更新数据库

这种方案也存在一些问题，比如在并发环境下，有两个请求A和B，A是更新操作，B是查询操作

1. 假设A请求先执行，会先删除缓存中的数据，然后去更新数据库
2. B请求查询缓存发现为空，会去查询数据库，并把这个值放到缓存中
3. 在B查询数据库时A还没有完全更新成功，所以B查询并放到缓存中的是旧的值，并且以后每次查询缓存中的值都是错误的旧值

这种情况的解决方法通常是采用延迟双删，就是为保证A操作已经完成，最后再删除一次缓存

1647863466039

逻辑很简单，删除缓存后，休眠一会儿再删除一次缓存，虽然逻辑看起来简单，但实现起来并不容易，问题就出在延迟时间设置多少合适，延迟时间一般大于B操作读取数据库+写入缓存的时间，这个只能是估算，一般可以考虑读业务逻辑数据的耗时 + 几百毫秒。

在实际应用中，还是先更新数据库后删除缓存这种方案用的多些。

需要注意的是，无论哪种方案，如果数据库采取读写分离+主从复制延迟的话，即使采用先更新数据库后删除缓存也会出现类似先删除缓存后更新数据库中出现的问题，举个例子

1. A操作更新主库后，删除了缓存
2. B操作查询缓存没有查到数据，查询从库拿到旧值
3. 主库将新值同步到从库
4. B操作将拿到的旧值写入缓存

这就造成了缓存中的是旧值，数据库中的是新值，解决方法还是上面说的延迟双删，延迟时间要大于主从复制的时间。

Redis 缓存雪崩、缓存击穿、缓存穿透

缓存雪崩

通常我们为了保证缓存中的数据与数据库中的数据一致性，会给 Redis 里的数据设置过期时间，当缓存数据过期后，用户访问的数据如果不在缓存里，业务系统需要重新生成缓存，因此就会访问数据库，并将数据更新到 Redis 里，这样后续请求都可以直接命中缓存。

那么，当大量缓存数据在同一时间过期（失效）或者 Redis 故障宕机时，如果此时有大量的用户请求，都无法在 Redis 中处理，于是全部请求都直接访问数据库，从而导致数据库的压力骤增，严重的会造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃，这就是缓存雪崩的问题。

1640334966299

解决办法：

用锁/分布式锁或者队列串行访问

缓存失效时间均匀分布

如果缓存集中在一端时间内失效，发生大量的缓存穿透，所有的查询都落在数据库上，造成了缓存雪崩。

这个没有完美解决办法，但是可以分析用户的行为，尽量让失效时间点均匀分布。大所属系统设计者考虑用加锁或者队列的方式保证缓存的单线程写，从而避免失效时大量的并发请求落到底层存储系统上。

1. 加锁排队。限流---限流算法

(1) 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个 key 只允许一个线程查询数据和写缓存，其他线程等待。

简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去 load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如 Redisde SETNX 或者 Memcache 的 ADD）去 set 一个 mutex key，当操作返回成功是，在进行 koad db 的操作应设缓存；否则，就重试整个 get 缓存的方法。

(2) SETNX ,是【SET IF NOT EXISTS]的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果。

2. 数据预热

可以通过缓存 reload 机制，预选去更新缓存，再即将发生大并发访问前手动触发加载缓存不同的 key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

缓存击穿

我们的业务通常会有几个数据会被频繁地访问，比如秒杀活动，这类被频地访问的数据被称为热点数据。

如果缓存中的某个热点数据过期了，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库很容易就被高并发的请求冲垮，这就是缓存击穿的问题。

缓存击穿跟缓存雪崩很相似，你可以认为缓存击穿是缓存雪崩的一个子集。

解决方案：

（1）互斥锁方案，保证同一时间只有一个业务线程更新缓存，未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。

（2）不给热点数据设置过期时间，由后台异步更新缓存，或者在热点数据准备要过期前，提前通知后台线程更新缓存以及重新设置过期时间；

缓存穿透

当发生缓存雪崩或击穿时，数据库中还是保存了应用要访问的数据，一旦缓存恢复相对应的数据，就可以减轻数据库的压力，而缓存穿透就不一样了。

当用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据，没办法构建缓存数据，来服务后续的请求。那么当有大量这样的请求到来时，数据库的压力骤增，这就是缓存穿透的问题。

解决方案

（1）非法请求的限制

当有大量恶意请求访问不存在的数据的时候，也会发生缓存穿透，因此在 API 入口处我们要判断求请求参数是否合理，请求参数是否含有非法值、请求字段是否存在，如果判断出是恶意请求就直接返回错误，避免进一步访问缓存和数据库。

（2）缓存空值或者默认值

当我们线上业务发现缓存穿透的现象时，可以针对查询的数据，在缓存中设置一个空值或者默认值，这样后续请求就可以从缓存中读取到空值或者默认值，返回给应用，而不会继续查询数据库。

（3）使用布隆过滤器快速判断数据是否存在，避免通过查询数据库来判断数据是否存在

我们可以在写入数据库数据时，使用布隆过滤器做个标记，然后在用户请求到来时，业务线程确认缓存失效后，可以通过查询布隆过滤器快速判断数据是否存在，如果不存在，就不用通过查询数据库来判断数据是否存在。

即使发生了缓存穿透，大量请求只会查询 Redis 和布隆过滤器，而不会查询数据库，保证了数据库能正常运行，Redis 自身也是支持布隆过滤器的。

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

Redis 事务

Redis 事务可以一次执行多个命令，（按顺序地串行化执行，执行中不会被其他命令插入，不许加塞）

事务简介

Redis 事务可以一次指定多个命令（允许在一个单独的步骤中执行一组命令），并且带有以下两个重要的保证：

批量操作在发送 EXEC 命令前被放入队列缓存。

收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余命令依然被执行。

在事务执行过程中，其他客户端提交的命令请求不会插入到事务执行命令列中。

1. Redis 会将一个事务中的所有命令序列化，然后按顺序执行
2. 执行中不会被其它命令插入，不许出现加赛行为

常用命令

DISCARD:
 取消事务，放弃执行事务块内的所有命令。
EXEC :
 执行所有事务块内的命令。
MULTI:
 标记一个事务块的开始。
UNWATCH:
 取消watch命令对所有key的监视。

WATCH KEY [KEY ...]
 :监视一个(或多个)key，如果在事务执行之前这个(或这些)key被其他命令所改动，那么事务将被打断。

一个事务从开始到执行会经历以下三个阶段：

1、开始事务。

2、命令入队。

3、执行事务。

示例 1 MULTI EXEC

转账功能，A 向 B 转账 50 元

一个事务的例子，它先以 MULTI 开始一个事务，然后将多个命令入队到事务中，最后由 EXEC 命令触发事务

图片

1. 输入Multi命令开始，输入的命令都会一次进入命令队列中，但不会执行
2. 知道输入Exce后，Redis会将之前的命令队列中的命令一次执行。

示例 2 DISCARD 放弃队列运行

1640334900821

1. 输入MULTI命令，输入的命令都会依次进入命令队列中，但不会执行。
2. 直到输入Exec后，Redis会将之前的命令队列中的命令依次执行。
3. 命令队列的过程中可以使用命令DISCARD来放弃队列运行。

示例3 事务的错误处理

事务的错误处理：

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

图片

由于之前的错误，事务执行失败

Redis 事务总结

Redis 事务本质：一组命令的集合！一个事务中的所有命令都会被序列化，在事务执行过程中，会按照顺序执行！一次性，顺序性，排他性！执行一些列的命令！

Redis 事务没有隔离级别的概念！

所有的命令在事务中，并没有直接被执行！只有发起执行命令的时候才会执行！Exec

Redis 单条命令保存原子性，但是事务不保证原子性！

Redis 事务其实是支持原子性的！即使 Redis 不支持事务回滚机制，但是它会检查每一个事务中的命令是否错误。