总结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：子进程在重写期间，如果进行了数据修改，就会出现数据不一致，
  方案3：aof_rewrite_buf，从fork子进程起后面写入的命令也copy到重写缓存区，等子线程重写结束，将重写缓存区的命令写入AOF

五、Redis主从同步

• 主节点负责写，从节点负责读
• 当从节点宕机时，主节点发送RDB文件给从节点进行数据同步
• 为了进行快速同步，主节点中设置缓存区，并设置复制偏移量（目的：确认缺失的信息范围）

六、Redis哨兵机制

解决：主节点宕机问题，实现高可用

• sentinel哨兵负责统筹协调，监控主节点（定时去确认其响应能力）
• 哨兵集群（规定数量认定主节点客观下线）
• 故障转移：选择新的主节点（规则：复制偏移量最大的节点），主节点进行数据同步，将原主节点改为从节点

七、Redis集群

加入集群：需要和其中一个Redis（IP+端口）建立联系（类似TCP三次握手），Redis原集群内部进行同步确认
数据存储任务分配：槽位slot（类似哈希表），内存空间大的占更多的槽位。

信息同步：redis节点之间要同步自己所负责的槽位信息
问题1：数据量大，
方案1：每个槽位用1bit表示，自己负责的为1，不负责的为0

问题2：定位节点麻烦
方案2：用一个超大的数组存储每个槽位，空间换时间

struct clusterNode *slots[16384/8];

集群工作：确认请求的位置是不是自己负责，如果不是则返回一个moved错误给请求端，同时发出对应的负责节点的IP和端口