TranquilXuan

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”。查询时需要扫描所有这些文件， ...

Redis 分布式锁实战：基于 Redisson 的可靠锁方案与 MySQL 并发更新保护从一个库存扣减的线上故障说起去年双十一前夜，我负责的订单服务突然收到告警：大量请求返回 500，数据库连接池被打满。排查日志后发现，一个看似简单的库存扣减接口，在压测时出现了严重的超卖——100 件库存的商品，最终卖出了 137 件。 问题出在这段代码上： 123456789101112131415161718192021222324252627// 问题代码：先查后改，非原子操作@Servicepublic class InventoryService { @Autowired private JdbcTemplate jdbcTemplate; public boolean deductStock(Long productId, int quantity) { // 第一步：查询当前库存 Integer current = jdbcTemplate.queryForObject( " ...

Doris Bitmap 索引实战：高基数精确去重与用户行为分析优化最近在做一个用户行为分析平台，需要实时统计 UV（独立访客）、留存、漏斗等指标。一开始图省事，直接用 COUNT(DISTINCT user_id)，结果 5 亿条日志的查询直接超时。运维建议用 HLL（HyperLogLog）近似去重，但产品经理无法接受 2% 的误差。最后在 Doris 里用 Bitmap 解决了问题——精确去重、性能还快。这篇文章把完整的实战过程记录下来，包括建表、导入、查询和性能对比。 一、问题场景用户行为日志表结构大致如下： 字段 类型 说明 event_time DATETIME 事件时间 dt DATE 事件日期（分区键） page_id INT 页面 ID user_id BIGINT 用户 ID 典型查询需求： 实时 UV：统计某天各页面的独立访客数。 次日留存：昨天访问过某页面的用户，今天又访问了该页面的数量。 7 日留存：一周内连续活跃用户数。 传统方案： COUNT(DISTINCT user_id)：精确但性能差，大数据量下内存消耗巨大。 HL ...

Redis 缓存穿透、击穿、雪崩实战：基于 MySQL 高并发读场景的完整防护方案先抛一个真实场景：某电商大促期间，商品详情页 QPS 从日常 200 飙到 8000，MySQL 单机 CPU 瞬间打满 100%，大量请求超时。查看慢查询日志，发现全是同一条 SELECT * FROM product WHERE id = ?，而这个 id 对应的商品其实早已下架，缓存里没有，数据库里也没有——但请求还在源源不断地打进来。 这就是典型的缓存穿透。而接下来半小时内，另一个热点商品突然过期，瞬时几千个请求同时回源 MySQL，把刚喘过气的数据库又打挂了——这是缓存击穿。紧接着，运维触发了一次缓存批量过期，导致大量 key 同时失效，缓存层形同虚设，MySQL 再次宕机——这是缓存雪崩。 三个问题，一个比一个致命。本文从真实高并发读场景出发，逐一剖析成因、给出可落地的 Java 代码方案，并用压测数据说话。 一、先理解：为什么缓存层会失守在引入 Redis 之前，高并发读 MySQL 的典型架构是这样的： 1[App] --> [MySQL] 所有请求直达数据库，MySQL 单机 ...