Redis知识脑图

@startmindmap
* Redis
** 基础
*** Redis应用
**** 缓存
***** 最广泛应用
**** 计数器
***** 天然支持，记录浏览量，点赞量
**** 排行榜
***** 列表和有序集合
**** 社交网络
***** 赞/踩、粉丝、共同好友、推送、下拉刷新
**** 消息队列
***** 发布订阅和阻塞队列
**** 分布式锁
*** 数据结构
****[#Orange] 字符串
***** 实际可以字符串，数字，二进制，最大不超过512MB
***** 典型应用：缓存，计数，共享Session，限速
****[#Orange] 哈希
***** 键值对结构
***** 典型应用：缓存用户信息，缓存对象
****[#Orange] 列表
***** 可充当栈和队列
***** 典型应用：消息队列，文章列表
****[#Orange] 集合
***** 不重复，无序
***** 典型应用：标签，共同关注
****[#Orange] 有序集合
***** 不重复，根据权重排序
***** 典型应用：用户点赞统计，用户排序
*** Redis快的原因
****[#lightgreen] 完全基于内存操作
****[#lightgreen] 使用单线程，避免县城切换和竞态的消耗
***** Redis4.0后为多线程，后台线程处理缓慢操作
*****: Redis6.0多线程：单条命令包含读数据，解析，执行，写数据等操作，
只有读写数据在多个IO线程中，执行步骤还是在主线程中串行运行
;
****[#lightgreen] 基于非阻塞IO多路复用机制
***** select
***** poll
*****[#FFBBCC] epoll
****[#lightgreen] C语言实现，优化过的数据结构，做了大量优化
** 持久化
*** RDB
**** 把进程数据生成快照保存到硬盘
***** 手动触发
****** save：阻塞知道执行完成（线上不建议使用）
****** bgsave：fork子进程执行，只在fork时阻塞
***** 自动触发
****** save m n（m秒内n次修改自动触发bgsave）
****** 从节点要全量复制时，主节点执行bgsave发送RDB文件给从节点
****** debug reload
****** 执行shutdown时，没开启AOF则自动执行bgsave
**** 优点
***** 只有一个紧凑的二进制文件`dump.rdb`，非常时候备份、全量复制场景
***** 容灾性好，可直接拷贝到远程机器
***** 恢复速度快
**** 缺点
***** 实时性低
***** 存在兼容问题（多个Redis版本的RDB格式不兼容）
*** AOF
****:以独立日志方式记录每次写命令
重启时重新执行AOF文件中的命令
;
***** 1) 所有写入命令追加到aof_buf中
***** 2) AOF缓冲区根据策略写磁盘文件
***** 3) AOF变大时，定期重写AOF文件以压缩
***** 4) 重启时，加载AOF来恢复数据
**** 优点
***** 实时性好
***** 可通过redis-check-aof工具解决数据一致性问题
**** 缺点
***** AOF文件比RDB文件大，且恢复速度慢
***** 数据集大的时候，比RDB启动效率低
*** Redis4.0混合持久化
**** 先加载rdb的内容
**** 再重放增量AOF日志
left side
** 高可用
*** 主从：主从同步+丛丛同步
**** 作用
***** 数据冗余：热备份，持久化外的冗余方式
***** 故障恢复：主节点出问题，从节点提供服务
***** 负载均衡：配合读写分离，分担服务器负载
***** 高可用基石：是哨兵和集群的基础
**** 步骤
***** 从节点与主节点建立连接
***** ping主节点
***** 权限验证
***** 同步主节点所有数据
***** 接下来主节点持续把写命令发送给从节点
**** psync命令
***** 全量复制：初次复制，一次性发送所有数据
***** 部分复制：断点续传
**** 问题
***** 主节点故障，需手动将从节点升为主节点还需要命令其他从节点复制新的主节点
***** 主节点写能力受单机限制
***** 主节点存储能力受单机限制
*** 哨兵：解决高可用问题，自动故障转移
**** 组成
***** 哨兵节点：一个或多个，不存储数据，只监控数据节点
***** 数据节点：主从节点都是
**** 作用
***** 监控：哨兵检查主从节点是否正常
***** 自动故障转移：主节点不正常时，哨兵开始自动故障转移
***** 配置提供者：客户端初始化时，连接哨兵获取主节点地址
***** 通知：将故障转移结果发送客户端
**** 步骤
***** 定时监控
****** 每10秒，主从信息获取（拓扑结构）
****** 每2秒，哨兵信息发布，向数据节点发送主节点和哨兵信息
****** 每1秒，节点心跳检测，向主从哨兵节点发心跳
***** 主观下线：一段时间未收到心跳，哨兵任务该节点主观下线
*****:
客观下线：如果主节点主观下线，
哨兵会询问其他哨兵节点，如果
超过一定数量认为主观下线，则
哨兵判断该节点客观下线
;
*****:
领导者哨兵选举：当确认主节点
主观下线时，哨兵节点使用Raft
算法选举一个领导者进行故障转移
;
***** 故障转移
****** 选出主节点
****** 设置主节点
****** 从节点同步
****** 原主节点转从
*** 集群：进一步解决分布式问题
**** 数据分区：将数据按分区分散到多个节点，突破Redis单机内存限制
***** 节点取余分区：节点数量变化时，会导致数据迁移
***** 一致性哈希分区：哈希环，节点数量变动只影响相邻节点
***** 虚拟槽分区：数据哈希到虚拟的槽上，一个节点拥有多个槽
**** 高可用：支持主从复制和主节点自动故障转移
***** 集群设置：3主3从
****** 设置节点
****** 节点握手：Gossip协议
****** 分配槽
***** 故障转移
****** 故障发现：ping/pong，Gossip，主客观下线
****** 故障恢复：某个主节点下线，在其从节点中投票选举成为主节点
** 缓存设计
*** 缓存问题
**** 缓存击穿：并发量大的key过期，导致所有请求打在DB上
***** 加锁更新
***** 异步刷新过期时间
**** 缓存穿透：缓存和数据库都不存在待查数据，这种请求永远打在DB上
***** 缓存空值或默认值
***** 布隆过滤器
**** 缓存雪崩：大量key同时过期，导致大量请求打在DB上
***** 提高缓存可用性：集群部署，多级缓存
***** 过期时间：过期时间随机，热点数据不过期
***** 熔断降级：服务熔断，服务降级
*** 缓存数据库一致性
**** 删除缓存而不是更新缓存
**** 先更数据后删缓存
**** 保证一致性
***** 消息队列保证key被删除
***** 数据库订阅+消息队列保证key被删除
***** 延时双删：删缓存再更数据库再删缓存
***** 过期时间兜底
*** 处理热Key
**** 监控热key
***** 客户端调用redis命令时记录
***** 代理端：Codis这种基于代理的Redis分布式架构，可在代理端统计
***** Redis服务端：使用monitor命令统计
**** 处理
***** 热key打散到不同服务器
***** 加入二级缓存，提前加载热key到内存中
*** 处理大Key
**** 问题
***** 客户端耗时增加
***** 对大key进行IO时，严重占用带宽和cpu
***** redis集群数据倾斜
***** 主动删除、被动删除导致阻塞
@endmindmap