随着业务不断扩展，用户规模和数据量呈现指数级增长，原有的单库同步写入方案逐渐暴露出显著的性能瓶颈。本文将分享我们在生产环境中，如何从基于 MongoDB 的单一架构演进到Kafka + ClickHouse 的分析架构的过程与思考。
一、业务背景与场景
我们的系统主要承担用户行为数据和业务数据的记录与分析。随着数据规模扩大，数据写入和分析查询对同一个 MongoDB 集群产生了巨大压力，具体表现包括:
- 接口响应时间增长，影响用户体验。
- 分析型查询阻塞了在线写入，导致偶发的请求超时。
- 数据存储增长带来集群扩容的复杂性。
面对以上问题，我们亟需一种既能保障高并发写入, 又能支撑复杂分析查询的架构。
二、原有架构概述
在早期阶段，我们采用了非常简单的方式：
- 所有数据同步写入 MongoDB。
- 前端的管理后台通过聚合管道直接进行分析查询。
- 后端接口写入和分析共享同一个数据库。
这种方案在最初阶段非常高效，开发成本低，迭代快。但随着日活和数据规模提升，这套架构已经无法满足性能要求。
三、性能瓶颈的表现
主要瓶颈体现在以下几个方面：
-
写入延迟增加
- 高并发写入时，MongoDB 单节点压力显著上升。
- 索引更新与写入操作耦合，响应时间持续增长。
-
查询吞吐下降
- 聚合查询消耗大量 CPU 和 I/O，阻塞写操作。
- 高峰期查询响应时间波动明显。
-
扩展受限
- 随着数据量增长，分片与扩容复杂度上升。
- 运维成本不断增加。
四、改造目标
基于上述挑战，我们明确了以下改造目标：
- 降低接口时延：将业务写入与分析解耦，避免互相影响。
- 提升分析能力：采用更适合大规模分析的存储引擎。
- 保持数据一致性：确保写入数据在各个存储系统的完整性与一致性。
五、新架构总览
为了解决这些问题，我们设计了如下新架构：
-
Kafka 引入
- 后端接口将写操作改为异步写入 Kafka。
- 实现写入解耦和流量削峰。
-
MongoDB + ClickHouse 双写
- Kafka 消费者从队列中消费数据。
- 数据分别落地到 MongoDB（业务存储）和 ClickHouse（分析存储）。
-
分析 API 独立
- 使用 NestJS 构建独立的数据分析 API。
- 专门为 Dashboard 提供高性能查询。
通过这种设计，写入与查询彻底解耦，系统的可扩展性和稳定性显著提升。
六、技术选型原则
在架构选型过程中，我们遵循了几个核心原则：
- 解耦性：通过引入 Kafka，生产和消费完全分离。
- 可扩展性：Kafka 与 ClickHouse 都具备良好的水平扩展能力。
- 低延迟：接口写入改为异步后，响应时间显著降低。
- 一致性保障：通过消费者的幂等写入和定期校验，保障数据一致。
七、总结
从单一 MongoDB 到分布式 Kafka + ClickHouse 架构的演进，是我们应对海量数据增长和性能瓶颈的重要里程碑。通过解耦写入与查询，我们不仅提升了系统的整体性能，还为未来的扩展和维护奠定了坚实基础。