1. 自我介绍2. RocketMQ 里顺序消息、普通消息、事务消息分别适合什么场景，为什么不能混着用普通消息适合最终一致、无严格顺序约束的场景，比如日志分发、画像更新、通知投递。顺序消息适合同一业务键必须按时间线推进状态的链路，比如同一工单、同一订单、同一会话的状态演进，但顺序消息的吞吐和容错设计会受到队列粒度限制。事务消息适合本地事务与异步投递之间要建立“发送承诺”的场景，比如主库先落事实，再由 MQ 推动旁路索引或下游补偿。三者不能混着用，是因为它们解决的问题不同，消费模型、失败恢复方式和成本模型也完全不同。3. 如果 RocketMQ 出现消息积压，你会怎样定位，不要只说“扩容消费者”...

学java第六天，效率太慢了把游戏删了我再玩是sb

灵神太强了，写力扣没这么爽过

拼多多后端二面，总体比较简单请做一个自我介绍介绍一下你第一个项目中你觉得比较有意义的内容你提到的 SPI 机制具体是怎么用在项目里的？优惠券秒杀中两套方案（同步 / 异步）分别是怎么实现的？乐观锁和分布式锁在你的秒杀逻辑中是怎么具体使用的？异步方案中 Lua 脚本 + MQ 的具体业务流程是怎样的？分布式锁在这个方案中的性能瓶颈在哪里，有什么优化手段？除了调整 RedLock，你还有什么办法优化锁的粒度或性能？布隆过滤器？你的项目中消息队列是怎么用的？如何保证消息不被重复消费？消息堆积一般如何解决？顺序消息是如何实现的？RocketMQ 为什么能支持顺序消息？和 Kafka 有什么区别？简单介...