TranquilXuan

消息队列幂等消费与消息去重实战：基于 MySQL 订单系统的 Redis + RabbitMQ 方案一、问题场景：一条延迟消息引发的“血案”订单系统里有一个经典场景：用户下单后 30 分钟未支付，系统自动关单并释放库存。 我们采用 RabbitMQ 延迟队列（通过死信交换机 + TTL 实现）来触发关单逻辑。架构如下： 1订单服务 ──发布延迟消息──> RabbitMQ（TTL 30min）──> 死信交换机 ──> 关单队列 ──> 关单消费者 这个方案本身没有问题，但上线后我们遇到了三类典型的重复消费场景： 场景 原因 后果 消息重复投递 网络抖动导致 Producer 重试，RabbitMQ Broker 未收到 ack 但消息已入队 同一条消息被投递两次 消费者重试 关单逻辑执行成功但 ack 超时，Broker 重新投递 关单操作执行两次 并发消费 消费者实例水平扩容，同一消息被不同实例同时拉取（极端情况） 库存重复释放 这些问题的本质是：消息中间件保证的是“至少一次投递”（At-Least-Once），而不保证“恰好一次” ...

Redis 大 Key 与热 Key 治理实战：基于 MySQL 高并发读场景的内存分析与拆分方案一、问题场景：一场大促引发的缓存危机某电商系统大促期间，商品详情接口 QPS 从日常 500 飙升到 2 万。为了扛住高并发读，团队在 MySQL 前加了 Redis 缓存。起初效果显著，数据库压力骤降，但活动开始一小时后，Redis 延迟出现周期性毛刺，部分请求响应从 2ms 劣化到 200ms，甚至出现超时。监控显示 Redis 实例 CPU 使用率接近 100%，但整体 QPS 并不高。 排查发现两个典型问题： 某个商品详情缓存 value 是一个完整的 JSON，包含商品基础信息、SKU 列表、评论摘要、推荐列表等，序列化后超过 5MB，属于典型的大 Key。 该商品正好是活动主推款，单 key 的 QPS 超过 8000，属于典型的热 Key。 大 Key 导致 Redis 单线程在处理该 key 的读写时占用大量 CPU 时间，热 Key 又使这个操作被高频触发，最终阻塞其他请求。这引发了我们对 Redis 大 Key 与热 Key 的系统性治理。 二、大 Key 与热 K ...

消息队列消息积压治理实战：RabbitMQ 消费者扩容、死信队列与监控告警故障复盘：订单状态机“卡死”的深夜凌晨 1 点，大促流量高峰刚刚过去，客服群里开始刷屏：“用户支付成功了，但订单状态一直是‘待支付’！”、“退款流程走不了，用户要投诉。” 打开 RabbitMQ 管理界面，心跳瞬间加速：order.event.queue 队列深度已经突破 300 万，消费者速率只有 200 条/秒，而生产者速率峰值时达到 5000 条/秒。更可怕的是，积压还在以肉眼可见的速度增长。 这是我们团队在订单系统上遇到的一次真实生产事故。系统拓扑很简单：用户支付成功后，支付回调服务将“支付成功”事件投递到 RabbitMQ，订单服务消费该事件，更新订单状态并触发后续流程（库存扣减、积分发放、通知用户）。问题出在订单服务这一环——单条消息处理时间从正常的 50ms 恶化到 2 秒以上，因为数据库查询没走索引，外部物流接口超时未设置合理超时时间，加上预取参数默认值过大，导致消费者不堪重负。 这次故障让我深刻体会到：消息积压不是消息队列的问题，而是消费端系统问题的放大镜。消息队列忠实地把上 ...

Doris Workload Group 资源隔离实战：查询并发控制与 CPU/内存配额调优一、一次大查询引发的线上事故上个月某个周五下午，我们的实时数据看板突然疯狂告警：查询延迟从 200ms 飙升到 8 秒，部分接口直接超时。与此同时，数据团队正在跑一个全量用户行为分析 SQL，扫描了 2 亿行数据，还带了多个 JOIN 和 GROUP BY。 排查发现，Doris 集群的 BE 节点 CPU 全部打满，内存使用率接近警戒线，部分大查询甚至触发了 BE 进程 OOM。小查询（点查、简单聚合）和这个大查询在同一批 BE 上运行，没有任何隔离，资源被大查询全部抢占，导致在线业务雪崩。 这就是典型的资源争抢问题：没有资源隔离时，Doris 中所有查询默认使用同一个资源池，大查询会无限制地消耗 CPU 和内存，拖垮整个集群。 解决思路就是引入 Workload Group（负载组），对不同类型的查询进行资源配额和并发控制。 二、Doris Workload Group 是什么Workload Group 是 Apache Doris 2.0 引入的资源隔离机制，它允许我们将查询按 ...

Redis ZSet 延迟队列实战：MySQL 订单超时关单的可靠实现与重试机制订单超时自动关闭是电商系统里最典型的延迟任务场景：用户下单后如果 30 分钟未支付，系统需要自动取消订单并释放库存。这个需求看似简单，但实现起来要考虑可靠性、幂等性、重试机制和最终一致性。本文以 Spring Boot 3 + MySQL 8 + Redis 7 为技术栈，手写一个基于 Redis ZSet 的延迟队列，完成订单超时关单的完整闭环。 一、为什么不用现成的消息队列？延迟任务实现方案有不少，我们列举最常见的三种： 方案 实现复杂度 可靠性 延迟精度 适用规模 备注 Redis ZSet 轮询 低，自己写轮询 中，需要自行处理 ACK/重试 秒级 中小规模 无额外中间件，运维成本低 Redisson DelayedQueue 低，封装好 高，自带 ACK/重试 毫秒级 中大规模 依赖 Redisson，侵入业务代码 RabbitMQ 延迟插件 中，需要安装插件 高，依赖 MQ 本身 秒级 大规模 需要运维 RabbitMQ，增加系统复杂度 对于创业初期或 ...

Redis Stream 消息队列实战：基于 MySQL 订单系统的异步解耦与可靠消费1. 场景与问题一个典型的订单创建接口，往往要完成以下动作： 校验库存 写入订单表 扣减库存 发送短信通知 推送 App 消息 记录审计日志 如果第 4、5、6 步在同一个同步事务里执行，接口响应时间会被外部服务拖慢，甚至因为短信网关超时导致订单创建失败。更糟的是，订单核心逻辑与通知、日志等非核心逻辑耦合在一起，任何一个下游出问题都会影响主流程。 我们需要引入消息队列做异步解耦。但为此单独部署一套 RabbitMQ 或 Kafka，对中小型项目来说运维成本偏高。Redis 5.0 之后提供的 Stream 数据结构，恰好能作为轻量级消息队列使用，尤其在亿级以下的消息量场景中，表现足够可靠。 本文以一个基于 MySQL 的订单系统为背景，演示如何用 Redis Stream 实现订单创建后的异步通知、削峰填谷和可靠消费。 2. 为什么是 Redis StreamRedis Stream 是一个 append-only 的日志数据结构，支持： 消息持久化：消息写入后不因消费者掉线而丢失，除非 Red ...

Doris 前缀索引与 BloomFilter 索引实战：高并发点查与基数过滤优化线上订单查询接口的 P99 延迟从 860ms 飙到 2.3s，Doris 集群 CPU 水位持续 75%+。排查发现慢查询全部集中在两张核心表上：一张是按天分区的订单明细表（每天 3000 万行），另一张是用户行为流水表（累计 20 亿行）。这两张表的共同问题是——查询条件里既有高选择性的等值条件，也有非排序键上的高基数字段过滤。 这篇文章只讲一件事：如何用 Doris 的前缀索引 + BloomFilter 索引，把这类查询从秒级压到毫秒级。 所有实验基于 Doris 2.0.15，表结构和查询语句均可直接复用。 一、先看清楚问题：为什么排序键没生效看下面这张表，是同事初版设计： 1234567891011121314151617181920212223-- 实验环境：Doris 2.0.15，3 个 BE 节点，每个 BE 16 核 / 64GB 内存CREATE TABLE `order_detail_original` ( `order_id` BIGINT COMMENT '订 ...

基于 MySQL Binlog + Canal 的 Redis 缓存一致性实战：异步更新与最终一致性方案问题场景：为什么缓存一致性这么难？假设你有一个用户信息接口，QPS 上了万级后，你自然想到用 Redis 挡一层。写操作时先更新 MySQL，再删除 Redis 缓存，读操作时缓存未命中就回源 DB 并重建缓存。这个流程看起来没问题，直到某天线上出现了「用户改了昵称，但 App 上显示的还是旧昵称」的 Bug。 排查发现：更新 MySQL 和删除 Redis 这两个操作不是原子的。如果删除 Redis 的动作因为网络抖动失败了，缓存里就一直是脏数据。你可能会说，那用事务或者消息队列做「双写」，但事务跨 MySQL 和 Redis 并不现实，而手动双写又容易漏掉某些业务入口——比如有人直接通过 SQL 改了库，或者有批量任务绕过了 Service 层。 真正的问题是：缓存的更新逻辑和业务代码耦合在一起，只要有一个入口没管住，缓存就会脏。 有没有办法让 MySQL 的数据变更被自动、完整地捕获，然后异步同步到 Redis？答案就是 MySQL Binlog + Canal。这也是我这几年 ...

Redis 集群与高可用实战：从主从复制、Sentinel 到 Cluster 的故障转移与容量规划缓存层单点故障是生产事故重灾区。某次大促前压测，我们一个 Redis 实例内存打满导致所有请求穿透到 MySQL，数据库连接池瞬间耗尽。从那以后，我开始系统性地研究 Redis 高可用方案。这篇文章从主从复制到 Cluster，把搭建、故障转移、容量规划完整走一遍。 1. 从主从复制开始：解决数据冗余与读扩展单机 Redis 一旦宕机，所有读请求直接打到 MySQL，这是典型的缓存雪崩。主从复制是最基础的冗余方案：一个 master 负责写，多个 slave 负责读，同时 slave 保留数据副本。 1.1 主从复制原理简述Redis 主从复制分为全量同步和增量同步两个阶段： 全量同步：slave 首次连接 master 时，master 执行 bgsave 生成 RDB 快照并发送给 slave，slave 加载快照后，master 再把快照期间的写命令通过 replication buffer 发送给 slave。 增量同步：全量同步完成后，master 持续将写命令发送给 sla ...

Prometheus + Grafana 监控 MySQL 与 Doris 性能指标实战：从数据采集到告警规则设计生产环境同时跑 MySQL 和 Apache Doris 时，最尴尬的情况是：MySQL 连接数打满导致业务报错，DBA 还在一个个 SHOW PROCESSLIST；Doris 查询延迟升高，只能等用户投诉才发现。本文不绕弯子，从零搭建 Prometheus + Grafana 监控体系，覆盖 MySQL 与 Doris 的核心性能指标采集、面板可视化和告警规则设计，并演示如何用监控面板快速定位一次真实的性能瓶颈。 1. 监控架构与指标清单整体架构如下： 1234567891011121314151617181920212223┌───────────────┐ ┌───────────────┐│ MySQL 8.0 │ │ Apache Doris ││ (业务库) │ │ FE / BE │└──────┬────────┘ └──────┬────────┘ │ ...