文章目录试题一Redis 缓存机制与主从复制选做题1. 题目背景2. 主从复制全量与增量题目描述答案与解析3. 持久化机制题目描述答案与解析试题二分布式架构与分布式锁试题四1. 题目背景2. 问题 1数据库锁 vs Redis 锁题目描述答案与解析3. 问题 2死锁场景与其它锁题目描述答案与解析4. 问题 3Redis Zset 常用命令题目描述答案与解析试题一Redis 缓存机制与主从复制选做题1. 题目背景Redis 作为高性能的键值对存储系统广泛应用于缓存、消息队列等场景。为了保证数据的高可用性和持久性Redis 提供了主从复制Replication和持久化Persistence机制。本题主要考察 Redis 的主从复制流程以及两种核心持久化方式的原理与区别。2. 主从复制全量与增量题目描述全量复制的流程图挖空填空。注意点是BGSAVE命令以及两次前后的状态同步。增量复制的流程图挖空填空。答案与解析由于原题图片未完全提供以下基于 Redis 标准主从复制机制提供标准答案流程。答案关键步骤全量复制流程Full Resynchronization连接建立从节点发送PSYNC命令。快照生成主节点执行BGSAVE命令在后台生成 RDB 快照文件。发送数据主节点将 RDB 文件发送给从节点。加载数据从节点清空旧数据加载 RDB 文件。缓存同步主节点将生成 RDB 期间接收到的写命令记录在Replication Buffer中发送给从节点保证状态一致。增量复制流程Partial Resynchronization命令请求从节点发送PSYNC runid offset汇报自己的进度。偏移量检查主节点检查offset是否在复制积压缓冲区Replication Backlog Buffer的范围内。发送增量如果命中缓冲区主节点仅发送从offset之后缺失的数据命令。详细分析为什么全量复制需要BGSAVE全量复制需要一份完整的数据快照。SAVE命令会阻塞主线程导致服务不可用而BGSAVE会fork克隆 一个子进程在后台处理最大程度减少对主线程的阻塞。为什么全量复制后还需要同步“缓冲区”RDB 生成和传输是需要时间的。在这段时间内主节点依然在接收新的写请求。如果只给 RDB从节点得到的数据就是“几秒钟前”的旧状态。因此必须把这段时间积压的写命令Replication Buffer发给从节点才能追平进度。增量复制的关键Backlog Buffer这是一个固定大小的环形缓冲区。如果从节点断开时间太长导致需要的 offset 已经被覆盖了那么增量复制就会失败不得不退化为全量复制。考点Redis 主从复制原理、PSYNC 协议、BGSAVE、复制积压缓冲区3. 持久化机制题目描述请介绍两种持久化方法RDB 和 AOF说明优缺点。答案与解析答案1. RDB (Redis Database) - 快照模式原理定时将内存中的数据生成二进制快照文件默认dump.rdb。优点文件紧凑二进制压缩文件体积小。恢复速度快直接加载二进制数据启动快。适合灾备方便备份和远程传输。缺点数据丢失风险两次快照之间的数据可能会丢失例如每 5 分钟备份一次宕机时可能丢 5 分钟数据。性能开销BGSAVE需要fork子进程在大内存场景下可能短暂阻塞主线程。2. AOF (Append Only File) - 日志模式原理记录所有的写操作命令以文本格式追加到文件中默认appendonly.aof。优点数据安全性高支持秒级everysec甚至同步持久化最多丢 1 秒数据。可读性强保存的是人类可读的操作命令误删数据后可能通过编辑文件恢复。缺点文件体积大记录的是流水账比 RDB 文件大得多。恢复速度慢重启时需要“重放”所有命令速度慢。需要重写长期运行后文件会膨胀需要定期执行BGREWRITEAOF进行瘦身。核心对比总结特性RDB (快照)AOF (日志)持久化方式二进制数据快照文本命令追加文件体积小紧凑大记录所有操作恢复速度快 ⚡慢 需重放命令数据安全性低可能丢一段时间数据高最多丢 1 秒适用场景备份、灾难恢复数据一致性要求高考点Redis 持久化、RDB/AOF 优缺点对比、RPO (恢复点目标) 权衡试题二分布式架构与分布式锁试题四1. 题目背景某公司计划打造一个集商品展示、在线下单、支付结算及物流配送为一体的综合性电商平台。由于在电商业务中高并发访问和数据处理是关键挑战特别是在订单处理环节当多个用户同时下单或支付时系统需确保订单状态的准确性和一致性。为此架构师李工提出采用分布式架构和高效的数据库系统以应对高并发场景并引入分布式锁机制来保障订单状态的正确更新防止数据冲突和错误。此外项目还将注重用户体验通过精准营销和个性化推荐增加用户粘性。2. 问题 1数据库锁 vs Redis 锁题目描述在订单处理系统中可能需要对订单状态进行更新如从“待支付”变为“已支付”。如果多个服务实例同时处理同一个订单可能会导致订单状态不一致。使用分布式锁可以确保在同一时间内只有一个服务实例能够修改订单状态。为此架构师李工提出了采用 Redis 作为分布式锁而架构师王工提出采用数据库作为分布式锁的方案。请写出使用基于数据库的分布式锁和基于 Redis 的分布式锁的优点和缺陷。答案与解析答案1. 基于数据库的分布式锁优点实现简单直接利用数据库现有的事务或唯一索引机制。无额外依赖不需要引入新的中间件如 Redis 或 Zookeeper。适用范围广所有支持事务的数据库都通用。具有持久性锁状态存储在磁盘不易丢失。缺陷单点问题数据库是单点一旦挂掉会导致整个业务系统不可用。无失效时间如果解锁操作失败锁记录会一直存在其他线程无法获取锁死锁。非阻塞插入操作失败直接报错没有获得锁的线程需要再次触发获取操作轮询。不可重入同一线程在释放锁之前无法再次获得该锁。性能较差频繁的磁盘 IO 操作并发性能不如内存存储。2. 基于 Redis 的分布式锁优点性能好基于内存操作读写速度极快适合高并发场景。容错性好Redis 支持集群部署Sentinel 或 Cluster避免单点故障。支持自动过期可以设置 Key 的过期时间防止死锁。缺陷死锁风险如果锁的持有者崩溃且未设置过期时间或过期时间设置不当会导致无法释放锁。数据一致性问题在主从切换时如果锁数据还没同步到从库主库挂了从库升级为主库可能导致锁丢失。考点分布式锁实现方案对比、CAP 理论权衡3. 问题 2死锁场景与其它锁题目描述基于 Redis 的数据库锁也会存在死锁场景举例说明。还有哪些其它的分布式锁的类型答案与解析答案1. 死锁场景示例假设有两个进程 A 和 B它们尝试获取两个共享资源 R1 和 R2A 成功获取 R1 的锁。A 尝试获取 R2 的锁但 R2 的锁已经被 B 持有。B 在持有 R2 锁的同时继续尝试获取 R1 的锁但 R1 的锁被 A 持有。结果A 和 B 互相等待对方释放锁谁也无法继续执行导致死锁。2. 其他分布式锁类型基于 Zookeeper 的分布式锁利用临时顺序节点。基于 Etcd 的分布式锁。解析基于 Zookeeper 的分布式锁原理利用 Zookeeper 的临时顺序节点 (Ephemeral Sequential)。客户端在锁目录下创建一个临时顺序节点然后检查自己是不是序号最小的节点。如果是则获取锁如果不是则监听比自己序号小的前一个节点的删除事件。优点可靠性高CP 模型天然解决死锁客户端断开连接临时节点自动删除。缺点性能不如 Redis频繁创建删除节点压力大。基于 Etcd 的分布式锁原理利用 Etcd 的Lease (租约)和Revision (版本号)机制。客户端创建一个租约并绑定一个 Key利用 Revision 号来判断谁先创建类似 Zookeeper 的顺序节点。优点强一致性Raft 协议支持 Watch 机制监听锁释放。考点死锁产生的四个必要条件互斥、占有且等待、不可抢占、循环等待、常见分布式锁选型4. 问题 3Redis Zset 常用命令题目描述Redis Zset 常见的命令有哪些。答案与解析答案ZADD向 zset 中添加元素 (member) 和分数 (score)。ZRANGE返回指定区间里的元素按照分数升序遍历。ZREVRANGE返回指定区间里的元素按照分数降序进行遍历。ZCARD获取指定 zset 的元素个数。ZCOUNT返回分数在 min 和 max 之间的元素个数。ZRANK升序返回指定元素的下标排名。ZREVRANK降序返回指定元素的下标排名。ZSCORE查询指定元素的分数。核心概念解释Sorted Set (有序集合)通俗类比考试排行榜Member (元素) 学生名字张三、李四Score (分数) 考试成绩98, 85ZADD 录入成绩。ZRANGE 从低分到高分念名字倒数排名。ZREVRANGE 从高分到低分念名字光荣榜。ZRANK 查你是第几名。详细分析Zset 是 Redis 中非常重要的数据结构底层通常由跳跃表 (SkipList)或压缩列表 (ZipList)实现。它既能通过 Key 快速查找像 HashMap又能自动排序像 TreeSet。常用于排行榜、延迟队列等场景。考点Redis 数据类型命令、Zset 应用场景