Redis深入浅出
Redis常见问题
- 缓存穿透
- 查询的数据不存在，因此缓存中也不会有，流量直接进入数据库
- 可以考虑使用布隆过滤器
- 缓存击穿
- 热点数据过期，导致大流量查询请求直接进入数据库
- 缓存雪崩
- 大批数据同时过了有效期
- 可以把过期时间设置的均匀一些，不至于同时过期，热点数据可以考虑永不过期
Redis持久化-AOF和RDB
为了解决redis进程崩溃，导致缓存数据全部消失的问题，因此数据需要持久化
RDB
-
创建一个子进程，去做整库备份生成rdb文件，周期性备份
-
因为周期性备份，容易丢数据
AOF - Append Only File
- 参考数据库binlog，生成aof文件，记录操作日志
- 先写入aof_buf，然后周期性写入aof文件
- aof重写，aof文件越来越大，需要瘦身压缩，通过指令合并的方式
- 参考rdb，fork一个子进程去做aof重写
- aof_rewrite_buf
哨兵模式
解决redis高可用问题，是对主从模式的优化
- 主从复制，若主节点挂了，需要程序员手动选择从节点升级为主节点
- 因此可以增加管理员（哨兵）专门负责统筹协调
- 一个哨兵不够，哨兵本身也需要高可用，且要为奇数个
- 哨兵发现主节点掉线后，判定为主观下线，然后需要跟其他哨兵确认，如果多个管理员都判定为下线，才能认定为客观下线，随后需要故障转移
- 故障转移流程：
- 选新主节点
- 让从节点从新主节点同步数据
- 把旧主节点改为从节点
- 新主节点选择标准
- 主动给节点设置优先级
- 断开主节点时间越短
- 复制偏移量越大
集群模式
哨兵模式只能解决高可用问题，无法解决数据量大的问题，集群模式解决哨兵模式中，每个节点都要存全量数据，空间利用效率不够高的问题
1. 集群扩容
- 抄袭TCP三次握手
- 集群内节点给新节点发送MEET信息，新节点回PONG信息，集群内节点回PING信息
- 集群内节点再将新节点信息告诉其他成员
2. 数据存储公平问题
- 学习哈希表的方式
- 划分16384的槽位slot
- 节点各自分配一定槽位
- 数据读写时，对键值做哈希计算，映射到哪个槽就由对应的节点负责
- 有一个公共数组，存储每个槽由哪个节点负责，空间换时间
- 所有槽位必须有节点负责
- 每个节点至少有一个backup，类似主从机制，解决高可用问题
