分布式事务选型需结合业务场景，而非单一依赖 Seata AT 模式。
Seata AT 模式局限：高并发场景下存在性能黑洞与数据脏写风险，核心账务系统禁用。
三剑客选型标准：TCC 模式适用于支付、扣库存等强一致性短事务场景；Saga / 本地消息表适用于长流程、跨部门场景；Seata AT 模式适用于低并发内部系统。
面试答题模板：从本质、对比、标准、实战四步展开，强调 CAP 权衡与系统稳定性。
视频提出 TCC 模式极端容错的思考题，涉及网络波动与人工冲正的选择。
传统递归嵌套设计在高并发场景下会直接导致服务器内存耗尽、数据库连接数超限。
扁平化结构：将所有嵌套回复直接挂载到一级评论下，仅通过标识记录直接回复对象，避免递归查询。
游标分页：放弃传统偏移量分页，以上一页最后一条评论 ID 为游标，查询小于该 ID 的内容，避免数据库扫描大量无效数据。
降级策略：缓存穿透时，网关层置灰二级回复折叠面板，返回静态快照，保证系统不崩溃。
视频最后提出思考题：将评论 ID 游标存入缓存有序集合时，用什么字段作为排序分数最合适。
volatile 关键字的核心作用是解决多线程环境下的可见性和指令重排问题，但无法保证原子性。
可见性问题：视频通过主线程修改共享布尔变量后子线程陷入死循环的案例，解释了 Java 内存模型（JMM）中线程工作内存与主内存的副本机制，以及 CPU 缓存和写缓冲区导致的脏数据问题。
指令重排陷阱：以配置初始化场景为例，说明编译器和 CPU 为优化效率可能打乱代码执行顺序，导致上下文未加载完成却被标记为初始化完成的空指针异常。
volatile 的作用：修饰变量后，写线程会强制将修改刷回主内存，通过 MESI 协议使其他线程缓存副本失效；同时插入内存屏障（x86 环境通过 lock 前缀指令实现）禁止指令重排。
原子性边界：视频指出 volatile 无法保证 i++ 等复合操作的原子性，需配合 Synchronized 或 CAS 机制。
视频最后提供了面试回答模板，分现象、根源、作用、边界四步梳理 volatile 的底层逻辑。
仅用 LRU 算法应对 5000 万数据缓存场景会直接导致面试失败。
核心问题：5000 万条视频数据需缓存 30 万条，且每秒十万请求需 50 毫秒响应，简单 LRU 算法会被冷门数据挤走热点视频，导致数据库压力激增系统瘫痪。
破局策略：将 Redis 淘汰策略改为 LFU（最不常使用），以访问频率而非时间判断缓存优先级，确保高访问量的热点视频不被挤出。
多级防御：在应用服务器内存中设置本地缓存，当探测到某 key 成为热点时，通过广播通知所有服务器将数据存入本地缓存，分散 Redis 节点压力。
视频最后提出思考题：若热点视频内容更新，如何解决本地缓存旧数据未过期的问题。
缓存穿透的核心风险并非 "缓存失效"，而是 "数据本身不存在"，此认知差异是多数面试者的失分点。
定义澄清：视频明确缓存穿透与缓存击穿、雪崩的区别，强调其核心是数据在缓存和数据库中均不存在，而非缓存失效。
防御方案：视频提出三种方案，包括缓存空值（需设置短过期时间）、布隆过滤器（高效拦截无效 ID）、接口限流 + 恶意 IP 拦截（兜底手段）。
面试陷阱：候选人因未考虑缓存空值的内存占用问题，被面试官指出方案隐患，暴露对核心风险的认知不足。
视频最后强调，面试官更关注解决问题的能力，而非项目经历。
字节电商团队面试中，分布式锁问题的回答需覆盖原子性、自动续期等四层进阶方案。
初级版直接使用 setnx 加 expire 存在非原子性问题，需改用 Redis 2.6 后的 set key value nx ex 原子命令。
进阶版原子 set 仍面临业务超时导致锁提前释放的风险，需通过看门狗机制启动守护线程自动续期。
企业级方案Redisson 框架已实现自动续期、可重入锁和防误删机制，默认锁超时 30 秒，每 10 秒续期一次。
终极方案Redlock 通过向多个 Redis 节点加锁（超过半数成功）解决主从同步丢锁问题，但实现复杂争议大。
视频明确要求面试回答需结合业务场景对比 Redis 与 ZooKeeper 分布式锁的选型逻辑。