Java高频面试考点场景题30

视频围绕 Kafka 消息顺序性问题展开，从底层逻辑、乱序根源到生产端、消费端解决方案及全局有序方案进行讲解。

底层逻辑：Kafka 的 Topic 分为多个 Partition，每个 Partition 是只能追加写入的有序日志文件，Broker 保证写入顺序与读取顺序一致，这是分区内有序的基础；因设计核心为高吞吐分布式，多个 Partition 独立运行，放弃分布式才能实现全局有序，违背设计初衷。

乱序根源：生产者重试插队、并发发送、消费者多线程消费、自动提交偏移量四个高频误区会导致消息乱序。

生产端方案：相同业务 Key 路由到同一 Partition、优化生产者参数（如设置 max.in.flight.requests.per.connection=1 或 enable.idempotence=true）、开启 Kafka 事务。

消费端方案：单线程消费单个 Partition、手动同步提交偏移量、监听消费者重平衡事件。

全局有序方案：单分区方案（Topic 分区数设为 1，适合消息量小的场景）、业务分桶加分区有序（按业务维度分桶，每个桶对应一个 Partition，适合中大型业务场景）。

实战避坑：Topic 分区数确定后不随意增加、多个生产者写入同一 Partition 以 Broker 接收顺序为准、消费者数量不超过分区数；监控每个分区的消费延迟和业务层乱序情况。

视频最后总结，Kafka 消息顺序性需从生产端、消费端多环节把控，结合全局有序方案及避坑监控才能落地。

面试场景：视频以 4 年高级后端工程师面试为切入点，候选人在被问及死锁排查时仅能回答 "看日志、调顺序"，但在面对清结算系统死锁案例时无法解释低活跃商户引发死锁的原因。

死锁特征：案例中死锁日志显示两个事务互相等锁，一个用 FOR UPDATE 锁商户账户，一个 UPDATE 订单状态，死锁发生在日交易不到 10 笔的低活跃商户上。

核心原因：FOR UPDATE 在查询条件未走索引时会从行锁升级为表锁，导致不同商户的事务互相等待，即 "索引失效引发的幽灵死锁"。

三层能力：视频提出能扛住生产级死锁压力的后端工程师需具备现场快照与根因定位、事前防御与压测设计、代码层防御性设计三层能力。

视频通过真实案例与能力拆解，强调开发者需从 "会加锁" 升级为 "懂锁的代价"。

线程数计算：短信推送属于 I/O 密集型任务，需基于黄金公式计算初始值并通过压测调整，而非直接给出固定数值。

队列选择：禁止使用 Executors 快捷创建线程池，必须手动创建 ThreadPoolExecutor 并配合有界队列，避免无界队列导致的 OOM 风险。

拒绝策略：推荐使用 CallerRunsPolicy，通过让提交任务的主线程参与执行实现天然背压，减缓任务生产速度。

动态调优：核心参数需接入配置中心实现动态化，并监控队列剩余容量、线程池活跃度，触发告警或动态扩容。

任务保障：结合数据库状态位和定时补偿任务，确保机器重启时任务不丢失。

视频还提到分布式场景下的架构设计问题，如多机集群如何保证短信发送不重复、不遗漏。

推模式实现：DefaultMQPushConsumer 底层启动 PullMessageService 后台线程，主动从 Broker 拉取消息后触发监听器回调，而非 Broker 主动推送。

拉模式优势：避免纯推模式无背压机制的缺陷，消费者可根据自身处理能力控制拉取频率，防止内存溢出。

长轮询机制：Broker 的 PullRequestHoldService 会挂起无消息的拉取请求，默认每 5 秒检查新消息，最多等待 15 秒，有消息时立即返回，减少无效请求并保证实时性。

视频通过源码分析对比推、拉模式的核心差异，并延伸至信息获取的主动性对个人的启示。

高并发消息队列的瓶颈往往不在消费者数量，而在日志 I/O 等易被忽略的环节。

事故细节：积分系统大促时消息量暴涨 20 倍，积压 300 万条，消费者从 10 个扩到 50 个后 TPS 仅从 500 涨到 600，CPU 利用率不到 30%，下游接口正常。

根因定位：通过 Arthas 排查发现，每个线程卡在logger.info() 上，关闭日志后 TPS 瞬间飙到 4000，问题出在同步日志的磁盘 I/O 阻塞。

三层能力：视频提出应对高并发消息积压需具备现场快照与根因定位、事前防御与压测设计、代码层防御性设计三层能力。

视频通过真实案例展示了高并发场景下全链路瓶颈排查的重要性。