分布式redis面试思路俩点 高性能 高并发
高性能
1.存储在内存 所以速度快
2. 线程模型 io多路复用 监控多个客户端socket 放入队列里面 只是文件分发机制是单线程的 处理队列中的数据 根据不同类型 分发给不同处理器 后面处理的过程 也是多线程的
3. 内存回收机制 ==定期+懒惰 ==
4. 持久化 rdb快照+aof 增量同步 配置 开启 appendfsync rewrite 压缩aof文件
5.常用数据结构 编码模式
高并发 单机-集群 主从同步
全量复制 初始化阶段 从节点 主动拉取 主节点的 快照 待参数 runid offset 发现 runid没有 全量
增量复制 维护 offset 复制偏移量
加入 哨兵集群 来监控master节点 防止一个误判 多个的话 判断 master节点挂掉 就内部选举出一个领导者 然后进行主从切换
使用log日志记录操作
集群里面如何存数据
- solt 槽位 16384个 平均分配 比如6个redis 3主3从 3个主 就会分配这16384个
写的数据 根据 2.hash 算法 3.取模 对16348 然后判断出 在哪个槽位 然后就到哪个 主
虽然数据只存在 相应槽位的 主 和对应的从
但是 服务集群俩俩通信 集群里面任何一个服务器 其他的也都可以查出来
问题： 双写 不一致 穿透雪崩 并发竞争
双写不一致 弱一致性（最终一致性） 强一致性 （性能不好有锁 违背使用redis）
1：先删缓存在删数据库 那就 延迟双删 数据库操作完在删除一次缓存 至多一次
2： 先删数据库在删缓存
存在删除缓存失败的情况 通过MQ重试发送
1.缓存击穿 1 热门数据 过期永不过期 2 或者 互斥锁 拿到数据 刷新缓存
2.缓存雪崩 大面积失效 1 过期随机 2 或者 互斥锁 3 多级缓存 4 集群
3.缓存穿透 恶意没有的数据请求 1.第一次请求后 设置空缓存 2. 参数校验拦截 3 布隆过滤器
redis分布式锁 分段 CAP
Redis分布式锁核心原理与分段优化
基础实现原理
原子加锁：通过 SET key unique_value NX PX timeout 命令实现原子性加锁，其中 NX 表示键不存在时设置，PX设置过期时间。
唯一标识：unique_value（如UUID）用于区分不同客户端，防止其他线程误删锁。
锁续期：通过“看门狗”机制（守护线程定期续期）解决业务执行时间超过锁超时的问题。
示例代码（Redisson）：
分段锁优化
问题背景：高并发场景下（如秒杀），单一锁导致性能瓶颈。
解决方案：
分段加锁：将资源（如库存）拆分为多个段（如100段），每个段独立加锁。
路由算法：通过用户ID哈希取模确定操作的分段（如 hash(user_id) % 100）。
优势：锁粒度细化后，冲突减少，吞吐量提升10-100倍。
RedLock算法
适用场景：Redis集群环境下避免单点故障导致的锁失效。
核心流程：
向多个独立Redis节点（N≥5）依次申请锁；
计算耗时，若超过半数节点加锁成功且总耗时<锁超时时间，则认为成功。
缺点：实现复杂，性能低于单节点锁。
二、CAP原则在分布式锁中的权衡
CAP理论解读
一致性（C）：所有节点数据实时一致；
可用性（A）：服务始终响应；
分区容错性（P）：容忍网络分区故障。
Redis分布式锁的CAP选择
偏向AP：Redis集群默认异步复制，主节点故障时可能丢失锁（但通过RedLock可提升一致性）。
对比Zookeeper：Zookeeper偏向CP（同步提交保证一致性，但牺牲可用性）。
实际应用建议
业务容忍度：若允许短暂不一致（如非金融场景），优先Redis锁；
强一致性需求：使用Zookeeper或数据库锁
