工程选型

背景 社区里关于 MQ 的讨论大多默认了一个前提——这条链路已经决定要异步化了，然后才去争 Outbox 谁负责、幂等表怎么设计、顺序/重试怎么保（#589、#474）。但我在三个项目里反复撞到的是更前置的一个问题： «这条链路，到底该不该

背景 社区里关于分布式锁的内容已经很多，但几乎清一色是「锁怎么加才安全」：Redisson 看门狗续期在主从切换下丢锁、"SETNX + EXPIRE" 误删、时钟回拨打穿 TTL、Fencing Token 兜底——这些我都认同，也确实踩

背景 社区里我们最近把「写库 + 发消息」这条链路的正确性讨论得很充分：本地消息表 vs Outbox vs 事务消息（#589）、幂等该在 commit 前还是 commit 后做（#869）、消费失败后死信与人工补偿的分工（#82）、半

背景 带 3 年技术团队，负责过订单-库存-支付这条跨 3 个服务的链路。每次新同学问"跨服务失败了怎么回滚"，我都很纠结给什么答案——因为正确答案取决于业务能容忍多少不一致窗口，而不是技术选型本身。可偏偏选型又是面试必问、团队里最爱吵架的

背景 社区里聊幂等的帖子不少，但大多在讨论「要不要做幂等」「用唯一索引还是 Redis SETNX」这类表层问题。真正让我在评审会上吵过两次的，是一个更底层的顺序问题： «幂等判断的时机——是先 "INSERT INTO idempoten

背景 做全栈 3 年，几乎每个新项目第一个要定的就是"主键长什么样"。社区里聊消息中间件、聊 K8s 探针的帖子不少，但分布式 ID 选型这个话题反而很少被认真讨论。我最近做订单号、流水号、库存批次号三条链路的统一 ID 方案，重新翻了一遍