开篇：微服务拆分后，事务怎么办？

假设你要从工商银行转 1000 块钱到建设银行。工商银行扣了你 1000，但建设银行那边因为系统故障没有加上。这笔钱就"人间蒸发"了。

在单体应用中，扣款和加款在同一个数据库里，用一个本地事务就能保证要么都成功、要么都回滚。但微服务拆分后，订单服务、库存服务、账户服务各用各的数据库，一个本地事务管不了跨数据库的操作。

这就是 分布式事务 要解决的问题：如何让分布在不同服务、不同数据库上的多个操作，像一个事务一样，要么全部成功，要么全部回滚。

Seata（Simple Extensible Autonomous Transaction Architecture）是阿里巴巴开源的分布式事务解决方案，目前是这个领域最主流的框架之一。

开篇：消息队列在生产环境最容易踩的坑

消息队列是分布式系统的血管。用得好，系统解耦、异步高效、削峰填谷。用不好，消息丢了不知道、重复消费造成脏数据、积压百万条把下游拖垮。

这篇文章从实战角度出发，把 MQ 在生产环境最容易遇到的几个场景拉出来过一遍：消息丢了怎么排查、重复消费怎么做幂等、积压了怎么快速消化、Kafka 吞吐量怎么优化。每个场景都带真实方案。

一、消息丢失场景与排查

消息从生产到消费，要经过三个环节：生产者发送、Broker 存储、消费者消费。每一个环节都可能丢消息。

生产者端丢失

生产者发送消息时，网络抖动导致发送失败，或者发送成功但没收到 Broker 的 ACK 就认为失败了。