【FFA 2026】Real-Time Analysis 2 构建可信赖的流存储：Fluss 在阿里云的稳定性工程与最佳实践

郑云红真正的稳定，源自海平面下巨大而坚实的底座夯实稳定性底座，迈向Agentic运维运营分析实时推荐用户画像模型风控应用场景湖流一体DeltaJoin查询下推实例管理库表管理监控报警产品能力跨AZ容灾数据一致性保证租户隔离基于开源ApacheFluss构建·企业级实时分析&AI流式存储运营分析实时推荐用户画像模型风控应用场景湖流一体DeltaJoin查询下推实例管理库表管理监控报警产品能力跨AZ容灾数据一致性保证租户隔离AI多模态节点秒级恢复数据湖数据湖湖流一体同步湖流一体同步CoordinatorCoordinator冷存储Tiering冷存储TieringTabletServerTabletServerTabletServerTabletServerTabletServerTabletServer乡▦核心能力乡▦◆稳定性保证实时数仓·湖流一体列式流存储稳定性保证实时数仓·湖流一体FlinkFlink+Fluss端到端毫秒级延迟与阿里云全托管DLF深度绑定->冷数据实时入湖TieringService全托管，支持AutoScale跨AZ容灾数据一致性写入&秒级恢复Rebalance&集群扩缩容Agentic主动运维ApacheArrow列存+流式订阅列裁剪/谓词下推：查询I/O↓10×条件下推（FilterPushdown）:查询数据量↓50%DeltaJoin：FlinkCPU/内存↓86%稳定性冰山模型真正的稳定，源自海平面下巨大而坚实的底座跨AZ容灾数据一致性冰山之上用户可感知Rebalance及扩缩容冰山之上用户可感知集群健康分磁盘禁写保护Tiering任务弹性扩缩容跨基础设施逃逸冰山之下底座能力逐台可控升级底座能力稳定性租户隔离/Region隔离KV快照机制&秒级恢复全局监控质量工程Agentic运维跨可用区（AZ）容灾3AZ对等架构·数据3副本同步复制·Coordinator跨AZ高可用数据面3副本同步复制●TabletServer跨3个AZ均匀分布：同一bucket的3个副本被强制放置在不同AZ的不同TabletServer上。●写入路径：客户端先发到Leader副本，Leader同步复制到另外2个AZ的Follower；多数副本ack后才向客户端返回成功，保证任一AZ故障数据零丢失。●热数据用各AZ本地磁盘；冷数据同步到跨AZ冗余的高可用对象存储控制面CoordinatorServer跨AZ高可用●CoordinatorServer跨AZ部署：任一AZ故障不影响集群管控（元数据/副本调度/Rebalance/心跳监控持续可用），管控面无单点。●故障切换：Coordinator检测故障AZTabletServer不可达→故障AZ副本下线→剩余2AZ的Follower自动接管并重新选Leader→客户端透明重连，无需重启或人工介入。●恢复：系统在存活AZ拉起新TabletServer补齐副本；若资源不足、未恢复节点数≥集群1/3，集群进入“亚健康”——读写仍可用但容灾能力降级，需立即关注。3AZ部署示意FFollowerAZ-1AZ-2AZ-3TabletServerTabletServerTabletServerCoordinatorServer跨AZHACoordinatorServerCoordinatorServerFollower数据一致性·写入路径同步保序Leader单点排序同步保序Leader单点排序读到即提交Consumer仅可读offset≤HW只读已被全副本确认的数据，读不抖⑤对外服务fetch提交数据④HW=min(LEOs)①Writersend(record)领头副本ack(LEO)min.insync满足确认ISR足才算齐②领头副本FetchRequest复制给所有ISR③已落盘已落盘写入承诺落盘+多副本均确认才返回，承诺即不丢现象慢副本/GC/网络抖动风险若继续放行写入→留下「少副本数据」，节点重启后可能丢现象慢副本/GC/网络抖动风险若继续放行写入→留下「少副本数据」，节点重启后可能丢•客户端拿到明确NotEnoughReplicas错误•宁可不写，也不假装提交现象集群两半互相不可达风险客户端读到两个版本/写入被冲突覆盖/不可调和的元数据冲突•Coordinator主备靠ZK选主•任意时刻只有一个Epoch是合法的•落后任期的写入全部被拒收现象现象风险老Leader苏醒后仍以为自己是主→双主双写→数据分叉•每次选举Epoch++写元数据•老Leader写请求被FencedLeader拒绝•Follower按Epoch截断错位前缀Goal优先级链·增量迁移·读写零抖动同同bucket副本分散到不同AZ/机架抗AZ/机架级故障③LEADER_DISTRIBUTION各TabletServerLeader数量均衡读写流量分摊各TabletServer副本数量均衡避免存储倾斜弹性扩缩容新Server注册→rebalance(REPLICA,LEADER)→部分副本平滑迁入addServerTag(PERMANENT_OFFLINE)→rebalance()把数据搬空→摘节点本地数据存储量/LogSegments/Leader/Replica/WriterCount—多节点单调收敛，无尖刺，无重试风暴集群健康诊断读写性能用户感知体验数据副本副本健康度退化资源水位物理资源水位线读写性能用户感知体验数据副本副本健康度退化资源水位物理资源水位线局部热点→级联放大磁盘使用率写入/查询错误率副本分布不均磁盘使用率写入/查询错误率副本分布不均读写倾斜TieringService自动扩缩容核心算法·按表权重throughputᵢ核心算法·按表权重throughputᵢ=pendingRecordsᵢ÷freshnessᵢP_target=⌈Σthroughput÷capacity×buffreshness短的表权重天然更高·无需额外优先级操作最小间隔3min决策周期30s实测4→6core动态扩容≈20s·reader不触发重试更多稳定性能力守住流存储的最后一道防线消费方持租约，快照不被回收磁盘禁写保护超过保护上限停写/磁盘容量降低自动恢复云监控告警接入阿里云云监控，集群异常立刻感知基础设施逃逸底层硬件/网络故障的自动隔离与恢复Region不可用Region不可用可用区不可用可用区不可用磁盘故障磁盘故障快照是什么Leader在RocksDB上做物理快照（SST文件+metadata），按周期checkpoint上传到远端对象存储；快照=KV状态在某个changelogoffset上的可恢复点，所有恢复都从这里开始。增量上传复用RocksDB的hard-link机制，新快照只上传与上一次差异的SST文件。GB级状态的快照量级降到MB，对带宽与IO几乎无侵入，可以做到分钟级周期。恢复路径新Leader从远端拉取最新有效快照→加载SST重建RocksDB→从快照对应的changelogoffset开短尾日志，远小于全量重放。为何能做到秒级StandbyReplica常驻预热，增量下载快照文件，热数据已在磁盘中可零拷贝接管；逐台可控升级等待等待前序重启中...检查中...重启完成✓GREEN重启完成✓GREENISRISR副本完整性少1副本即YELLOW—阻塞升级Leader全部就绪快照恢复完成KVsnapshotrestored未恢复不放行—保护数据安全对比：传统TCP探活仅检查端口连通→无法感知ISR/Leader→滚动升级≈滚动故障质量工程协议不变量·秒级反馈每次提交性能基线每日回归新老client/server矩阵全链路真集群验证每天/发版Kill/丢包/磁盘满预发集群常驻Agentic主动运维（建设中）①观测②推理③行动④验证①观测②推理③行动④验证巡检场景la集群日志巡检拉SLSERROR/WARN日志→LLM按类别归类→Top-N异常+受影响节点+处置建议Tiering作业巡检每张表的Tiering作业healthy/lag/pendingRecords/freshness，自动定位异常taskTiering资源调度反压感知+资源画像→动态调parallelism/memory，把人盯几百个tiering作业变成AI盯，人审批副本健康自愈ClusterHealthAPI→ISR/Leader偏差判定→自动起rebalance→工单闭环未来展望夯实稳定性底座，迈向Agentic运维未来稳定性优化—5个深水区方向毫秒级metadata更新写吞吐线性扩展到N盘磁盘/读写/带宽多维均衡故障替换→秒级扩缩容/升级/迁移更顺滑替换ZooKeeper元数据服务规模化KV稳定性深水区JBODPhase2写入路径多盘隔离+坏盘热替换RebalanceGoal增强业务画像驱动均衡存算分离架构演进KV状态远端存储Agentic运维演进—4个落地方向从『集群可巡检』到『链路可解释』—把Agent推到产品0101全面落地Agentic主动运维5类巡检线上默认开启·全Regio