TranquilXuan

消息队列消息积压治理实战：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 │└──────┬────────┘ └──────┬────────┘ │ ...

每天输出一篇数据库实战之后，我发现了自己的三个瓶颈两个月前的一次组会上，Leader 突然问我：“你最近写了不少 MySQL 和 Doris 的文章，那你说说，如果现在让你从零设计一个存储引擎，你会怎么考虑？” 我愣住了。脑子里全是 Buffer Pool 的脏页刷新策略、Doris 的 Compaction 触发阈值、索引下推的执行流程——但这些碎片化细节像一堆散落在地上的乐高积木，我无法在短时间内拼出一个完整的结构。最后我只能含糊地说：“这个问题我需要再整理一下。” 那天晚上我没有继续写新的文章，而是打开了自己的博客目录，一篇一篇翻过去。四十七篇实战文章，从 MySQL 慢查询分析到 Doris 分区分桶策略，每一篇单独看似乎都“有点东西”。但当我跳出来审视这些内容时，一个不舒服的发现浮了上来：我好像一直在做知识的搬运工，而不是知识的建筑师。 三个瓶颈浮现连续输出带来的第一个幻觉是“我在变强”。文章一篇篇发出去，阅读量、点赞、收藏这些正反馈会强化这个感觉。但正反馈本质上是一个危险的信号——它告诉你“这条路走对了”，却不会告诉你“这条路通向哪里”。当我把四十七篇文章的标题全部列在表格 ...

MySQL 崩溃恢复实战：redo log、undo log 与 binlog 一致性的深度解析凌晨两点，告警群炸了：订单库 MySQL 实例宕机重启后，恢复流程跑了 40 分钟还没结束，所有依赖订单的微服务全部阻塞。DBA 在群里发了一句「正在恢复，请等待」，但没人知道这一等要多久。 那是我第一次意识到：崩溃恢复不是玄学，而是可以拆解、可以计算、可以优化的工程问题。 这篇文章，我们把 MySQL 崩溃恢复的底层机制彻底讲透，从 redo log 的 WAL 机制到 binlog 与 redo log 的两阶段提交，再到 LSN 驱动的恢复流程，最后给出生产环境可落地的参数优化方案。所有代码示例在 MySQL 8.0.32 上验证通过。 一、WAL 机制：先说 redo log 存在的意义1.1 如果没有 redo log，会发生什么？假设 InnoDB 没有 redo log，每次事务提交都需要把脏页立即刷回磁盘（ibd 文件）。这会导致两个致命问题： 随机写放大的性能灾难：一条 UPDATE 可能只改了一行 300 字节的记录，但 InnoDB 至少要刷一个 16KB 的页，而 ...