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

这种要去吗？

求大佬们拷打简历，投了好多简历了，基本上都没面

1. 自我介绍2. TCP 和 IP 的职责边界是什么，为什么说“HTTP 基于 TCP，TCP 基于 IP”这个表述只对了一半IP 负责尽力而为地把报文从源地址送到目标地址，它不保证到达、不保证顺序，也不保证不重复。TCP 建立在 IP 之上，提供有连接、可靠传输、流量控制、拥塞控制和按序交付。HTTP 是应用层协议，它依赖传输层提供的可靠字节流，但 HTTP 本身并不“知道”底下是不是 TCP，也可以跑在 QUIC 上。所以“HTTP 基于 TCP”对传统 HTTP/1.1 和 HTTP/2 是对的，但对 HTTP/3 就不成立；“TCP 基于 IP”则更准确，因为 TCP 的寻址和转发确...