TranquilXuan

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 的页，而 ...

Doris Compaction 原理与查询性能优化实战凌晨两点，监控群里突然弹出告警：user_behavior 表的查询 P99 延迟从 45ms 飙到 800ms。第一反应是“谁又在上线？”但检查后发现是夜间高频导入任务在持续写入。深入排查 BE 节点后，发现 12 张 Tablet 的 CumulativeCompactionScore 全部超过 500，磁盘上堆积了上千个小 Rowset。 这篇文章不会从“什么是 Doris”开始，我会直接复盘这次 Compaction 积压的排查和优化过程，并给出可运行、可验证的实验步骤。 1. 问题表现：查询为什么突然变慢Doris 的写入路径很清晰： 123写入 -> MemTable -> 刷盘 -> Rowset（小文件） \-> Rowset \-> Rowset ... 每一批导入都会在磁盘上生成一个或多个 Rowset。如果导入频率高、批次小，就会产生大量“小 Rowset”。查询时需要扫描所有这些文件， ...