Cloudflare的账单生成任务突然撞上了每日截止期限。排查所有常规指标——I/O、内存、扫描行数、读取数据块——一切正常。问题最终指向一个从未被怀疑过的环节:查询规划阶段的锁竞争。
这场故障源于一次看似成功的数据库改造。Cloudflare在2022年搭建了名为"Ready-Analytics"的统一分析平台,让数百个内部团队无需设计新表,直接将数据流写入一张巨型表。数据通过namespace字段区分,配合indexID和时间戳构成主键,到2024年12月已积累超过2PiB数据,每秒摄入数百万行。
![]()
但统一架构有个致命缺陷:按天分区的设计只能执行31天全局保留策略。有的团队因法律合同需保存数年数据,有的只需几天,这种"一刀切"迫使许多场景放弃便利的Ready-Analytics,转向复杂的传统方案。
团队决定改造分区策略,在分区键中加入namespace字段,实现按租户自定义保留期。方案经过多轮跨团队评审,上线几周后却意外触发了账单管道的性能危机。
深入调查揭示了ClickHouse内部的一个隐藏瓶颈——查询规划器中的锁竞争。当数百个namespace的并发查询同时争夺规划锁时,原本微不足道的延迟被放大成系统性阻塞。Cloudflare工程师为此编写了补丁修复该问题。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.