服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

公司的支付系统出了个大事故。一笔订单因为网络抖动，支付回调超时了，系统重试了扣款。结果扣了两笔——用户投诉，财务对账发现了差异，运营逐笔人工退款。查日志发现，不是网络不通，是"半通"——第一次扣款请求发出去了，银联处理成功了，但响应在回来的路上丢了。系统认为扣款失败，又发了一次。 这种"网络半通"是分布式系统里最危险的情况——操作已经执行了，但调用方不知道。不加重试怕丢，加多了怕重。今天聊聊怎么用业务流水号加状态机，让重试在"安全"的边界内进行。 问题的本质：操作不是天然幂等的 HTTP 的 POST 不是幂等的，数据库的 INSERT 不是幂等的，银行的扣款接口更不是幂等的。如果不做任何处理，同一个扣款请求发两次，钱就会扣两笔。 分布式系统里有太多场景需要重试——网络抖动、超时、服务暂时不可用。重试本身是合理的，问题在于你拿什么来判断"这次重试的请求，上一次有没有已经成功过了"。 答案就是业务流水号。不是数据库自增 ID，不是 UUID，而是一个由业务方生成、全链路唯一、可用来判断"这条请求我见没见过"的标识。 业务流水号：请求的唯一身份证 业务流水号的核心原则：由发起方生成，....

前言 在微服务架构中，分布式事务的监控和告警是保障系统稳定性的关键环节： 事务可见性差：分布式事务跨越多个服务，难以追踪整体状态 故障定位困难：事务失败时，难以快速定位问题根源 告警不及时：传统日志监控无法实时发现异常 健康度缺失：缺乏对事务整体健康状态的量化评估 本文将详细介绍如何使用 Spring Boot + Micrometer + Prometheus + Grafana 构建分布式事务监控大盘，实现事务健康度实时监控和失败率秒级告警。 一、分布式事务监控挑战 1. 分布式事务的复杂性 ┌─────────────────────────────────────────────────────────────┐ │ 分布式事务执行链路 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 订单服务 │───▶│ 库存服务 │───▶│ 支付服务 │───▶│ 通知服务 │ │ ....

Redis事务又被回滚了？这5个核心原理让你彻底搞懂分布式事务！ 本文来自公众号【服务端技术精选】，专注Java后端技术干货分享 大家好，欢迎来到【服务端技术精选】！我是你们的老朋友，一个在后端踩过无数坑的程序员。 今天我们要聊的话题是Redis事务。相信很多小伙伴在使用Redis时都遇到过这样的困惑：明明觉得Redis的事务和MySQL事务差不多，但实际使用时却发现各种"不对劲"的地方。比如： Redis事务执行一半出错了，为什么不会回滚？ 为什么Redis事务里某个命令执行失败了，后面的命令还会继续执行？ Redis事务真的能保证数据一致性吗？ 如果你也有这些疑问，那今天这篇文章就是为你准备的！我会用最通俗易懂的方式，带你彻底搞懂Redis事务的那些事儿。 在开始之前，先给大家透露一下，Redis事务和我们熟悉的MySQL事务可不太一样，它更像是一个"打包执行"的功能，而不是真正的ACID事务。这也就是为什么很多人会踩坑的原因。 废话不多说，让我们直接进入正题！ Redis事务基础概念和原理 什么是Redis事务？ 首先，我们要明确一个概念：Redis事务和传统关系型数据库....