Redis 关键点思维导图

跳表

跳表逻辑(图片来自维基百科)

跳表有序的组织、保存元素,增删改查操作的时间复杂度为 O(logN),空间复杂度为 O(N),跳跃表在 Redis 的唯一作用,就是实现有序集数据类型.

• 相比红黑树,增删时不用复杂的旋转变色操作,仅修改有限的几个节点

• 相比 B+树,每个节点都有相应数据,不需要一定访问到叶子节点

故障

雪崩

多个热点 key 同时失效,每个 key 到请求量不大,大量 key 对应的请求并发访问,从缓存获取不到数据打到数据库,数据库能够承受的并发访问量有限容易宕机,甚至进一步导致系统阻塞请求过多造成崩溃

解决

• 为每个 key 失效时间增加随机值,防止 key 同时失效

• 热点 key 永存,仅做修改,若需要删除,值改为 null 等标志

• 大量相同 key 的请求,只允许少量请求打到数据库,其他请求阻塞等待访问缓存

击穿

少量 key 失效,每个 key 的请求量巨大,从缓存获取不到数据打到数据库,数据库能够承受的并发访问量有限容易宕机,甚至进一步导致系统阻塞请求过多造成崩溃

解决

• 热点 key 永存,仅做修改,若需要删除,值改为 null 等标志

• 大量相同 key 的请求,只允许少量请求打到数据库,其他请求阻塞等待访问缓存

穿透

大量请求不存在的 key,穿过缓存,数据库全量查询不到数据,数据库扛不住大量全量查询请求

解决

• 使用布隆过滤器,对不存在的 key 进行检测,能够保证不存在,不能保证一定存在

• 对请求 key 进行检查,不合法 key 的请求在接口处直接返回

• 在缓存中设置 key,数据库不存在的 key 在第一次请求后,在缓存中建立 key-null 键值对

持久化

AOF

通过写操作日志进行数据恢复

三种日志追加模式:

• always -> 每次有写操作就将写操作命令写入缓存并同步到磁盘,性能印象比较大

• everysec -> 每隔一秒同步一次缓存到磁盘,数据有可能丢失 1s

• no -> 每次有写操作命令就写入缓存,同步操作交由操作系统自动执行

AOF 文件重写:

如果所有写操作都追加到文件中,将造成文件很大,会有很多重复和冗余数据

• fork 新到子线程进行相关操作

• 重写期间,新的写操作命令也会缓存到新的缓冲区,也就是同时存在两个缓冲区,防止重写失败

• 当重写完成,子线程发送信号给主进程将新缓冲区数据追加到重写文件中

• 重写文件覆盖原日志文件,主线程暂时阻塞

优势

数据丢失少,甚至不丢失

AOF 只是追加日志文件,对服务器影响更小

劣势

日志文件体积大,存在重复和冗余数据

恢复速度慢

RDB

通过快照进行数据恢复

通过中配置文件中配置多少秒有多少修改操作来设置自动执行快照备份,如果设置的时间太短,可能会造成快照备份频繁,影响性能,如果设置的时间太长,可能会造成数据的大量丢失

运行过程:

• 创建子线程

• 创建临时文件,将数据备份到临时文件

• 覆盖磁盘上的 RDB 文件

优势

数据格式更紧凑,体积相比 AOF 文件小很多

恢复速度快

劣势

数据丢失相对 AOF 更多

使用 save 命令会造成服务器阻塞

开启后需要两倍的快照文件空间,包括临时 RDB 文件和磁盘 RDB 文件

主从

使用 slaveof 命令设置主从关系

当主节点宕机,从节点不会自动转换身份,主节点重新上线,继续当主节点

发起主从请求后,直接从主节点获取 RDB 文件,之后每次有写操作都会发送给从节点

可以设置多级主从节点

可用于读写分离,写主节点,读从节点

哨兵

哨兵是单独开启的服务 redis-sentinel

当主节点下线,哨兵系统给各个节点评分,得分最高的设为新主节点,其他从节点执行主从命令到新主节点

如果老主节点重新上线,会变成从节点,不会拿回原来的身份