思维导图
关于缓存
redis缓存存在的问题
| 问题 | 描述 | 解决方案 |
|---|---|---|
| 缓存穿透 | 缓存和数据库都没有数据，查不到数据不写入缓存，导致流量大时，DB压力也大 | 查不到的请求参数也写入缓存中/布隆过滤器 |
| 缓存击穿 | 缓存中没有但数据库中有的数据，由于并发高导致的DB瞬间压力增大 | 加锁，限流，或者设置热点数据不过期并定时刷新 |
| 缓存雪崩 | 数据大批量过期，而查询数据量巨大，引起数据库压力过大 | 过期时间设置随机 |
| 缓存污染 | 只会被访问一次的数据，被访问完后，长久的留存在缓存中 | 缓存淘汰策略 |
| 缓存和数据库一致性 | 数据更新时，存在缓存和数据库数据不一致 | - |
如何解决缓存一致性问题
- 先删除缓存，再更新DB，并将缓存更新任务强制加入串行线程池
- 在缓存中查询不到数据时，查询数据库，并将缓存更新任务去重后加入串行线程池
- 需要保证缓存更新任务能够及时被处理，否则将导致DB压力增大。
最大缓存设置多大
建议把缓存容量设置为总数据量的 15% 到 30%，兼顾访问性能和内存空间开销
缓存淘汰策略关键词说明
思维导图
- noeviction 不淘汰
- volatile 淘汰对象为设置了过期时间的数据
- allkeys 淘汰对象为所有数据
- random 随机策略
- ttl 越早过期的数据优先
- lru 即Least Recently Used 最久未被使用策略
- lfu 最不经常使用策略
LRU实现原理
随机选出n个数，然后根据最后一次使用时间，将最久未使用的淘汰掉
如何解决mysql和redis的一致性问题
- 读时，若缓存无数据，则添加缓存更新任务到线程池（经过去重）
- 写时，修改DB，并添加缓存更新任务到线程池（强制）
- 缓存更新任务执行时，需先获取分布式锁。
关于哨兵模式
哨兵实现了什么功能
- 监控
- 自动故障转移
- 配置提供者
- 通知
哨兵模式的组建
哨兵模式的组建
哨兵如何同从库建立连接
哨兵同从库建立连接
哨兵集群的leader有什么用
- 执行主从切换
哨兵模式的选举
- 拿到半数以上的赞成票；
- 拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值
哨兵的主库下线判定
如果主观下线的赞同票数大于等于哨兵配置文件中的 quorum 值时则可判定主库客观下线。
哨兵的选出新主库
- 过滤掉不健康的从节点（掉线，断线，无回应）
- 选择配置优先级最高的
- 选择复制最完整的从节点
哨兵模式不可用情况
- 存活的哨兵数不足半数（包括半数）的时候
- 存活的哨兵数不足哨兵配置文件中的quorum值
关于集群
哈希槽
Redis-cluster中有16384(即2的14次方）个哈希槽，每个key通过CRC16校验后对16383取模来决定放置哪个槽。Cluster中的每个节点负责一部分hash槽（hash slot）
如何将多个不同的key分配到相同的哈希槽中
redis cluster可以使用{}指定部分字符被用来计算放入哪个哈希槽。
将 node 标记为 FAIL（下线） 的条件
半数以上的主节点将某主节点标记为PFAIL（疑是下线）时，标记为FAIL并广播
故障恢复的流程
- slave发现自己的master变为FAIL
- 广播Failover Request信息
- 其他节点收到该信息，只有master响应
- 超过半数的master同意后变成新Master
- 广播通知其他集群节点
扩容的流程
- redis-trib add node添加新节点到集群
- redis-trib.rb reshard将部分哈希槽迁移到新节点并广播
redis cluster不可用的情况
- 集群主库半数宕机（无论是否从库存活）
- 集群某一节点的主从全数宕机。
已经有哨兵模式了为什么还需要集群模式？
哨兵模式只扩展了读并发能力，但是写能力无法进行扩展。
关于锁
redisson原理
redisson原理图
锁续期
- 锁存在，在线程池中加入延时任务。
- 延时任务中判断锁不存在时，直接返回
- 锁存在，异步重设锁的过期时间
- 设置成功，转第1步重新加入延时任务
redisson加锁的数据结构（hash）
"锁名称":{
"uuid:threadId": 重入次数
}
//生存时间30秒
redisson是如何防止死锁的
为锁设置存活时间
什么是RedLock
redis锁存在数据丢失的情况，于是提出了RedLock锁，有n个互相独立的redis节点，客户端向这n个节点请求锁，当在超过半数的节点上请求到锁的时候，才算真正获取到了锁。
其他
使用场景
- setnx，可用于分布式锁
- 读写速度，可用于分布式缓存
- 键值有效时间，可用于延时/限时操作
- 原子性，可用于计数器
- List，可用于分布式队列
redis 为什么快
- 基于内存实现
- 执行指令时使用单线程，没有线程切换的损耗
- IO多路复用技术，避免上下文切换
redis6.0前真的是单线程的吗？
io,命令执行都由一个顺序串行的主线程处理，但是严格意义上并不是单线程的，除了主线程外还存在无用链接的释放，脏数据的清理等其他线程
redis6.0之前为什么不用多线程处理？
- CPU不存在贫瘠，主要受限于内存和网络
- 使用单线程减少了线程切换的消耗
- 使用单线程使的系统更简单
redis6.0为什么要引入IO多线程
- 就redis整体来说，命令的执行不会占用太多CPU，而redis网络IO消耗还有优化的空间
- 引入IO多线程可以充分利用服务器 CPU 资源分摊 Redis 同步 IO 读写负荷
- 据测试，引入IO多线程后性能能提高一倍。
redis的内部架构
多路复用iO+单线程命令处理
redis数据可能丢失的原因
主库执行请求指令并回复client的同时，会异步的将请求同步给它的从库。如果写请求未到达从库时，主库宕机，那么这条写请求就丢失了。
RDB、AOF、混合持久化方式优缺点
| 持久化方式 | 说明 | 优点 | 缺点 |
|---|---|---|---|
| RDB | 快照方式 | 恢复速度快于AOF | 实时性不够，执行成本较高 |
| AOF | 增量方式，先执行命令后写日志 | 不会堵塞写操作 | 存在丢失数据的风险，写磁盘频繁 |
| 混和 | RDB+AOF | - | - |
RDB的过程
- Redis调用fork创建一个子进程。（父子进程共享内存）
- 子进程负责将数据写入一个临时文件，父进程则继续处理数据库读写请求。
- 完全写入成功后，调用rename将新的RDB文件替换原来的RDB文件。
redis 事务的重要指令说明
- MULTI ：开启事务，redis会将后续的命令逐个放入队列中，然后使用EXEC命令来原子化执行这个命令系列。
- EXEC：执行事务中的所有操作命令。
- DISCARD：取消事务，放弃执行事务块中的所有命令。
- WATCH：监视一个或多个key,如果事务在执行前，这个key(或多个key)被其他命令修改，则事务被中断，不会执行事务中的任何命令。
- UNWATCH：取消WATCH对所有key的监视。
单机redis的QPS能达到多少
普通机器能达到万级别的QPS，可以使用redis-benchmark性能测试工具。
如何查找出redis中的dakey
-rdb_bigkeys工具，分析RDB文件，可指定key大小
- redis-cli --bigkeys 只能查找出五种类型中最大的key
热key的影响和处理
- 热key指几十万的请求访问固定key
- 影响：压垮redis缓存系统
- 方案：客户端监控热key，动态通知业务系统采用本地缓存存储热key。
