总结Redis的原理

一、为什么要使用Redis

缓解数据库访问压力
mysql读请求进行磁盘I/O速度慢，给数据库加Redis缓存（参考CPU缓存），将数据缓存在内存中，省略了I/O操作

二、Redis数据管理

2.1 redis数据的删除

定时删除+惰性删除+内存淘汰
问题1：内存也是有空间限制的
方案1：加超时时间
问题2：超时数据量大，无法一次性删除
方案2：随机算法删除（惰性删除）
问题3：有些超时数据运气好，一直没有被随机匹配到
方案3：在查询时判断是否过期，确认为过期的数据被动式触发删除
问题4：没有被随机删除也没有被查询的数据越来越多
方案4：内存淘汰策略
在这里插入图片描述

2.2 特殊缓存处理

缓存穿透：查询不存在的数据

方案：缓存空结果null+过期时间

缓存雪崩：大量缓存同时失效（大量不同的请求打到数据库）

方案：原有失效时间上增加随机值，即过期时间均匀分布+热点数据永不过期

缓存击穿：超高并发访问一个正好失效的Key（大量相同的请求打到数据库）

方案：加锁（用户出现大并发访问的时候，在查询缓存的时候和查询数据库的过程加锁，只能第一个进来的请求进行执行，当第一个请求把该数据放进缓存中，接下来的访问就会直接集中缓存）
热点数据永不过期，不设置热点key的失效时间

2.3 热点key

热key：在极短的时间内访问频次非常高的key

2.3.1 如何定位热点key？

提前预测

凭业务经验

实时收集

独立的热key检测系统：将该SDK引入到应用系统
客户端收集：Redis服务器有专门的客户端工具SDK（Redisson），可以对其进行改写封装（理解：二次开发，缺点：代码有入侵性，维护成本高，存在语言异构和版本升级问题），在发送请求前进行收集采集，并上报到统一的服务进行聚合计算。
代理层收集：如果Redis的请求都经过代理的话，考虑改写proxy代码收集
Redis定时扫描：使用Redis的自带命令-Hotkeys参数
Redis节点抓包：通过tcpdump抓取一段时间内的流量并上报，然后由一个外部的程序去解析并计算（缺点：流量高时抓包数据量过大，负担大）

2.3.2 解决方案

本地缓存（guava cache或caffeine）
发现热点key后将其加载到JVM中，不用到DB或Redis中查询

理解：
1 请求访问热点key，先经过负载均衡器，到达Nginx集群，
2 再由Nginx通过负载均衡到达应用网关，
3 网关转发到后端微服务，
4 准备热key检测系统
- 1 管理后台dashboard：管理热key的规则，如userId，活动id，以及可视化。
- 2 注册中心：管理分布式服务集群。
- 3 实时计算程序：根据前端传来的key。
- 4 SDK：用于接入外部系统。
- 由注册中心将这4块进行连接互通
5 计算得到的热key通过SDK传入系统并写入本地缓存，
6 请求访问本地缓存，如果存在热点key，则读取Redis并写入本地缓存，
7 此时，前端再次访问时就可以直接从本地缓存拿到数据
冗余存储备份key
设计思想：将热key分成不同的小key（比如key拼接节点ID），存储在不同的Redis节点上，降低数据的倾斜，通过小key分流，分散请求到Redis节点，
将热点key拼接节点ID，去当前访问的Redis判断是否有值，如果没有则读取数据库，存入Redis并返回数据
限流熔断（兜底方案）
限流（Nginx-集成lua脚本插件、网关、微服务-hystrix或sentinel对服务接口限流）

三、Redis为什么这么快

Redis基于内存，内存的访问速度是磁盘的上千倍
Redis内置了多种优化后的数据结构实现，性能高
Redis基于reactor模式开发了一套高效的事件处理模型（单线程事件循环，IO多路复用，类似netty网络通信）

四、Redis的备份机制

Redis数据持久化

RDB：在指定的时间间隔内生成数据集的时间点快照（理解：数据备份，不同时间段的数据都放在一个RDB文件中）
问题：数据丢失。如果 Redis 宕机，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。
AOF：（append-only file，追加操作的文件）记录服务器执行的所有写操作命令（理解：参考了MySQL的Binlog日志），命令会暂存在Redis的aof_buf中，从缓存中写入AOF。
在服务器启动时，通过重新执行这些命令来还原数据集
问题1：命令多
方案1：指令合并
问题2：耗时间
方案2：fork出子进程进行处理指令合并
问题3：子进程在重写期间，如果进行了数据修改，就会出现数据不一致，
方案4：aof_rewrite_buf，从fork子进程起后面写入的命令也copy到重写缓存区，等子线程重写结束，将重写缓存区的命令写入AOF