长连接导致内存爆炸的核心原因并非连接时长，而是资源生命周期失控。
本质拆解：长连接需占用文件描述符、TCP 控制块、收发缓冲区等系统资源，各资源有独立的内存占用模型。
失控原因：连接关闭后 TIME_WAIT 机制延迟释放资源；流量增大时 TCP 滑动窗口扩张，内核需扩容缓冲区；频繁建连断连产生无法复用的内存碎片。
结果：三类问题叠加导致内存持续膨胀，最终引发 OOM。视频指出长连接内存问题的关键在于资源生命周期管理。
仅罗列 Spring 事务传播机制的 7 种类型会被面试官直接否定。
核心问题：传播机制解决的是嵌套调用时，子方法是加入父方法事务还是独立创建事务的问题。
REQUIRED（必选）：有事务则加入，无事务则新建，适用于大部分业务场景，保证操作的一致性。
REQUIRES_NEW（新建）：无论是否有事务都新建独立事务，旧事务挂起，适用于关键日志记录等需隔离风险的操作。
SUPPORTS（支持）：有事务则加入，无事务则以非事务方式运行，适用于查询等灵活适配的操作。
NESTED（嵌套）：基于数据库保存点实现，子事务可独立回滚但受父事务最终结果影响，适用于复杂局部回滚的精细控制。
面试官更关注结合业务场景的判断，而非死记硬背。
分布式事务面试题的核心考察点并非方案名称，而是每种方案的原理、坑点与适用场景。
面试场景：面试官以 "用户支付成功但订单状态未更新" 的场景提问，候选人因仅能列举分布式事务方案名称（如 TCC、SAGA），无法回答 TCC 的空回滚、悬挂问题及本地消息表与 RocketMQ 事务消息的区别而失败。
方案对比：视频详细对比了五种分布式事务方案，包括 XA/2PC（强一致性但性能差）、TCC（高性能但需处理空回滚和悬挂）、SAGA（长事务拆分 + 补偿）、本地消息表（定时任务 + MQ + 幂等）、RocketMQ 事务消息（半消息 + 反查机制）。
核心结论：分布式事务面试的关键在于掌握每种方案的原理、优缺点及适用场景，而非仅背诵方案名称。
视频强调，理解分布式事务的坑点与适用场景是 P7 级别面试的核心要求。
微信红包系统设计的核心矛盾在于公平性与娱乐性的平衡。
核心算法：视频明确提到两种分配算法。二倍均值法以剩余人均金额的两倍为上限，保证金额分布均匀但娱乐性不足；线段切割法将总金额视为线段随机切割，可能出现大额红包但需处理排序和精度问题。
高并发方案：生产环境采用预分配加原子操作，提前计算并打乱红包金额存入列表，用户抢红包时直接弹出元素，通过 Redis 保证原子性避免超发。
精度处理：将金额转换为分进行整数运算，预留每人至少一分钱防止零元红包。
视频最终给出的设计思路是结合算法特性与工程优化，同时满足稳定性与趣味性需求。
订单取消重新付款怎么处理？
核心原因：订单状态流转存在并发冲突，支付通道与订单系统信息同步延迟，缺乏临界状态异常的兜底机制。
解决方案：一是利用数据库状态判断，在更新订单状态时添加当前状态为支付中的限制条件，避免状态混乱；二是使用 Redis 分布式锁，为每个订单生成唯一锁标识，获取锁成功的线程才能变更状态，解决跨节点并发问题。
选型逻辑：数据库方案无需中间件、实现简单，适合复杂度不高的系统；Redis 方案适配性强，但需处理锁超时、释放等细节。
视频给出了两种主流解决方案的设计原则与适用场景。
MySQL 深度分页问题的核心原因是大 offset 会导致数据库白查并丢弃大量数据。
问题原因当使用limit 100000,10时，MySQL 会先查询 100010 条数据，再丢弃前 100000 条，仅返回最后 10 条，造成 IO 和内存浪费，offset 越大性能越差。
主键 ID 优化若 ID 连续递增且按 ID 排序，可改为where id>100000 limit 10，通过主键索引直接定位数据，无需扫描前 10 万条。
子查询优化若按非主键字段（如create_time）排序，先通过子查询用覆盖索引获取 ID，再关联查询回表，仅需回表 10 条数据。
业务优化限制分页上限，如最多允许翻 100 页，从根源避免大 offset 出现。
深度分页优化的核心是避免扫描无用数据，优先使用索引定位或业务限制。