RocketMQ 的固定级别延迟任务设计未使用复杂时间轮算法，却能通过朴素技术智慧扛住百亿级并发。
固定延迟级别：默认设 18 个固定延迟级别（1 秒到 2 小时），可通过配置修改；同一级别消息延迟时间一致，天然形成 FIFO 队列，无需排序。
系统 Topic 与队列：延迟消息存入内部 SCHEDULE_TOPIC_XXX 主题，该主题含 18 个队列对应 18 个级别；生产者发送延迟消息时，Broker 会将原 Topic 和 Queue 存入消息属性，替换为对应延迟级别的队列。
任务调度机制：启动 18 个后台任务对应不同级别，扫描队列头部消息判断是否到期；未到期则计算差值，用 Timer 机制提交精准定时任务，避免死循环轮询；队列空时设 100 毫秒短定时任务检查新消息。
核心优势：顺序 IO 保证写入高效，零排序开销提升效率，精准事件唤醒实现 CPU 零内耗。
视频提到下期将讲解 RocketMQ 基于时间轮的任意时间点延迟消息机制。
Redis 在 TB 级数据场景下会因内存成本与集群复杂度成为负担。
Redis 的局限性：视频指出 Redis 虽单机内存读写快，但几十 TB 数据下内存成本极高，且集群带来的网络延迟、分片与运维复杂度会成为痛点。
RocksDB 的核心优势：作为嵌入式 KV 存储引擎，RocksDB 将数据存在 SSD 硬盘，通过 LSM 树将随机写转为顺序写，结合多级合并机制（Level0 至 Level6 动态层级）与 IO 限流、多线程并发合并等优化，在 TB 级数据场景下实现高吞吐与低成本。
两者定位差异：Redis 适合几十 GB 数据的微秒级低延迟场景，RocksDB 则针对 TB 级海量数据与成本敏感需求，无网络开销且能压榨 SSD 性能。
视频通过对比两者的技术设计与适用场景，强调技术选型需结合数据规模与成本需求。
防止接口重复提交的核心考点是接口的幂等性设计。
数据库唯一索引：通过在数据库表中设置唯一索引，重复创建相同数据时会触发索引冲突异常，适用于创建类场景。
Redis 锁机制：请求到达后，用业务标识加用户 ID 生成唯一 key，通过 SETNX 命令尝试获取锁，成功则执行业务，否则拒绝执行。
请求 ID 校验：前端携带唯一请求 ID，后端接收后先查询缓存数据库，若 ID 已处理则直接返回结果，避免重复执行。
视频提到幂等性在订单、定时任务等业务场景中常见，且整理了包含该知识点的面试文档。
唯一索引在高并发场景下可能因锁竞争拖垮系统，且无法完全避免重复扣款问题。
问题场景：视频以 618 大促订单系统重复扣款事故为例，指出仅依赖 Redis 分布式锁和数据库唯一索引的幂等方案，在高并发下会出现锁等待超时，甚至导致系统瘫痪。
根因分析：唯一索引仅为兜底措施，未结合业务状态判断（如订单是否已支付），且高并发下数据库锁竞争会形成排队，同时分布式 ID 生成器若存在重复（如雪花算法时钟回拨），唯一索引无法拦截。
三层能力：视频提出能扛住大促流量的幂等设计需具备现场快照与根因定位、事前防御与压测设计、代码层防御性设计三层能力，强调业务状态机是第一道防线，唯一索引为最后一道防线。
视频通过真实事故案例，拆解幂等性设计在高并发场景下的失效陷阱及应对方案。
视频通过生活化类比拆解了 JVM 垃圾标记的底层逻辑，解决了 "循环引用" 问题的核心矛盾。
引用计数法缺陷：用 "借书计数" 类比引用计数法，指出其无法识别对象 A 与 B 互相引用的 "孤儿" 场景，计数器始终为 1 导致内存泄漏。
可达性分析原理：将对象比作风筝，GC Roots（根节点）比作地面 VIP 人物，JVM 通过检查对象是否能通过 GC Roots 的 "线" 被触及来判断存活，断开连接的 "断线风筝" 即为垃圾。
GC Roots 类型：明确四类核心根节点，包括当前执行方法的局部变量、类的静态变量和常量、底层本地代码引用的对象。
视频最后提出关于 "断线风筝是否立即销毁" 的思考题，引导观众进一步思考垃圾回收的后续流程。