很简单的一面，速通了，当天约二面简历里提到了三套可替换的登录逻辑（单JWT、JWT+Redis、Session+Redis），为什么要去做这三套？你的考虑或者想法是什么？如果项目中依赖的 Redis 宕机了，这几种登录方式你是怎么考虑应对的？有什么备用方案吗？简历中提到秒杀有同步和异步两种方案，能具体说说你对这两种秒杀方案的思路和整个想法吗？简历中写到了布隆过滤器，并且单独提到了一个“1.82%”的拦截率数字，请问这个数字是你实际测试出来的吗？手撕：lc1291 顺次数

简历给你了学校标的清清楚楚😅，面完说我是三本只能给150，那你boss标200-250干嘛，感觉还是太礼貌了，应该直接爆了😤学历就是一个人的外貌实习就是一个人的衣服本科学历差就是其貌不扬的样子实习经历差就是破破烂烂的衣服＃民办已经死了 ＃都给我去考研吧＃计算机就是学历＞技术＃c++92✌🏻才能学

现在好多技术都在学，项目还在搞，但是害怕时间太晚来不及了，只要有人要我就可以了小厂也可以，佬佬帮我看一下😭😭

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