分布式事务深度分析：Saga + Outbox文档定位：讲清「跨服务一致性」里最常用的组合拳——Saga（编排/补偿）+ Outbox（可靠投递）。 刻意剥离：不绑定理财 / 资产 / 订单等具体域名；用抽象角色（发起方、参与方、资源方）说明。 阅读目标：知道各自解决什么问题、为何常一起用、失败怎么收、何时不该用。目录问题本质：分布式下没有免费的 ACID先分清两层问题Saga：业务级长...

在落地 Pulsar 的过程中，开发者最容易踩的坑集中在两个问题上：问题一："我有多个消费者，消息是怎么分发的？顺序能保证吗？"问题二："消费者处理业务逻辑很慢，会不会把整个消费流程阻塞住？"这两个问题的答案，分别对应 Pulsar 的订阅模式（Subscription Type） 和消费模型（Consumption Pattern）。本文基于 Go 语言，通过完整可运行的代码，逐一拆解四种...

写给自己的 Consul 入门笔记。搞清楚"它是什么、解决什么问题、怎么工作的"。一、背景：没有 Consul 之前假设你有三个服务：订单服务、用户服务、支付服务。问题 1：配置怎么管？# 每个服务各自写死配置 DB_URL=postgres://localhost:5432/order REDIS_ADDR=localhost:6379 PAY_SECRET=abc123改一个配置 → 要...

写在前面：我是个后端开发，用过 Redis 的 Pub/Sub，听说过 Kafka，但从来没有认真用过消息队列。这篇文章记录我第一次接触 Apache Pulsar 的全过程，踩了哪些坑，怎么理解那些概念，希望对同样是新手的你有用。为什么会接触 Pulsar？项目里有个需求：多个服务之间要传消息，而且要可靠——发出去的消息不能丢，消费失败了要能重试，还要支持多个服务同时消费同一条消息。Red...

消息队列不只是"生产-消费"那么简单。在真实的业务场景中，我们需要面对消息消费失败、延时执行、顺序保障等各种复杂问题。本文梳理六种常见的队列模式，帮你建立完整的消息队列知识体系。一、死信队列（Dead Letter Queue）是什么死信队列（DLQ）是用来存放无法被正常消费的消息的特殊队列。当一条消息反复消费失败、超过最大重试次数，或者因为格式错误无法解析时，它不会被直接丢弃，而是被转移到...