网硕互联帮助中心文章目录
-
- 试题一：Redis 缓存机制与主从复制（选做题）
-
- 1. 题目背景
- 2. 主从复制（全量与增量）
-
- 题目描述
- 答案与解析
- 3. 持久化机制
-
- 题目描述
- 答案与解析
- 试题二：分布式架构与分布式锁（试题四）
-
- 1. 题目背景
- 2. 问题 1：数据库锁 vs Redis 锁
-
- 题目描述
- 答案与解析
- 3. 问题 2：死锁场景与其它锁
-
- 题目描述
- 答案与解析
- 4. 问题 3：Redis Zset 常用命令
-
- 题目描述
- 答案与解析
试题一：Redis 缓存机制与主从复制（选做题）
1. 题目背景
Redis 作为高性能的键值对存储系统，广泛应用于缓存、消息队列等场景。为了保证数据的高可用性和持久性，Redis 提供了主从复制（Replication）和持久化（Persistence）机制。本题主要考察 Redis 的主从复制流程以及两种核心持久化方式的原理与区别。
2. 主从复制（全量与增量）
题目描述
答案与解析
由于原题图片未完全提供，以下基于 Redis 标准主从复制机制提供标准答案流程。
答案（关键步骤）：
全量复制流程（Full Resynchronization）：
增量复制流程（Partial Resynchronization）：
详细分析：
为什么全量复制需要 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 进行瘦身。
核心对比总结：
| 持久化方式 | 二进制数据快照 | 文本命令追加 |
| 文件体积 | 小（紧凑） | 大（记录所有操作） |
| 恢复速度 | 快 ⚡ | 慢 🐢（需重放命令） |
| 数据安全性 | 低（可能丢一段时间数据） | 高（最多丢 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 和 R2：
2. 其他分布式锁类型
- 基于 Zookeeper 的分布式锁（利用临时顺序节点）。
- 基于 Etcd 的分布式锁。
解析
-
基于 Zookeeper 的分布式锁
- 原理：利用 Zookeeper 的临时顺序节点 (Ephemeral Sequential)。客户端在锁目录下创建一个临时顺序节点，然后检查自己是不是序号最小的节点。如果是，则获取锁；如果不是，则监听比自己序号小的前一个节点的删除事件。
- 优点：可靠性高（CP 模型），天然解决死锁（客户端断开连接，临时节点自动删除）。
- 缺点：性能不如 Redis，频繁创建删除节点压力大。
-
基于 Etcd 的分布式锁
- 原理：利用 Etcd 的 Lease (租约) 和 Revision (版本号) 机制。客户端创建一个租约并绑定一个 Key，利用 Revision 号来判断谁先创建，类似 Zookeeper 的顺序节点。
- 优点：强一致性（Raft 协议），支持 Watch 机制监听锁释放。
考点： 死锁产生的四个必要条件（互斥、占有且等待、不可抢占、循环等待）、常见分布式锁选型
4. 问题 3：Redis Zset 常用命令
题目描述
Redis Zset 常见的命令有哪些。
答案与解析
答案：
核心概念解释： Sorted Set (有序集合) 💡 通俗类比：考试排行榜
- Member (元素) = 学生名字（张三、李四）
- Score (分数) = 考试成绩（98, 85）
- ZADD = 录入成绩。
- ZRANGE = 从低分到高分念名字（倒数排名）。
- ZREVRANGE = 从高分到低分念名字（光荣榜）。
- ZRANK = 查你是第几名。
详细分析： Zset 是 Redis 中非常重要的数据结构，底层通常由跳跃表 (SkipList) 或 压缩列表 (ZipList) 实现。它既能通过 Key 快速查找（像 HashMap），又能自动排序（像 TreeSet）。常用于排行榜、延迟队列等场景。
考点： Redis 数据类型命令、Zset 应用场景
评论前必须登录！
注册