视频围绕 Kafka 消息顺序性问题展开从底层逻辑、乱序根源到生产端、消费端解决方案及全局有序方案进行讲解。底层逻辑Kafka 的 Topic 分为多个 Partition每个 Partition 是只能追加写入的有序日志文件Broker 保证写入顺序与读取顺序一致这是分区内有序的基础因设计核心为高吞吐分布式多个 Partition 独立运行放弃分布式才能实现全局有序违背设计初衷。乱序根源生产者重试插队、并发发送、消费者多线程消费、自动提交偏移量四个高频误区会导致消息乱序。生产端方案相同业务 Key 路由到同一 Partition、优化生产者参数如设置 max.in.flight.requests.per.connection1 或 enable.idempotencetrue、开启 Kafka 事务。消费端方案单线程消费单个 Partition、手动同步提交偏移量、监听消费者重平衡事件。全局有序方案单分区方案Topic 分区数设为 1适合消息量小的场景、业务分桶加分区有序按业务维度分桶每个桶对应一个 Partition适合中大型业务场景。实战避坑Topic 分区数确定后不随意增加、多个生产者写入同一 Partition 以 Broker 接收顺序为准、消费者数量不超过分区数监控每个分区的消费延迟和业务层乱序情况。视频最后总结Kafka 消息顺序性需从生产端、消费端多环节把控结合全局有序方案及避坑监控才能落地。低活跃商户引发死锁的现象暴露了多数开发者对索引失效场景下死锁机制的认知盲区。面试场景视频以 4 年高级后端工程师面试为切入点候选人在被问及死锁排查时仅能回答 “看日志、调顺序”但在面对清结算系统死锁案例时无法解释低活跃商户引发死锁的原因。死锁特征案例中死锁日志显示两个事务互相等锁一个用 FOR UPDATE 锁商户账户一个 UPDATE 订单状态死锁发生在日交易不到 10 笔的低活跃商户上。核心原因FOR UPDATE 在查询条件未走索引时会从行锁升级为表锁导致不同商户的事务互相等待即 “索引失效引发的幽灵死锁”。三层能力视频提出能扛住生产级死锁压力的后端工程师需具备现场快照与根因定位、事前防御与压测设计、代码层防御性设计三层能力。视频通过真实案例与能力拆解强调开发者需从 “会加锁” 升级为 “懂锁的代价”。线程池调优面试题的核心考察点是对生产环境风险的预判与应对能力。线程数计算短信推送属于 I/O 密集型任务需基于黄金公式计算初始值并通过压测调整而非直接给出固定数值。队列选择禁止使用 Executors 快捷创建线程池必须手动创建 ThreadPoolExecutor 并配合有界队列避免无界队列导致的 OOM 风险。拒绝策略推荐使用 CallerRunsPolicy通过让提交任务的主线程参与执行实现天然背压减缓任务生产速度。动态调优核心参数需接入配置中心实现动态化并监控队列剩余容量、线程池活跃度触发告警或动态扩容。任务保障结合数据库状态位和定时补偿任务确保机器重启时任务不丢失。视频还提到分布式场景下的架构设计问题如多机集群如何保证短信发送不重复、不遗漏。RocketMQ 的推模式本质是拉模式通过长轮询机制平衡实时性与系统稳定性。推模式实现DefaultMQPushConsumer 底层启动 PullMessageService 后台线程主动从 Broker 拉取消息后触发监听器回调而非 Broker 主动推送。拉模式优势避免纯推模式无背压机制的缺陷消费者可根据自身处理能力控制拉取频率防止内存溢出。长轮询机制Broker 的 PullRequestHoldService 会挂起无消息的拉取请求默认每 5 秒检查新消息最多等待 15 秒有消息时立即返回减少无效请求并保证实时性。视频通过源码分析对比推、拉模式的核心差异并延伸至信息获取的主动性对个人的启示。高并发消息队列的瓶颈往往不在消费者数量而在日志 I/O 等易被忽略的环节。面试场景面试官针对 4 年后端求职者简历中 “精通高并发消息队列” 的描述提出消息积压的真实事故问题。事故细节积分系统大促时消息量暴涨 20 倍积压 300 万条消费者从 10 个扩到 50 个后 TPS 仅从 500 涨到 600CPU 利用率不到 30%下游接口正常。根因定位通过 Arthas 排查发现每个线程卡在logger.info() 上关闭日志后 TPS 瞬间飙到 4000问题出在同步日志的磁盘 I/O 阻塞。三层能力视频提出应对高并发消息积压需具备现场快照与根因定位、事前防御与压测设计、代码层防御性设计三层能力。视频通过真实案例展示了高并发场景下全链路瓶颈排查的重要性。