1. 项目背景与核心挑战作为在Java领域深耕八年的开发者我最近完成了一个日均写入量超过2000万条记录的高并发数据系统。这个系统采用Kafka作为消息队列MongoDB作为数据存储在初期上线时遇到了严重的性能瓶颈。经过一系列优化后最终将写入吞吐量从最初的5000条/秒提升到23000条/秒同时保证了99.9%的数据可靠性。这个架构的典型应用场景包括物联网设备数据采集如智能家居传感器数据用户行为日志收集如电商平台的点击流金融交易流水记录如支付系统的交易日志关键提示高并发写入系统的设计必须同时考虑吞吐量和数据一致性这是所有优化工作的基本前提。2. 架构设计与技术选型2.1 为什么选择KafkaMongoDB组合在技术选型阶段我们对比了几种常见方案方案写入吞吐量查询灵活性运维复杂度适用场景KafkaMySQL中等高关系型高需要复杂查询的事务系统KafkaRedis高低中纯缓存场景KafkaMongoDB高中文档型中日志类、设备数据类系统最终选择MongoDB的核心原因文档模型天然适合日志类数据的半结构化特性水平扩展能力优秀通过分片可以轻松应对数据增长写入性能优异特别是批量插入场景2.2 基础架构示意图[数据生产者] - [Kafka集群] - [消费者服务] - [MongoDB集群] ↑ [监控告警系统]3. Kafka层优化实战3.1 生产者配置优化Properties props new Properties(); props.put(bootstrap.servers, kafka1:9092,kafka2:9092); props.put(acks, 1); // 平衡可靠性与性能 props.put(linger.ms, 20); // 适当增加批量等待时间 props.put(batch.size, 16384); // 16KB批次大小 props.put(buffer.memory, 33554432); // 32MB发送缓冲区 props.put(compression.type, snappy); // 压缩减少网络传输关键参数说明acks1leader确认即返回比all更高效比0更可靠linger.ms适当增加可提升批量效果但会增加延迟实测发现snappy压缩率约60%CPU消耗在可接受范围3.2 消费者组设计我们采用了多消费者组架构实时处理组处理对延迟敏感的数据批量处理组处理可容忍分钟级延迟的数据备份组纯粹用于数据备份踩坑记录曾经因为所有消费者使用相同group.id导致数据重复处理后来通过严格的命名规范避免如app1-realtime-group4. MongoDB写入优化4.1 批量插入性能对比通过JMeter压测得到不同批量大小的性能数据批量大小平均吞吐量(条/秒)CPU使用率网络流量15,20035%12MB/s10018,70068%48MB/s50023,40082%52MB/s100022,10085%51MB/s结论批量大小500是最佳平衡点4.2 写入策略优化// 最佳实践配置 MongoClientSettings settings MongoClientSettings.builder() .applyToConnectionPoolSettings(builder - builder.maxSize(50).minSize(10)) .writeConcern(WriteConcern.JOURNALED) // 保证写入journal .readConcern(ReadConcern.LOCAL) .retryWrites(true) .build();关键优化点连接池大小根据实际负载动态调整使用JOURNALED而非MAJORITY在保证可靠性的同时提升性能启用retryWrites避免网络闪断导致数据丢失5. 异常处理与监控5.1 重试机制设计我们实现了指数退避重试策略public void insertWithRetry(ListDocument docs) { int retry 0; while (retry MAX_RETRY) { try { collection.insertMany(docs); break; } catch (MongoException e) { long waitTime (long) Math.pow(2, retry) * 1000; Thread.sleep(waitTime random.nextInt(500)); retry; } } }5.2 监控指标配置使用Prometheus监控的关键指标Kafka消费者lagMongoDB操作耗时分insert/update/query系统吞吐量按数据类型统计错误率按错误类型分类告警规则示例- alert: HighConsumerLag expr: kafka_consumer_lag 10000 for: 5m labels: severity: critical6. 性能压测数据在AWS c5.2xlarge实例上的测试结果场景吞吐量(条/秒)平均延迟(ms)99分位延迟(ms)初始配置5,20045210优化后23,4001895峰值压力31,200633207. 经验总结与避坑指南连接池管理不要过度放大连接池MongoDB每个连接对应一个线程建议公式poolSize (核心数 * 2) 磁盘数量索引策略写入密集型集合避免过多索引后台创建索引db.collection.createIndex({field:1}, {background:true})硬件选择MongoDB特别受益于SSD存储内存容量应能容纳热数据集的索引工作集文档设计避免大文档超过16MB将频繁更新的字段放在文档顶部分片策略基于查询模式选择分片键避免单调递增的分片键如时间戳这套方案已经在生产环境稳定运行14个月处理了超过50亿条数据记录。最大的收获是高并发系统优化必须建立在准确监控的基础上没有度量就没有优化。建议大家在实施前先建立完善的监控体系用数据驱动优化决策。