ByConity项目中的Trash Item清除机制优化分析

在分布式数据库系统ByConity中，数据分区(Part)的垃圾回收(GC)机制是保证存储空间高效利用的关键组件。近期在项目中发现了一个关于Trash Item清除效率的问题，本文将深入分析该问题的技术背景、产生原因以及解决方案。

问题现象

运维人员观察到系统在刚重启时能够快速清除Trash中的大部分数据，但随着系统持续运行，清除速度会逐渐变慢。日志显示GC线程虽然每次都能从底层存储(FDB)加载最大数量的条目(400个)，但这些条目在经过过滤后往往全部被判定为"不可删除"状态，导致实际回收效率低下。

技术背景

ByConity的GC机制采用两阶段设计：

1. 第一阶段标记可回收的数据为Trash状态
2. 第二阶段实际执行删除操作

当前实现中，GC线程会：

• 使用游标(phase_two_start_key)记录扫描位置
• 每次批量获取400个待删除条目
• 过滤掉不符合删除条件的条目(如TTL未过期)
• 根据回收结果动态调整下次调度间隔

问题根因分析

经过深入排查，发现问题源于以下几个技术因素：

1. 游标推进机制缺陷：当前实现只有在加载条目数小于limit时才会重置游标，导致系统可能长时间"卡"在一段密集的不可删除数据区域。

2. 实时表的高频写入：对于写入频繁的表(如每30秒产生700+新分区)，GC速度可能永远跟不上数据产生速度。

3. 自适应调度算法的局限性：连续多次回收失败会触发指数退避策略，进一步降低GC频率。

解决方案

经过社区讨论，确定了以下优化方向：

1. 改进扫描策略：采用"尽力删除N个条目"的机制，即使需要多次扫描也要确保每轮回收一定数量的数据。

2. 引入完整扫描周期概念：只有当游标完成一整轮完整扫描后，才触发退避等待机制。

3. 优化游标重置逻辑：在检测到扫描"绕回"起点时自动重置扫描状态。

4. 性能参数调优：适当增大gc_remove_part_batch_size等参数，提高单次处理能力。

实现细节

技术实现上主要修改了以下关键逻辑：

1. 移除了基于回收结果的简单退避策略，改为基于完整扫描周期的判断。

2. 增加了对扫描范围是否越界的检测，确保不会遗漏任何区域。

3. 优化了游标管理逻辑，在特定条件下自动重置扫描位置。

预期收益

这些优化将带来以下改进：

1. 显著提高高负载场景下的垃圾回收效率。

2. 避免系统因局部数据特征导致的GC"假死"现象。

3. 保持对存储后端访问压力的合理控制。

总结

ByConity通过这次Trash Item清除机制的优化，解决了分布式环境下高效垃圾回收的技术挑战。该方案既考虑了系统稳定性，又确保了资源回收的及时性，为大规模生产环境提供了更可靠的存储管理能力。未来还可以考虑引入基于时间的二级索引等进一步优化手段。