首页  思维导图  详情

Redis面试知识点全解

2021-07-11 22:20:37   4  举报





AI智能生成

Redis面试知识点全解

面试

redis

数据库

java

服务端

作者其他创作

大纲/内容

数据结构

String：简单动态字符串

Hash：压缩列表、hash表

压缩列表：类似数组，表头保存了列表长度、尾偏移量、元素个数， 头尾操作O(1)，中间元素需要遍历O(n)

Set：整数数组、hash表

Sorted Set：跳表、压缩列表

跳表：多级索引，加速查找，复杂度O(logN)

List：双向链表、压缩列表

不同操作复杂度

1.单元素操作是基础； 2.范围操作非常耗时：集合类型的遍历操作通常很耗时，推荐scan； 3.统计操作通常高效：数据结构包含了个数； 4.例外情况只有几个：压缩列表和双向链表的头尾增删很快，O(1);

日志

AOF

写机制：AOF是写后日志，与WAL相反，先写内存后写日志

日志内容：记录命令，类似于Mysql的statement格式的binlog

写策略： 1.Always：命令执行完，立马写；基本不丢失数据，但影响性能。 2.No：命令执行完，只写到内存缓冲区，由操作系统决定写时机；丢数据风险大。 3.EverySec：命令执行完，只写到内存缓冲区，每秒写入；折中【推荐用法】。

AOF日志由主线程写入，重写过程由子线程bgrewriteaof完成

AOF重写机制：多变一，多个指令合并。

解决AOF文件过大问题

原理：根据数据库里数据的最新状态，生成这些数据的插入命令，作为新的AOF日志

一处拷贝： 主线程fork子进程，将数据库最新数据(父进程的内存页表，虚实映射关系，非物理内存)拷贝到子进程， 父子进程共享内存，子进程再将最新数据转换为指令写入新文件。在之后父进程写入新日志， 才会复制一份给子进程(copyOnWrite)，写时复制； 两份日志： 一份是正在使用的AOF日志，新来的操作会写入缓冲区，另一份是重写的AOF日志，新来的操作也会写入。

RDB

内存快照，生成RDB文件： save：主线程中执行，会阻塞； bgsave：(默认)主线程fork子线程执行，fork时阻塞，子线程执行时不阻塞；

bgsave子进程由主线程fork生成，可以共享主线程的内存， fork后开始读取主进程内存数据写入RDB文件， 此时如果主线程有读取操作，没有影响，有写入操作时， 主线程会将这块数据复制一份进行修改(CopyOnWrite)， 子进程依然写入原始快照数据

频繁创建RDB快照时，fork子进程会经常阻塞主线程

最推荐的日志姿势：RDB+AOF混合模式，内存快照按照频率生成， AOF记录两次快照间的操作，下次生成RDB快照时清空AOF日志

高可靠性

数据尽量少丢失：AOF、RDB

服务尽量少中断：增加副本冗余量

哨兵机制

概念：哨兵其实就是一个运行在特殊模式下的 Redis 进程，主从库实例运行的同时，它也在运行。 哨兵主要负责的就是三个任务：监控、选主（选择主库）和通知。

哨兵使用ping命令检测它自己和主、从库的网络连接情况，用来判断实例的状态

判断下线：如果哨兵发现主库或从库对 PING 命令的响应超时了 ，哨兵就会先把它标记为“主观下线”，只有大多数的哨兵实例， 都判断主库已经“主观下线”了，主库才会被标记为“客观下线”， 【少数服从多数】

选主：筛选+打分

Redis实现分布式锁

单节点

使用Redis实现分布式锁存在的问题

加锁关键步骤：SET lock_key unique_value NX PX 10000 关键点： NX：保证获取、判断、设置为原子命令； PX：防止获取锁后在执行业务操作时无法释放，导致其他线程无法获取锁； unique_value：防止被其他线程误释放锁，所以需要加上客户端标识，在获取、判断、删除锁的时候使用lua脚本

多节点

Redlock算法实现多实例分布式锁，基本思路： 让客户端和多个独立的 Redis 实例依次请求加锁， 如果客户端能够和半数以上的实例成功地完成加锁操作， 那么就认为，客户端成功地获得分布式锁了，否则加锁失败

Redlock实现步骤： 1.客户端获取时间； 2.客户端依次向各个示例执行加锁操作，加锁操作需要设置超时时间，一般几十ms，要小于锁过期时间； 3.各个节点完成加锁操作后，判断半数以上节点完成加锁并且客户端获取锁的总耗时小于锁过期时间， 认为加锁成功，否则释放锁。

如何解决缓存与数据库的一致性

新增数据时：缓存中没有数据，此时不存在一致性问题

删除或更新数据时，因为删除缓存和更新数据库不是原子操作，所以存在一致性问题

缓存污染

volatile-random、allkeys-random、volatile-ttl 这三种并不能有效治理缓存污染问题

LRU策略：通过数据的时效性，并不能精准解决污染问题； 实现： 1.Redis 是用 RedisObject 结构来保存数据的，RedisObject 结构中设置了一个 lru 字段，用来记录数据的访问时间戳； 2.Redis 并没有为所有的数据维护一个全局的链表，而是通过随机采样方式，选取一定数量（例如 10 个）的数据放入候选集合，后续在候选集合中根据 lru 字段值的大小进行筛选。

LFU策略：通过两个维度，时效性+数据访问次数，来淘汰数据； 实现：Redis 在实现 LFU 策略的时候，只是把原来 24bit 大小的 lru 字段， 又进一步拆分成了两部分，第一部分放ldt时间戳，第二部分放counter计数。 计数器实现：并非访问一次就增加一次计数，为了避免数据短时间内都达到最大次数， 非线性递增，设置参数越大，增长越慢，根据业务调整。

Redis调优之网络中断程序+Redis进程绑定同一个CPU核

如果网络中断程序和Redis不在同一个核上，Redis就要跨核读取缓冲区数据

Redis集合统计

聚合统计：交叉并集统计

set

基数统计：统计一个集合中不重复的元素个数

HyperLogLog：有误差但是存储数量极大

排序统计

sorted set

二值状态：只有两种状态，0或1

bitmap

Redis问题排查