平移台3大高频面试题:从报错到选型,老手避坑指南
上周一个做市政项目的朋友来找我，说面试卡住了。他对着屏幕上一堆红色的 StackTrace 发呆，问我：“这报错到底在骂谁？”
我接过电脑，看了一眼，笑了。
这不是代码报错，这是平移台逻辑没理顺。
在很多人的认知里，“平移台”只是个机械名词。但在后端高并发场景里，它指的是数据在多个存储层或线程间的无状态搬运与对齐。
这就是今年 Java 和 Go 后端高频面试题的盲区。
面试官不问八股，问的是：当你的数据在 Redis 和 MySQL 之间“平移”时，怎么保证一致性？
答不上来，直接 Pass。
别慌。今天这篇，我不讲虚的。
我们直接拆解“平移台”在工程里的真实映射，对比三种主流技术方案。
看完你就知道，那个红色的 StackTrace 是怎么来的，以及怎么让它闭嘴。
1. 定位：谁在扮演“平移台”？
在市政公用工程的数字化系统中，我们经常遇到“数据搬家”的场景。
比如：施工日志从现场 App 上传，经过网关，写入 Kafka，再落入 MySQL。
这个链路中，Kafka 就是那个“平移台”。
它不处理业务逻辑，只负责把数据从 A 点平移到 B 点，保持原样，不丢不重。
但在面试中，“平移台”往往指代内存中的数据视图同步。
假设你有三个微服务：用户服务、订单服务、库存服务。
当用户下单，库存扣减后，这个变更需要“平移”到其他服务。
这时候，如果同步做，性能爆炸；如果异步做，数据不一致。
核心矛盾：实时性与一致性的博弈。
这也是为什么面试官喜欢拿这个场景来坑人。
你需要识别出，所谓的“平移台”，在你的架构里到底是：消息队列 (MQ)：解耦与削峰。
缓存层 (Cache)：读写分离与热点加速。
事件总线 (Event Bus)：领域驱动设计中的状态同步。
搞不清这个定位，写代码就是瞎猜。
报错一堆看不懂 StackTrace？
90% 的情况，是因为你把“平移台”当成了“业务处理器”。
你让 Kafka 去判断库存够不够？
当然炸。
Kafka 只管传，不管算。
这就是定位偏差带来的致命错误。2. 核心差异：三大方案硬核对比
市面上能当“平移台”用的技术不少。
但真正能扛住生产环境高并发的，也就这几家。
我选取了三个最具代表性的方案进行横向对比：
RabbitMQ、Kafka、Redis Stream。
这三个，覆盖了绝大多数后端场景。
为了让你一目了然，我整理了一张对比表。
请仔细看图，每一行都藏着面试陷阱。特性
RabbitMQ
Kafka
Redis Stream核心定位
业务消息路由
高吞吐日志/数据流
轻量级事件流吞吐量
万级 QPS
百万级 QPS
十万级 QPS延迟
毫秒级 (极低)
毫秒级 (略高)
微秒级 (极低)持久化
可选 (默认内存)
强制 (磁盘顺序写)
可选 (RDB/AOF)消息确认
手动/自动 ACK
Offset 提交
ACK (XACK)适用场景
复杂路由、事务消息
大数据同步、监控日志
实时计数、短时队列运维难度
中等
高 (集群复杂)
低官方文档
RabbitMQ.io
Apache Kafka
Redis.io重点解读：吞吐量差异巨大：Kafka 依靠磁盘顺序写，速度吊打其他两个。如果你的“平移台”是同步亿级用户的行为日志，选 Kafka 没商量。
延迟敏感型：如果是金融交易，要求毫秒内确认，RabbitMQ 或 Redis Stream 更合适。Kafka 的批量处理机制会导致轻微延迟累积。
运维成本：Kafka 集群搭建是噩梦。Zookeeper 或 KRaft 模式，配置稍有不慎，数据就乱了。Redis Stream 几乎零运维，随启随用。
消息可靠性：RabbitMQ 支持死信队列和延迟消息，功能最丰富。Kafka 一旦消息被消费，Offset 提交了，想找回很难（除非保留时间够长）。避坑提示：
很多新人喜欢用 Redis 做消息队列。
大错特错。
Redis 的 List 结构，如果消费端宕机，消息就丢了。
Stream 虽然好，但它的设计初衷不是持久化存储。
如果你的数据丢失了会导致市政工程款算错，别用 Redis 当“平移台”。
3. 代码写法对比：从报错到实现
光说不练假把式。
我们来看三种方案在 Java 中的实际代码写法。
注意，我特意保留了一些容易出错的细节。
对照你手里的 StackTrace，看看是不是踩了这些坑。
方案一：RabbitMQ (Spring Boot)
场景：订单创建后，平移库存扣减消息。
痛点：消息重复消费、事务不一致。
@Service
public class OrderService {@Autowiredprivate RabbitTemplate rabbitTemplate;@Autowiredprivate OrderMapper orderMapper;/*** 下单逻辑：本地事务 + 消息发送* 错误示范：直接在事务里发 MQ，可能导致事务回滚但消息已发出*/@Transactionalpublic void createOrder(OrderDTO dto) {// 1. 插入订单orderMapper.insert(dto);// 2. 发送消息到“平移台”// 坑点：如果这里抛异常，事务回滚，但消息可能已经发出// 正确做法：使用本地消息表 或 RocketMQ 事务消息rabbitTemplate.convertAndSend(order.exchange, order.created, dto);}
}@Component
public class InventoryConsumer {@RabbitListener(queues = inventory.queue)public void handleInventory(String msg) {// 坑点：没有幂等性处理// 如果 MQ 重发，库存会被扣两次InventoryDTO dto = JsonUtils.parse(msg, InventoryDTO.class);inventoryMapper.deduct(dto.getSkuId(), dto.getQty());}
}解析：
这段代码里，@Transactional 和 rabbitTemplate 的配合是经典雷区。
如果 insert 成功，但 send 失败，事务回滚，订单没了。
如果 insert 和 send 都成功，但后续业务逻辑报错回滚，订单没了，但库存扣了。
这就是“平移台”失控的后果。
解决方案：引入本地消息表，或者换用支持事务消息的 RocketMQ。
方案二：Kafka (原生客户端)
场景：海量传感器数据实时平移至数据仓库。
痛点：数据丢失、乱序。
public class SensorDataProducer {private static final String TOPIC = sensor-data-stream;private static KafkaProducerString, String producer;static {Properties props = new Properties();// 关键配置：确保数据不丢props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, kafka:9092);props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);// 坑点：acks=0 是默认值，数据可能丢// 必须设置为 all 或 -1props.put(ProducerConfig.ACKS_CONFIG, all);// 重试机制props.put(ProducerConfig.RETRIES_CONFIG, 3);producer = new KafkaProducer(props);}public static void sendSensorData(String sensorId, String data) {RecordMetadata metadata = null;try {// 关键：指定 Key，保证同一传感器的数据在同一个 Partition，避免乱序ProducerRecordString, String record = new ProducerRecord(TOPIC, sensorId, data);FutureRecordMetadata future = producer.send(record);// 同步等待结果，确保发送成功metadata = future.get();} catch (Exception e) {// 坑点：吞掉异常，导致数据静默丢失// 必须记录日志并告警System.err.println(Failed to send sensor data: + e.getMessage());}}
}解析：
Kafka 的坑在于顺序性和确认机制。
如果不设置 acks=all，Leader 节点挂了，数据就没了。
如果不指定 Key，同一传感器的数据可能发到不同 Partition，导致乱序。
在市政工程中，传感器数据乱序，可能触发错误的报警。
这就是为什么面试官喜欢问 Kafka 的 acks 参数。
方案三：Redis Stream (Lettuce)
场景：实时在线用户数统计。
痛点：内存溢出、消息堆积。
@Component
public class UserOnlineStreamHandler {@Autowiredprivate RedisTemplateString, String redisTemplate;private static final String STREAM_KEY = user:online:stream;@PostConstructpublic void initConsumerGroup() {// 创建消费者组，保证消息只被一个实例消费try {redisTemplate.opsForStream().createGroup(STREAM_KEY, ReadOffset.latest(), online-group);} catch (Exception e) {// 忽略已存在异常}}@Scheduled(fixedRate = 1000)public void consumeOnlineEvents() {// 坑点：没有使用 XREADGROUP，而是用了 XREAD// 这样消息不会被标记为已消费，导致重复处理StreamRecordsString, MapRecordString, String records = redisTemplate.opsForStream().read(StreamReadOptions.empty().count(10),StreamOffset.create(STREAM_KEY, ReadOffset.latest()));if (records != null) {for (MapRecordString, String record : records) {String userId = record.getValue().get(userId);// 业务逻辑：更新 Redis 计数器redisTemplate.opsForValue().increment(online:count);// 坑点：没有 ACK// 如果这里抛异常，下次轮询会重复读到这条消息// 应该使用 ack() 方法}}}
}解析：
Redis Stream 的 XREAD 和 XREADGROUP 是两回事。
XREAD 只是读取，不改变消息状态。
XREADGROUP 会将消息放入待处理列表 (Pending List)，消费后需要 XACK 确认。
如果不用 Group，高并发下多个实例会重复消费，导致在线数虚高。
这就是“平移台”在内存中的典型故障。
4. 适用场景：怎么选不踩坑？
技术没有银弹，只有场景适配。
结合市政公用工程的实际业务，我给你三条选型建议。
场景一：核心交易链路 (订单、支付)
推荐：RabbitMQ 或 RocketMQ
理由：可靠性第一：数据不能丢，不能错。
功能丰富：支持延迟消息（如订单超时取消）、死信队列（处理异常）。
事务支持：RocketMQ 的事务消息完美解决“本地事务+消息发送”的一致性问题。
避坑：不要用 Kafka 做核心交易，吞吐量虽高，但一致性保障较弱，运维复杂。场景二：大数据同步与日志收集
推荐：Kafka
理由：高吞吐：轻松应对百万级 QPS。
生态完善：与 Flink、Spark、Elasticsearch 无缝集成。
持久化：数据保留时间长，方便回溯和重放。
避坑：必须配置 acks=all 和 min.insync.replicas，确保数据不丢。场景三：实时统计与轻量级事件
推荐：Redis Stream
理由：低延迟：微秒级响应，适合实时大屏。
低运维：无需独立集群，复用现有 Redis。
轻量级：代码简单，开发效率高。
避坑：必须使用 Consumer Group 和 ACK 机制，避免重复消费。不要用它做持久化存储。场景四：混合架构 (推荐)
实际项目中，往往不是单选。
常见的组合拳：Kafka 作为主“平移台”，承接所有业务事件。
Flink 消费 Kafka，进行实时计算。
Redis 缓存计算结果，供前端实时查询。
MySQL 存储最终结果，供后台管理查询。
这种架构下，Kafka 是“大动脉”，Redis 是“毛细血管”。
各司其职，互不干扰。5. 选型建议与避坑清单
回到开头的那个 StackTrace。
报错不可怕，可怕的是你不知道错在哪。
在“平移台”的选型和实现中，我有五条血泪建议：幂等性是底线：
无论用哪种 MQ，消费端必须做幂等处理。
用 Set 记录已处理的消息 ID，或者用数据库唯一索引兜底。
没有幂等，就是给自己埋雷。监控不能少：
监控 MQ 的积压量 (Lag)。
如果 Lag 持续增长，说明消费端处理能力不足，或者下游服务挂了。
设置告警阈值，提前介入。灰度发布：
新上“平移台”逻辑时，不要全量切换。
先切 1% 流量，观察数据一致性，再逐步扩大。
市政系统一旦数据出错，整改成本极高。备份与恢复：
Kafka 的 retention.ms 设置要合理。
建议至少保留 7 天，方便问题排查和数据重放。
Redis Stream 的 maxlen 也要设置上限，防止内存爆满。不要过度设计：
小项目，用 Redis List 就够了。
别为了炫技，上 Kafka 集群。
运维成本是你看不见的负债。总结：
“平移台”不是孤立的技术点，它是架构中数据流动的枢纽。
选对技术，写对代码，做好监控。
你的 StackTrace 就会少一半，你的面试通过率就会高一大截。
这个知识点你面试被问过吗？留言说说
你是被 RabbitMQ 的事务消息坑过，还是被 Kafka 的乱序问题折磨过？
或者你在生产环境遇到过什么奇葩的“平移台”故障？
评论区聊聊，大家一起避坑。
毕竟，少踩一个坑，就少加一次班。
平移台3大高频面试题:从报错到选型,老手避坑指南
上周一个做市政项目的朋友来找我，说面试卡住了。他对着屏幕上一堆红色的 StackTrace 发呆，问我：“这报错到底在骂谁？”
我接过电脑，看了一眼，笑了。
这不是代码报错，这是平移台逻辑没理顺。
在很多人的认知里，“平移台”只是个机械名词。但在后端高并发场景里，它指的是数据在多个存储层或线程间的无状态搬运与对齐。
这就是今年 Java 和 Go 后端高频面试题的盲区。
面试官不问八股，问的是：当你的数据在 Redis 和 MySQL 之间“平移”时，怎么保证一致性？
答不上来，直接 Pass。
别慌。今天这篇，我不讲虚的。
我们直接拆解“平移台”在工程里的真实映射，对比三种主流技术方案。
看完你就知道，那个红色的 StackTrace 是怎么来的，以及怎么让它闭嘴。
1. 定位：谁在扮演“平移台”？
在市政公用工程的数字化系统中，我们经常遇到“数据搬家”的场景。
比如：施工日志从现场 App 上传，经过网关，写入 Kafka，再落入 MySQL。
这个链路中，Kafka 就是那个“平移台”。
它不处理业务逻辑，只负责把数据从 A 点平移到 B 点，保持原样，不丢不重。
但在面试中，“平移台”往往指代内存中的数据视图同步。
假设你有三个微服务：用户服务、订单服务、库存服务。
当用户下单，库存扣减后，这个变更需要“平移”到其他服务。
这时候，如果同步做，性能爆炸；如果异步做，数据不一致。
核心矛盾：实时性与一致性的博弈。
这也是为什么面试官喜欢拿这个场景来坑人。
你需要识别出，所谓的“平移台”，在你的架构里到底是：消息队列 (MQ)：解耦与削峰。
缓存层 (Cache)：读写分离与热点加速。
事件总线 (Event Bus)：领域驱动设计中的状态同步。
搞不清这个定位，写代码就是瞎猜。
报错一堆看不懂 StackTrace？
90% 的情况，是因为你把“平移台”当成了“业务处理器”。
你让 Kafka 去判断库存够不够？
当然炸。
Kafka 只管传，不管算。
这就是定位偏差带来的致命错误。2. 核心差异：三大方案硬核对比
市面上能当“平移台”用的技术不少。
但真正能扛住生产环境高并发的，也就这几家。
我选取了三个最具代表性的方案进行横向对比：
RabbitMQ、Kafka、Redis Stream。
这三个，覆盖了绝大多数后端场景。
为了让你一目了然，我整理了一张对比表。
请仔细看图，每一行都藏着面试陷阱。特性
RabbitMQ
Kafka
Redis Stream核心定位
业务消息路由
高吞吐日志/数据流
轻量级事件流吞吐量
万级 QPS
百万级 QPS
十万级 QPS延迟
毫秒级 (极低)
毫秒级 (略高)
微秒级 (极低)持久化
可选 (默认内存)
强制 (磁盘顺序写)
可选 (RDB/AOF)消息确认
手动/自动 ACK
Offset 提交
ACK (XACK)适用场景
复杂路由、事务消息
大数据同步、监控日志
实时计数、短时队列运维难度
中等
高 (集群复杂)
低官方文档
RabbitMQ.io
Apache Kafka
Redis.io重点解读：吞吐量差异巨大：Kafka 依靠磁盘顺序写，速度吊打其他两个。如果你的“平移台”是同步亿级用户的行为日志，选 Kafka 没商量。
延迟敏感型：如果是金融交易，要求毫秒内确认，RabbitMQ 或 Redis Stream 更合适。Kafka 的批量处理机制会导致轻微延迟累积。
运维成本：Kafka 集群搭建是噩梦。Zookeeper 或 KRaft 模式，配置稍有不慎，数据就乱了。Redis Stream 几乎零运维，随启随用。
消息可靠性：RabbitMQ 支持死信队列和延迟消息，功能最丰富。Kafka 一旦消息被消费，Offset 提交了，想找回很难（除非保留时间够长）。避坑提示：
很多新人喜欢用 Redis 做消息队列。
大错特错。
Redis 的 List 结构，如果消费端宕机，消息就丢了。
Stream 虽然好，但它的设计初衷不是持久化存储。
如果你的数据丢失了会导致市政工程款算错，别用 Redis 当“平移台”。
3. 代码写法对比：从报错到实现
光说不练假把式。
我们来看三种方案在 Java 中的实际代码写法。
注意，我特意保留了一些容易出错的细节。
对照你手里的 StackTrace，看看是不是踩了这些坑。
方案一：RabbitMQ (Spring Boot)
场景：订单创建后，平移库存扣减消息。
痛点：消息重复消费、事务不一致。
@Service
public class OrderService {@Autowiredprivate RabbitTemplate rabbitTemplate;@Autowiredprivate OrderMapper orderMapper;/*** 下单逻辑：本地事务 + 消息发送* 错误示范：直接在事务里发 MQ，可能导致事务回滚但消息已发出*/@Transactionalpublic void createOrder(OrderDTO dto) {// 1. 插入订单orderMapper.insert(dto);// 2. 发送消息到“平移台”// 坑点：如果这里抛异常，事务回滚，但消息可能已经发出// 正确做法：使用本地消息表 或 RocketMQ 事务消息rabbitTemplate.convertAndSend(order.exchange, order.created, dto);}
}@Component
public class InventoryConsumer {@RabbitListener(queues = inventory.queue)public void handleInventory(String msg) {// 坑点：没有幂等性处理// 如果 MQ 重发，库存会被扣两次InventoryDTO dto = JsonUtils.parse(msg, InventoryDTO.class);inventoryMapper.deduct(dto.getSkuId(), dto.getQty());}
}解析：
这段代码里，@Transactional 和 rabbitTemplate 的配合是经典雷区。
如果 insert 成功，但 send 失败，事务回滚，订单没了。
如果 insert 和 send 都成功，但后续业务逻辑报错回滚，订单没了，但库存扣了。
这就是“平移台”失控的后果。
解决方案：引入本地消息表，或者换用支持事务消息的 RocketMQ。
方案二：Kafka (原生客户端)
场景：海量传感器数据实时平移至数据仓库。
痛点：数据丢失、乱序。
public class SensorDataProducer {private static final String TOPIC = sensor-data-stream;private static KafkaProducerString, String producer;static {Properties props = new Properties();// 关键配置：确保数据不丢props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, kafka:9092);props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);// 坑点：acks=0 是默认值，数据可能丢// 必须设置为 all 或 -1props.put(ProducerConfig.ACKS_CONFIG, all);// 重试机制props.put(ProducerConfig.RETRIES_CONFIG, 3);producer = new KafkaProducer(props);}public static void sendSensorData(String sensorId, String data) {RecordMetadata metadata = null;try {// 关键：指定 Key，保证同一传感器的数据在同一个 Partition，避免乱序ProducerRecordString, String record = new ProducerRecord(TOPIC, sensorId, data);FutureRecordMetadata future = producer.send(record);// 同步等待结果，确保发送成功metadata = future.get();} catch (Exception e) {// 坑点：吞掉异常，导致数据静默丢失// 必须记录日志并告警System.err.println(Failed to send sensor data: + e.getMessage());}}
}解析：
Kafka 的坑在于顺序性和确认机制。
如果不设置 acks=all，Leader 节点挂了，数据就没了。
如果不指定 Key，同一传感器的数据可能发到不同 Partition，导致乱序。
在市政工程中，传感器数据乱序，可能触发错误的报警。
这就是为什么面试官喜欢问 Kafka 的 acks 参数。
方案三：Redis Stream (Lettuce)
场景：实时在线用户数统计。
痛点：内存溢出、消息堆积。
@Component
public class UserOnlineStreamHandler {@Autowiredprivate RedisTemplateString, String redisTemplate;private static final String STREAM_KEY = user:online:stream;@PostConstructpublic void initConsumerGroup() {// 创建消费者组，保证消息只被一个实例消费try {redisTemplate.opsForStream().createGroup(STREAM_KEY, ReadOffset.latest(), online-group);} catch (Exception e) {// 忽略已存在异常}}@Scheduled(fixedRate = 1000)public void consumeOnlineEvents() {// 坑点：没有使用 XREADGROUP，而是用了 XREAD// 这样消息不会被标记为已消费，导致重复处理StreamRecordsString, MapRecordString, String records = redisTemplate.opsForStream().read(StreamReadOptions.empty().count(10),StreamOffset.create(STREAM_KEY, ReadOffset.latest()));if (records != null) {for (MapRecordString, String record : records) {String userId = record.getValue().get(userId);// 业务逻辑：更新 Redis 计数器redisTemplate.opsForValue().increment(online:count);// 坑点：没有 ACK// 如果这里抛异常，下次轮询会重复读到这条消息// 应该使用 ack() 方法}}}
}解析：
Redis Stream 的 XREAD 和 XREADGROUP 是两回事。
XREAD 只是读取，不改变消息状态。
XREADGROUP 会将消息放入待处理列表 (Pending List)，消费后需要 XACK 确认。
如果不用 Group，高并发下多个实例会重复消费，导致在线数虚高。
这就是“平移台”在内存中的典型故障。
4. 适用场景：怎么选不踩坑？
技术没有银弹，只有场景适配。
结合市政公用工程的实际业务，我给你三条选型建议。
场景一：核心交易链路 (订单、支付)
推荐：RabbitMQ 或 RocketMQ
理由：可靠性第一：数据不能丢，不能错。
功能丰富：支持延迟消息（如订单超时取消）、死信队列（处理异常）。
事务支持：RocketMQ 的事务消息完美解决“本地事务+消息发送”的一致性问题。
避坑：不要用 Kafka 做核心交易，吞吐量虽高，但一致性保障较弱，运维复杂。场景二：大数据同步与日志收集
推荐：Kafka
理由：高吞吐：轻松应对百万级 QPS。
生态完善：与 Flink、Spark、Elasticsearch 无缝集成。
持久化：数据保留时间长，方便回溯和重放。
避坑：必须配置 acks=all 和 min.insync.replicas，确保数据不丢。场景三：实时统计与轻量级事件
推荐：Redis Stream
理由：低延迟：微秒级响应，适合实时大屏。
低运维：无需独立集群，复用现有 Redis。
轻量级：代码简单，开发效率高。
避坑：必须使用 Consumer Group 和 ACK 机制，避免重复消费。不要用它做持久化存储。场景四：混合架构 (推荐)
实际项目中，往往不是单选。
常见的组合拳：Kafka 作为主“平移台”，承接所有业务事件。
Flink 消费 Kafka，进行实时计算。
Redis 缓存计算结果，供前端实时查询。
MySQL 存储最终结果，供后台管理查询。
这种架构下，Kafka 是“大动脉”，Redis 是“毛细血管”。
各司其职，互不干扰。5. 选型建议与避坑清单
回到开头的那个 StackTrace。
报错不可怕，可怕的是你不知道错在哪。
在“平移台”的选型和实现中，我有五条血泪建议：幂等性是底线：
无论用哪种 MQ，消费端必须做幂等处理。
用 Set 记录已处理的消息 ID，或者用数据库唯一索引兜底。
没有幂等，就是给自己埋雷。监控不能少：
监控 MQ 的积压量 (Lag)。
如果 Lag 持续增长，说明消费端处理能力不足，或者下游服务挂了。
设置告警阈值，提前介入。灰度发布：
新上“平移台”逻辑时，不要全量切换。
先切 1% 流量，观察数据一致性，再逐步扩大。
市政系统一旦数据出错，整改成本极高。备份与恢复：
Kafka 的 retention.ms 设置要合理。
建议至少保留 7 天，方便问题排查和数据重放。
Redis Stream 的 maxlen 也要设置上限，防止内存爆满。不要过度设计：
小项目，用 Redis List 就够了。
别为了炫技，上 Kafka 集群。
运维成本是你看不见的负债。总结：
“平移台”不是孤立的技术点，它是架构中数据流动的枢纽。
选对技术，写对代码，做好监控。
你的 StackTrace 就会少一半，你的面试通过率就会高一大截。
这个知识点你面试被问过吗？留言说说
你是被 RabbitMQ 的事务消息坑过，还是被 Kafka 的乱序问题折磨过？
或者你在生产环境遇到过什么奇葩的“平移台”故障？
评论区聊聊，大家一起避坑。
毕竟，少踩一个坑，就少加一次班。
