ByConity S3存储场景下ListObjects请求异常问题分析与解决方案

问题背景

在ByConity分布式数据仓库系统的实际部署中，用户遇到了一个典型的高负载问题：即使在没有数据写入的情况下，MinIO存储集群仍然持续出现高负载现象。通过监控发现，系统产生了大量ListObjects请求，导致存储服务资源消耗异常。

问题现象分析

根据用户提供的监控数据和日志信息，我们可以观察到以下几个关键现象：

1. 异常请求模式：系统持续产生大量S3 ListObjects API调用，频率远超正常业务需求
2. 资源消耗：MinIO集群CPU利用率长期维持在100%
3. 时间持续性：问题在系统无写入操作的情况下仍持续存在
4. 错误日志：频繁出现文件不存在的错误（Errno 2）

技术排查过程

通过对系统状态的深入分析，技术团队进行了多维度排查：

1. 系统部件检查

首先检查了系统中各关键组件的状态：

• Server节点：正常运行
• Worker节点：正常运行
• Daemon Manager：正常运行

2. 数据状态分析

通过查询系统表获取数据分布情况：

• system.cnch_parts表显示存在34,731个数据分区
• 其中34,503个为可见分区(VisiblePart)
• 28个为逻辑删除分区(Tombstone)
• 28个为已删除分区(DroppedPart)
• system.cnch_trash_items表显示有368个待清理项

3. 错误日志分析

系统日志中反复出现以下关键错误：

CnchMergePrefetcher: Fail to copy byconity/xxx/data to byconity/auxility_store/xxx
Cannot open file byconity/auxility_store/xxx, errno: 2, strerror: No such file or directory

该错误表明系统在执行Merge任务的预取(prefetch)操作时，无法在本地找到预期的目录结构。

根本原因定位

综合各项分析，确定问题根源如下：

1. Merge任务失败循环：系统持续尝试执行Merge操作，但由于预取阶段无法找到本地目录而失败，触发自动重试机制
2. S3请求风暴：每次失败的Merge操作都会触发对S3存储的ListObjects请求，形成恶性循环
3. 目录结构异常：检查发现worker节点的auxility_store目录为空，与预期结构不符

解决方案与建议

针对该问题，推荐采取以下解决措施：

1. 临时缓解方案

• 停止Daemon Manager服务，观察请求量变化
• 清理系统临时文件和缓存目录
• 检查并修复本地目录权限

2. 根本解决方案

1. 目录结构修复：

   • 验证并重建正确的目录结构
   • 确保auxility_store目录具有适当权限

2. 配置检查：

   • 核对S3存储相关配置项
   • 验证本地存储路径配置是否正确

3. 系统维护：

   • 执行系统表一致性检查
   • 清理无效的分区记录

3. 长期优化建议

1. 错误处理机制改进：

   • 增加预取失败时的回退机制
   • 优化错误重试策略

2. 监控增强：

   • 实现Merge任务状态的实时监控
   • 设置S3 API调用频率告警

3. 资源隔离：

   • 为关键操作配置资源配额
   • 实现存储请求的限流机制

经验总结

这次问题排查过程揭示了分布式系统中几个重要原则：

1. 雪崩效应防范：单个组件的异常可能引发连锁反应，需要设计完善的熔断机制
2. 状态一致性：存储系统的本地状态与远程状态必须保持严格一致
3. 监控全面性：不仅要监控业务指标，也要关注底层存储访问模式

通过这次问题的解决，也为ByConity系统的稳定性优化提供了宝贵经验，未来版本将会在这些方面进行持续改进。