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

目前进度是codetop前五页+hot100刷完了，八股背完了一轮但是感觉没背熟，求大佬们拷打简历

遇到一个民科乐子，最难绷的一集。

1. 自我介绍2. 介绍下你简历上这个项目3. 聊聊记忆系统模块设计，你会怎么拆记忆系统至少要拆成写入、索引、检索、融合和淘汰五层。写入层不是把所有对话都存下来，而是先判断值不值得记；索引层要同时支持按用户、会话、任务、实体和时间切片检索；检索层通常要把结构化过滤和语义召回结合起来；融合层负责把召回结果转成当前 prompt 可消费的上下文；淘汰层解决过期、冲突和污染。好的记忆系统不是“记得多”，而是“能在正确时刻拿回正确事实”。4. 记忆检索到底应该用 user_id、session_id，还是别的主键不能只用一个主键。session_id 更适合短期上下文恢复，能还原当前任务过程；user...