首页  思维导图  详情

Redis知识总结及常见面试问题

2021-04-06 16:04:01   0  举报





AI智能生成

redis知识总结、redis面试

redis面试

redis

作者其他创作

大纲/内容

Redis 发布订阅

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

内存淘汰机制

noeviction

永不过期，当内存使用达到阈值的时候，所有引起申请内存的命令会报错

allkeys-lru

在主键空间中，优先移除最近未使用的key

volatile-lru

在设置了过期时间的键空间中，优先移除最近未使用的key默认值）

allkeys-random

在主键空间中，随机移除某个key

volatile-random

在设置了过期时间的键空间中，随机移除某个key

volatile-ttl

在设置了过期时间的键空间中，具有更早过期时间的key优先移除

同步机制

全量同步

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份

配置好主从后，无论slave是初次还是重新连接到master, slave都会发送PSYNC命令到master。如果是重新连接，且满足增量同步的条件，那么redis会将内存缓存队列中的命令发给slave, 完成增量同步。否则进行全量同步

增量同步

Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

Redis集群

Redis Sentinel(哨兵模式)

Redis-Sentinel(哨兵模式)是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自懂切换。

Redis Cluster

Redis Cluster是Redis的分布式解决方案，在Redis 3.0版本正式推出的，有效解决了Redis分布式方面的需求

Redis 管道技术（Pipeline）

Redis 管道技术可以在服务端未响应时，客户端可以继续向服务端发送请求，并最终一次性读取所有服务端的响应。管道技术最显著的优势是提高了 redis 服务的性能。

客户端使用redis

java

spring boot直接可以使用spring-boot-starter-redis（RedisTemplate ）

Jedis：比较全面的提供了Redis的操作特性

Redisson：促使使用者对Redis的关注分离，提供很多分布式相关操作服务，例如，分布式锁，分布式集合，可通过Redis支持延迟队列。官方推荐使用 Redisson。

Lettuce：主要在一些分布式缓存框架上使用比较多

StackExchange.Redis

Redis实现分布式锁

加锁实际上就是在redis中，给Key键设置一个值，为避免死锁，并给定一个过期时间。 SET lock_key random_value NX PX 5000

解锁的过程就是将Key键删除，为了保证解锁操作的原子性，我们用LUA脚本完成这一操作。先判断当前锁的字符串是否与传入的值相等，是的话就删除Key，解锁成功。

这类锁最大的缺点就是它加锁时只作用在一个Redis节点上，即使Redis通过sentinel保证高可用，如果这个master节点由于某些原因发生了主从切换，那么就会出现锁丢失的情况

Redis高级分布式锁:Redlock

redisson已经有对redlock算法封装

<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.3.2</version>
</dependency>

Redis 是完全开源免费的，遵守 BSD 协议，是一个高性能的 key-value 数据库。

优势

性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s

丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。

原子性支持事务 – Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。

丰富的特性 – Redis还支持 publish/subscribe, 通知, 按key设置过期时间，过期后将会自动删除

数据类型

string（字符串）

string 类型是 Redis 最基本的数据类型，string 类型的值最大能存储 512MB。SET命令->jedis.set(key, value)

hash（哈希）

HMSET命令 jedis.hset(key, Map<String, String>)

适合存储对象,并且可以像数据库中update一个属性一样只修改某一项属性值

list（列表）

lpush 在key对应 list的头部添加字符串元素

rpush在key对应 list 的尾部添加字符串元素

linsert 在key对应 list 的特定位置之前或之后添加字符串元素

lset设置list中指定下标的元素值(下标从0开始)

lrem从key对应 list 中删除 count 个和 value 相同的元素

set（集合）

Redis 的 Set 是 string 类型的无序集合。集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。

sadd命令

zset(有序集合)

Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。 zset的成员是唯一的,但分数(score)却可以重复。

zadd命令

BitMap

BitMap 就是通过一个 bit 位来表示某个元素对应的值或者状态, 其中的 key 就是对应元素本身，实际上底层也是通过对字符串的操作来实现。Redis 从 2.2 版本之后新增了setbit, getbit, bitcount 等几个 bitmap 相关命令

Geo

Redis 的 GEO 特性在 Redis 3.2 版本中推出，这个功能可以将用户给定的地理位置信息储存起来，并对这些信息进行操作

HyperLogLog

Redis 的基数统计，这个结构可以非常省内存的去统计各种计数，比如注册 IP 数、每日访问 IP 数、页面实时UV）、在线用户数等

PFADD、PFCOUNT、PFMERGE

Redis持久化

RDB持久化

触发机制

手动触发（save、bgsave命令）

save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用

bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短

自动触发RDB的持久

使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave

RDB的优点

RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。

性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis的高性能)

相对于数据集大时，比 AOF的启动效率更高

RDB的缺点

RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。

RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。

AOF持久化

开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。保存路径同 RDB持久化方式一致，通过dir配置指定。AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）

AOF优点

AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。

AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损

AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。

AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。

AOF缺点

对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大

AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

缓存常见问题

缓存雪崩

由于原有缓存失效，新缓存未到期间(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

大多数系统设计者考虑用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。还有一个简单方案就时讲缓存失效时间分散开

缓存穿透

缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴。

缓存预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

缓存更新

除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种:（1）定时去清理过期的缓存；（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）

Redis 事务

Redis 事务可以一次执行多个命令，并且带有以下三个重要的保证：批量操作在发送 EXEC 命令前被放入队列缓存。收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

一个事务从开始到执行会经历以下三个阶段：开始事务、命令入队、执行事务

Redis 事务相关的命令有哪几个：MULTI、EXEC、DISCARD、WATCH

DISCARD

取消事务，放弃执行事务块内的所有命令。