YAOTU INSIGHTS

Redis深度解析-下,熟悉redis所有流程

Redis深度解析-下,熟悉redis所有流程
Redis深度解析高可用、集群、缓存经典问题与运维调优标签Redis主从、Sentinel哨兵、Redis Cluster、缓存雪崩、运维调优前言上篇看懂Redis底层原理但是单机Redis存在单点故障容量和性能存在上限。生产环境几乎不会直接单机上线。下篇讲解Redis高可用方案主从复制、哨兵、集群同时重点解决开发最关心的缓存三大问题运维排查命令大key热key处理线上调优与踩坑。一、Redis高可用三种方案对比方案架构能力优缺点适用场景单机单Redis实例读写都在单机简单单点故障容量上限无高可用测试环境、非核心小业务主从Replication1主N从主写从只读数据异步复制主节点宕机无法自动切换需要人工干预读分离读多写少不需要故障自动转移配合哨兵使用Sentinel哨兵1主多从 多个sentinel进程监控节点主宕机自动故障转移选新主自动故障切换不支持分片扩容容量上限还是单机内存中小型业务数据量不大需要高可用不需要横向扩容Redis Cluster集群多个主节点每个主带从分片存储数据分散到多个master自动故障转移支持水平扩容数据分片运维复杂度高大数据量需要扩容PB级缓存场景1. 主从复制原理主节点master接收写请求异步同步数据给slave从节点复制流程全量同步psync增量同步首次建立连接执行全量同步master执行bgsave生成RDB发给slaveslave加载RDB期间新写入命令存入复制积压缓冲区全量同步完成后缓冲区后续命令持续增量推送给slave复制是异步主写完直接返回客户端不等待从同步完成存在短暂数据不一致风险复制积压缓冲区psync核心缓冲区保存最近写命令网络短暂断开不需要全量重同步。缓冲区太小会导致断线后全量同步。2. Sentinel哨兵哨兵本身是独立进程不存储数据。三大功能监控持续检测master、slave是否正常在线通知节点异常推送告警给业务自动故障转移master下线多个哨兵协商投票选出新master修改其他从节点指向新主哨兵部署要求至少3个哨兵奇数节点保证仲裁quorum防止脑裂。脑裂网络分区业务还能访问旧master继续写入两边数据不一致。解决方案min-replicas-to-write主节点少于指定数量从节点拒绝写请求。3. Redis Cluster 集群Redis Cluster是官方分布式分片方案16384个哈希槽slot所有key通过CRC16算法对16384取模映射到slot每个master负责一部分slot数据按槽分片存储每个master挂载slavemaster宕机slave自动提升为主客户端直接连接集群任意节点节点会返回重定向MOVED/ASK集群限制key不能跨槽事务multi事务只能同一个slotmget、hmget跨槽性能差不支持多数据库db仅db0扩容需要迁移slot迁移期间有少量开销二、缓存经典三大问题面试生产高频问题现象风险解决方案缓存穿透查询不存在的数据缓存没有命中请求全部打到数据库数据库压力被打垮布隆过滤器空值缓存设置短过期时间参数校验缓存击穿热点key过期大量并发请求瞬间打到数据库数据库瞬间压力飙升永不过期互斥锁提前主动刷新热点key缓存雪崩大量key同时过期Redis宕机大量请求压数据库数据库雪崩业务整体不可用过期时间加随机偏移多级缓存集群高可用限流熔断服务降级额外补充缓存与数据库双写一致性常用策略更新数据库 删除缓存推荐延迟双删。无法做到强一致缓存场景一般接受短暂最终一致性强一致性场景不适合缓存。三、Redis高频运维命令# 查看redis整体信息info# 查看内存状态info memory# 查找大key4.0redis-cli--bigkeys# 查找热key6.2 redis-cli --hotkeys# 查看key过期信息ttl key# 监控实时命令monitor# 慢查询日志slowlog get# 集群查看cluster info cluster nodes慢查询slowlog记录执行超过阈值的命令不包含网络往返时间仅命令执行耗时。四、大key、热key问题实战1. 大key大keyvalue体积巨大超大string、百万元素list/hash危害删除时主线程阻塞网络传输慢RDB持久化fork压力大。处理拆分key不要用del直接删大key使用unlink异步删除控制value大小。2. 热key热key超高QPS访问同一个key危害压力集中在单个Redis分片分片CPU打爆。处理本地多级缓存key副本分片请求限流读写分离。五、性能调优要点操作系统调优关闭THP透明大页调整tcp-backlogvm内存swappiness尽量设为0避免swap交换。网络尽量内网低延迟网络避免跨机房部署。持久化业务高吞吐场景控制RDB bgsave频率避免频繁forkAOF根据业务选择刷盘策略。命令规范禁用keys、hgetall这类O(n)慢命令用scan迭代遍历。内存合理设置maxmemory控制key数量定期清理无效过期key。集群分片均匀避免slot分配不均主从分离读请求打到从节点。六、Redis适用场景 不推荐场景✅ 推荐场景热点数据缓存减轻数据库压力计数器、限流、分布式ID排行榜ZSet、签到统计BitMap分布式锁Redlock/单机锁简单消息队列List、Stream❌ 不推荐场景海量持久化核心业务要求强事务、强一致性MySQL更合适超大单value、超多大key业务数据量巨大无法放入内存Redis是内存库磁盘只是备份下篇结语Redis不是简单的缓存工具是一套高性能内存数据库。开发常犯错误只关注业务代码忽略高可用、大key、缓存雪崩等底层风险。记住缓存设计的核心不是加速而是保护后端数据库。上篇掌握原理下篇掌握高可用、缓存问题、运维排查。理解整套体系才能写出稳定的Redis业务架构。