Cortex项目中的Ingester优雅缩容方案设计与实现

在分布式时序数据库Cortex的架构设计中，Ingester组件负责实时接收和存储指标数据。生产环境中经常需要对Ingester集群进行扩容或缩容，其中缩容操作尤其需要谨慎处理以避免数据丢失。本文将深入分析传统缩容方式的局限性，并提出一种创新的READONLY状态机制来实现安全、可控的Ingester缩容。

传统缩容方式的挑战

当前Cortex文档推荐的Ingester缩容流程存在两个主要技术痛点：

1. 数据完整性风险：要求先确保所有内存数据块（block）都刷新到持久化存储，这个异步过程难以实时验证
2. 查询性能下降：必须设置querier.query-store-after=0强制查询使用存储数据，丧失了Ingester本地查询的低延迟优势

这种"一刀切"式的缩容方式在需要保持查询性能的场景下尤其不适用，本质上是因为缺乏细粒度的状态控制机制。

READONLY状态的设计哲学

我们提出在Ingester生命周期中引入新的READONLY状态，其核心设计原则包括：

1. 状态隔离：与现有的ACTIVE、PENDING等状态并列，明确区分不同职责阶段
2. 读写分离：READONLY状态下拒绝写入但继续服务查询
3. 渐进式卸载：通过状态转换实现平滑缩容

状态转换示意图如下：

[ACTIVE] --(进入只读)--> [READONLY] --(数据清理)--> [TERMINATED]

关键技术实现

环形状态管理

在服务发现环（ring）中扩展状态过滤逻辑：

WriteOp = NewOp([]InstanceState{ACTIVE}) 
ReadOp = NewOp([]InstanceState{ACTIVE, READONLY})

这种设计保证：

• 写入流量只会分发到ACTIVE节点
• 查询流量可以同时访问ACTIVE和READONLY节点

控制平面接口

新增两个管理接口实现精细化控制：

1. 模式切换API：

POST /ingester/mode { "state": "READONLY" }

支持双向切换，允许运维人员在发现问题时回退到ACTIVE状态

2. 块存储检查API：

GET /ingester/blocks?local=true

返回本地存储的数据块清单，作为安全删除的决策依据

操作流程最佳实践

建议的缩容操作时间线：

1. T0时刻：通过API将目标Ingester切换为READONLY状态
2. T1时刻：等待query-ingesters-within时长（通常5小时）
3. T2时刻：确认无残留数据块后下线节点

这个流程相比传统方式具有三大优势：

• 无需全局配置变更影响所有查询
• 保持缩容期间查询性能稳定
• 提供可视化手段验证数据安全

架构演进思考

该方案体现了分布式系统设计中的重要原则：

1. 状态显式化：通过明确的状态机管理复杂生命周期
2. 操作原子化：每个状态转换都是可验证的独立操作
3. 故障可观测：提供检查接口降低运维复杂度

未来可考虑与Kubernetes Operator集成，实现基于自定义指标的自动扩缩容，这将使Cortex在云原生环境中具备更强的弹性能力。