定时任务在高并发场景下存在三个致命缺陷。
定时任务的问题：时效性差，轮询间隔导致无法秒级取消；数据库压力大，全表扫描易引发 CPU 飙升；资源浪费，无超时订单时任务仍空跑。
Redis 过期监听的陷阱：不可靠，事件丢失会导致订单无法取消；延迟大，Redis 的过期删除策略不保证即时性。
Redis ZSet 方案：利用 ZSet 的 Score 存储订单超时时间戳，每秒轮询获取超时订单，性能高且精准。
消息队列与时间轮：RocketMQ5.0 支持任意延迟消息，RabbitMQ 需插件解决队头阻塞问题；时间轮算法高效但内存不可靠，需结合 Redis 持久化。
并发与兜底处理：用 Lua 脚本保证原子性，取消接口实现幂等；保留 T+1 离线扫描任务处理极端情况。
视频提供了从基础到架构师级的解决方案，覆盖并发控制、可靠性保障及进阶优化。
分库分表的核心是通过技术手段匹配业务增长，解决高并发和大数据量问题。
分表：单表数据量过大（如千万级）会降低 SQL 执行性能，分表将一个表的数据拆分到多个表中，控制每个表的数据量在可控范围。
分库：单个数据库最多支撑 2000 并发，健康状态应保持在 1000 并发以内，分库将数据拆分到多个库中，分散并发压力。
水平拆分：将同一结构的表数据拆分到多个库或表中，分散数据量和并发压力，提升存储容量。
垂直拆分：将字段多的表拆分为多个结构不同的表，按访问频率区分字段，通常在同一库内进行。
分库分表需根据业务增长阶段实施，避免过早拆分。
RabbitMQ 4.X 版本已移除 Classic 镜像队列，不懂三种队列区别将导致架构方案过时。
版本变化：RabbitMQ 4.X 版本彻底移除使用十几年的 Classic 镜像队列，集群模式仅保留 Quorum 仲裁队列。
Classic 队列缺陷：默认类型但存在三致命问题 ------ 消息积压引发性能雪崩、镜像同步无法保证强一致性（主节点断电易丢未同步消息）、节点重启全量同步堵塞集群，新项目建议避免。
Quorum 队列优势：基于 Raft 协议，消息需多数节点确认落盘（强一致），采用增量日志复制（节点重启不阻塞），适合核心业务（订单、支付），是官方推荐集群方案。
Stream 队列特点：日志追加写结构，顺序写磁盘提升性能，支持回溯消费（消息不删除，新消费者可指定起始点），适合大数据流场景（日志收集、IoT 数据）。
视频给出三种队列的选型建议，帮助开发者匹配不同业务场景需求。
MySQL 事务隔离级别的底层逻辑可通过 "开车换挡" 类比理解，档位越低效率越高但风险越大，反之则更安全但效率降低。
- read uncommitted（读未提交）事务未提交时数据即可被其他事务读取，可能导致脏读问题，生产环境基本不使用。
- read committed（读已提交）需等事务提交后数据才会被读取，解决了脏读问题，但可能出现不可重复读，是 Oracle 等数据库的默认级别，部分互联网公司会将 MySQL 调整至该级别以追求高并发。
- repeatable read（可重复读）MySQL 的默认级别，事务开启时会生成数据快照，事务内数据状态保持不变，但理论上可能出现幻读。
- serializable（串行化）最高级别，通过锁机制实现事务串行执行，数据绝对安全但效率极低，仅适用于极高安全级别的场景。
视频最后提出问题，询问 MySQL 的可重复读级别是否防住了幻读。
初级 Java 开发对库存超卖问题的基础回答，无法覆盖分布式并发场景下的核心矛盾。
问题本质：库存超卖源于读取 - 判断 - 扣减的非原子操作，在高并发与分布式环境下必然引发数据不一致。
前置防护：前端按钮防重、网关限流与请求过滤，以及活动前的库存缓存预热。
核心方案：数据库乐观锁通过版本号实现原子条件更新；Redis 预扣库存利用原子操作提升并发能力；分布式锁控制库存操作串行化；数据库悲观锁通过行级锁保证绝对安全但性能较低。
设计要点：库存分层管理、异步削峰同步、异常回补机制、兜底熔断策略与最终一致性校验。
视频提出了项目中处理秒杀结束后缓存与数据库库存最终一致性核对的问题。
视频将反射原理拆解为四个核心考点，并用生活场景类比降低理解门槛。
反射本质：用 "户籍系统查信息" 类比反射的反向操作，解释其在运行时解析字节码文件的特性。
Class 对象：强调 JVM 为每个类生成唯一 Class 对象，所有反射操作均围绕该对象展开。
获取方式：点明 getClass、Class.forName 等三种获取 Class 对象的方式是面试高频考点，需区分优缺点。
框架应用：指出 Spring IOC、MyBatis Mapper 代理等主流框架的底层逻辑均依赖反射实现。视频最后给出实践建议，通过调用私有方法的代码示例验证反射突破封装的特性。