视频强调微服务高可用设计需平衡服务可用性、数据一致性与性能，重试、熔断、限流是一套防御体系。
面试者因机械背诵 MySQL 三层 B + 树理论数据而被面试官质疑。
理论计算：视频拆解 2000 万数据的来源，基于 InnoDB 默认 16KB 页大小、每条记录 1KB、非叶子节点索引键 + 指针 14 字节的假设，通过 1170×1170×16 的计算得出约 2190 万的理论值。
实际差异：视频指出实际存储量取决于行大小，行宽几十 KB 的表一页可能仅存一条数据，而行宽几十字节的表存 2000 万无压力，甚至有 5 亿数据的表因索引设计合理仍可高效运行。
面试建议：视频强调面试时需说明 2000 万是理论估算，实际需结合行宽和查询场景，补充实际业务经验可提升面试官认可度。视频通过具体案例和计算过程，解释了理论与实际存储量的差异及面试应答策略。
用户付了款还是待支付
业务分级：区分强一致性与最终一致性读，强一致性读（如订单详情页）强制走主库，最终一致性读（如历史订单）走从库。
降级与兜底：监控主从延迟，超过阈值自动切回主库；写入时返回版本号，读请求校验版本；热点数据应用层缓存。
架构优化：开启 MySQL 并行复制提升同步速度；核心写操作后延迟几十毫秒；大促期间强制读主库。
视频通过真实线上事故案例，考察开发者对数据一致性在读写分离下的理解深度。
视频中对 ThreadLocal 的错误说法可能导致面试者误解其内存泄漏原理。
内存泄漏原理：ThreadLocal 的 Map 中，key 是 ThreadLocal 实例的弱引用，会被 GC 回收，但 value 是强引用。若线程（如核心线程）长期存活且未手动清理，value 会持续占用内存，最终引发 OOM。
解决方法：一是使用后必须在 finally 代码块中调用 remove 方法；二是将 ThreadLocal 定义为 static final，减少弱引用实例；三是利用 JDK8 及以上版本的自动清理兜底机制，但不能替代手动 remove。
核心结论：ThreadLocal 的 Map 与线程绑定，线程不销毁则 value 持续占用内存，必须主动清理。
视频强调手动调用 remove 是解决内存泄漏的最可靠方案。
华为高级架构岗面试中，48 核 CPU 满载却无死锁的问题，暴露了候选人对多核环境底层原理的认知盲区。
死锁误区：死锁本质是线程阻塞等待，CPU 应空闲，而 48 核满载说明核心在被调度，面试官借此考察候选人是否突破思维定势。
三大真凶：视频指出 CAS 自旋锁引发的总线风暴、伪共享导致的缓存行失效、缺乏安全点的长循环拖慢全局 STW，是多核环境下 CPU 满载的隐蔽原因。
排查步骤：视频给出三步排查法，包括抓高耗能线程、用 Arthas 火焰图定位问题、针对不同原因优化，如将 AtomicLong 换为 LongAdder 解决 CAS 争抢。
视频提供了该面试题的标准答案模板，涵盖底层原理分析与落地优化方案。
用分布式锁解决缓存击穿的方案被指 "用大炮打蚊子"。
缓存击穿定义：热点 Key 在 Redis 中过期瞬间，大量请求同时查库导致数据库压力剧增。
分布式锁方案问题：作者认为该方案过度复杂，本质应直接从 MySQL 查数据再加载回 Redis，正常配置的 MySQL 能承受短时间内 500 个请求，且热点数据已在 MySQL 的 BufferPool 缓存。
替代方案：建议将 Key 设为永不过期或采用逻辑过期 + 异步刷新，避免在请求链路上加锁。
慢查询处理：慢查询应优化根因而非依赖分布式锁，分布式锁无法解决系统隐患。
视频最后提出问题：若热点 Key 更新频繁（如秒杀库存），应如何解决。