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

本人bg为末九本，目前力扣hot100过了一遍目前在刷面试150，算法能力不太行，八股过了一遍。从3.9号开始陆续投简历，主要是官网投得多，中间几家大厂因为太菜笔试没过，其他不是简历挂就是一直在初筛，ssob上发了消息不是已读不回就是看都没看。在ssob上投还是在官网投面试机会大？另外我是不是简历有问题？希望各位大佬能给我和我点建议 从开始到现在已经一个月了一个面试机会都没有，已经没招了引流：美团，字节，pdd，腾讯，阿里

上来先手撕：非递归实现后序遍历二叉树，磨蹭半天写出来了请简单介绍一下你自己做的项目，以及大概用到了哪些组件（中间件）？是否了解分布式系统的 CAP 理论？这大概是一个什么样的问题？在你的项目中，使用分布式锁主要是为了解决什么问题？如果改为异步的方式，还能判断“一人一单”吗？秒杀场景下，先判断“一人一单”再判断“库存是否足够”，这一套逻辑具体是在哪里判断的？项目中的 Redis 是单节点部署的吗？如果变成集群部署，库存在一致性的问题？Redisson 分布式锁的实现原理是什么样的？布隆过滤器？如果让你设计一个工作在多线程并发环境下的本地先进先出（FIFO）队列，且为了性能要求是无锁（Lock-f...