美团万亿级对象存储挑战和实践探索

1. 宣宇

2. 目录

3.

4.

5. ⚫ 规模：万亿级对象、EB级存储 ⚫ 场景：静态资源、多媒体数据、文档、模型、备份等 ⚫ 增速：50%~100%/年

6. 从开源的openstack swift到自研系统 ⚫ Proxy：协议解析，文件切片和合并，限流等，无状态节点 ⚫ Objectmanager：对象管理，生命周期、垃圾数据清理 ⚫ Store：单机存储引擎，追加聚合成大文件存储，数据冗余持久存储，后台任务执行 ⚫ Storemaster：节点管理、全局负载均衡、后台任务调度等 ⚫ MetaDB：类LSM的数据库

7.

8. 面临的挑战 ⚫ MetaDB为瓶颈：每日写入量、扫描流量、事务冲突 ⚫ 业务之间相互干扰严重，爆炸半径过大 ⚫ 对象管理和存储管理单点成为瓶颈 ⚫ Proxy缓存效率低 ⚫ 垃圾数据的GC效率低、成本高 ⚫ 异构存储硬件的管理复杂度高

9. 对象处理单元分组 ⚫ 对象元数据与存储元数据分离 ⚫ 每个对象分组有独立的proxy、 objecmanager和metadb ⚫ 每个对象分组共享底层存储 ⚫ 每个分组承担若干租户/桶的请求

10. 数据存储单元分组 ⚫ 数据存储划分多个独立的单元 ⚫ 每个单元有独立的store、storemaster 和metadb ⚫ 每个单元存储若干个租户/bucket的数据 ⚫ 一个单元内的机器硬件保持统一 ⚫ 数据的冗余副本不能跨单元分组 ⚫ 支持存储单元分组故障降级

11. 流量控制的背景 ⚫ 业务诉求：吞吐承诺，流量不能过高 ⚫ 业务趋势：内网流量超千万GB/天，避免突发流量的影响流量控制面临的挑战 ⚫ 请求大小差异：文件大小差异大，HTTP Range ⚫ 客户端影响：流式传输，收发包快慢 ⚫ 连接不均匀：网关转发策略、慢节点等 ⚫ 性能开销：不能影响吞吐和时延常见方法的问题 ⚫ 基于中心统计节点的精确限流：统计节点为瓶颈、流量倾斜、连接饥饿 ⚫ 基于平均分布的单机限流：误差大

12. 解决思路 ⚫ 低并发场景基于中心统计方式实现流量 token分配 ⚫ 高并发场景下按节点平均分配流量 token，并且要有机制校正误差具体做法 ⚫ 限流周期：秒级，轮换中心限流节点 ⚫ 中心限流节点统计：连接数+已使用token数 ⚫ 限流粒度：proxy按照bucket级别预取限流token ⚫ 连接倾斜和饥饿：基于上一个限流周期的连接数校正，并控制校正幅度

13.

14. 基本存储模型 ⚫ 对象切片：proxy将对象切割成不超过2MB的record ⚫ 追加存储：不同的record追加到partition实现冗余存储 ⚫ 对象读取：proxy拼接多个record返回给client ⚫ Partition冻结：写满256MB后冻结持久化索引和CRC checksum ⚫ Partition GC：record标删，多个partition合并来实现清理垃圾数据 ⚫ 后台EC：多个partition实现后台转EC

15. 数据持久性需要解决的问题 ⚫ 不能给client返回错误的数据 ⚫ 尽快发现错误的数据，并利用冗余机制进行修复 ⚫ 防止错误数据扩散 ⚫ 确保持久存储的数据与client一致不返回错误的数据：record CRC 校验 ⚫ 对象文件大小范围大 ⚫ 保证http首包延迟 ⚫ http range请求

16. 尽快发现错误数据 ⚫ 温热数据：读取record时校验 ⚫ 冷数据：周期性chunk crc校验周期性chunkCRC校验 ⚫ 巡检周期控制在半个月以内 ⚫ 每个硬盘挑选一个chunk组成一个集合 ⚫ 条带式增量计算chunk crc减轻硬盘的压力 ⚫ 低峰期执行，减轻对前台IO的影响 ⚫ 隔离问题chunk并修复

17. 防止错误数据扩散 ⚫ 副本恢复/迁移：chunk级crc校验 ⚫ GC: 写入时流式计算record crc校验 ⚫ EC：基于record CRC进行数据源和目标文件校验 GC流程举例： ⚫ 3个副本挑选1个chunk副本获取有效record ⚫ 计算节点聚合多个chunk的有效record ⚫ 目标存储节点写入时流式校验record CRC和 index完整性

18. 全链路CRC校验 ⚫ Record的多副本写入：落盘前CRC校验 ⚫ Proxy：流式计算切片CRC，持久化并响应

19.

20. MetaDB的特点过往运营的痛点 ⚫ 类LSM架构，仅支持L1，提供SQL接口 ⚫ 写入有瓶颈，难以满足业务需求 ⚫ 增量数据采用主从多数派实现，并支持事务 ⚫ 大量tombstone记录导致scan消耗过多资源，容易 ⚫ L1 SST 数据支持多副本存储，可以隔离不同操作请求流量 ⚫ 不支持墓碑检测和优化超时并且影响其他非scan操作 ⚫ 业务存在大量的元数据扫描，影响元数据稳定性 ⚫ 事务冲突，消耗资源，影响访问稳定性 ⚫ 慢请求会耗尽客户端的SQL连接池

21. 缓解方法 ⚫ LSM的tombstone问题：检测并管控list object ⚫ 元数据扫描：隔离后台扫描流量 ⚫ 事务冲突：冲突检测和控制 ⚫ 连接池：list object单独一个连接池元数据架构替换的关键3个问题 ⚫ LSM的扫描和墓碑问题 ⚫ KV是否就能满足对象的场景需求（扩展性） ⚫ 是否需要分布式事务，将元数据从数据库迁移到KV

22. RootServer ⚫ 收集Range以及相关监控信息 ⚫ 维护Range路由 ⚫ 进行全局调度 KVServer ⚫ KV操作接口，包含原子和批量操作 ⚫ 引擎具体实现，包含只有L1的LSM，支持墓碑感知compaction以及Range分裂等 ⚫ SST文件持久化共享存储，支持隔离扫描流量 ⚫ 流控和缓存实现

23. 元数据模型 ⚫ Object表：每一个记录代表一个对象 ⚫ ObjectInfo表：对象的类型和切片信息 ⚫ Multipart表：每个记录代表一个分片 ⚫ MultipartUpload表：代表一个分片上传请求 ⚫ Deleteobject表：代表一个标删对象

24. 关键设计 ⚫ 对象存储中Object的扩展性是关键 ⚫ 分区规则：Object名字 ⚫ 同一个Object的其他关联记录存储到一个节点中 ⚫ 不同表之间的数据要分离

25. 关键设计 ⚫ 引入CF概念，每张表对应1个CF ⚫ 以bucketID+object名字实现Range分区，计算不同CF的边界 ⚫ 每个CF对应1个存储引擎

26. 1 2 3 4 KV支持隔离扫描流量，基于宏块减少写放大实现bucke级别的数据调度策略，降低GC成本提供更细粒度的分级存储方案优化目录操作性能，满足更多业务场景需求

27.

28. 大模型正在重新定义软件 Large Language Model Is Redefining The Software