对象存储上做随机读听起来是个很普通的需求但在真实工程里它常常把架构逼到墙角。HTTP 协议里那个不起眼的Range头很多人只在下载续传时用过可一旦业务变成“在大文件上频繁读取局部字节”Range的语义、缓存粒度、回源策略就全部变成了核心问题。这篇文章讨论的正是我最近完成的一个 byte-range cache字节范围缓存设计。它不是把整个对象读进内存再截取而是以字节块为粒度按需缓存让对象存储上的随机读变得可控。我会从问题背景、缓存原理、关键决策、最小实现代码、验证方法到生产落地的坑完整讲清楚。如果你正在处理这些场景中的任何一种视频抽帧转码、AI 数据集加载、容器镜像并发拉取、大数据 Parquet/ORC 文件分析、大文件断点续传那么这篇文章应该能帮你省掉很多自己摸索的时间。1. 在对象存储上做随机读到底难在哪1.1 对象存储的读写模型与文件系统完全不同很多团队第一次接触对象存储时会下意识把它当成文件系统来用。这是最深的误解。文件系统提供的是 POSIX 语义你可以open、lseek、pread内核帮你管理页缓存、目录项缓存随机读是文件系统的原生能力。对象存储不是这样。它的对外接口是 HTTP核心操作是PUT object、GET object、DELETE object并没有“打开文件偏移量”这种概念。在对象存储上做读取时你只有两种选择GET整个对象一次性把完整数据拉回来GET时带Range头告诉服务端只返回指定字节区间。第二种方式在语义上已经接近“随机读”了。但问题在于对象存储不负责缓存每次Range请求都是一次完整的网络往返。如果业务会反复读取同一个文件的不同区间而每次都直接回源延迟、带宽、甚至对象存储侧的请求计费都会被拉高。从本质上讲对象存储把原本属于操作系统的“页缓存”职责交给了上层应用自己处理。而大部分应用没有处理这个问题的能力。1.2 典型场景视频、容器镜像、AI 数据集哪些业务最容易踩中这个坑我梳理了三类典型场景。第一类是视频处理。转码服务常常需要读取视频文件的头部、moov box、关键帧区间文件可能是几个 GB但每次处理只读几十 MB。比如在视频加载首帧时所需数据往往集中在文件开头几 MB而 MP4 文件的 metadata 可能在文件末尾。不做缓存时这些请求会反复打向对象存储。第二类是容器镜像拉取。OCI 镜像本身是分层打包的每一层又可以继续按 tar 块拆成多个范围并发拉取。像 Docker、Podman、Harbor、containerd 这类运行时和仓库在传输层都实现了大文件分块并发读取。镜像层一旦被多个节点同时拉取缓存的收益会非常明显。第三类是 AI 和大数据。训练任务会反复读取图像数据集、embedding 文件、Parquet 列式文件。Parquet 这类列式存储天然就是“大文件 列区间读取”的模式读某一列时只需要文件里对应的 row group 和 column chunk。数据量大、重复读、读区间固定这三条合在一起是 byte-range cache 最理想的适用场景。还有一个容易被忽视的场景是断点续传和并发下载。下载器通常用多个线程分别请求bytes0-1048575、bytes1048576-2097151这样的区间。如果产物要反复发布、反复被拉取同一个对象的相同区间会在不同时间被不同客户端请求。命中缓存后既能降低回源压力也能明显改善下载耗时。1.3 没有缓存时会发生什么没有缓存时Range请求的行为非常直接来一个请求回一次源。表面上看延迟也可接受但实际压力会被叠加放大。假设一个 AI 训练集群有 100 个 worker同时读取同一个 10GB 的数据集文件。每个 worker 只读取其中 200MB 特征区间但它们发起的区间高度重叠。如果没有缓存对象存储在这段时间内要处理 100 次重复的 200MB 请求总流量达到 20GB而数据本身只有 200MB 是真正有价值的。这就是典型的读放大问题。读放大的本质不是网络带宽不够而是重复数据反复在网络和存储层之间搬运。更麻烦的是对象存储通常会按照请求次数和数据出流量双重计费。对于大规模业务来说这种重复读取不只是性能问题更是成本问题。2. byte-range cache 的原理2.1 Range 请求的对象存储语义先明确Range请求的基本流程。客户端发送GET /bucket/large-file.bin HTTP/1.1 Host: storage.example.com Range: bytes1048576-2097151服务端如果支持会返回状态码206 Partial Content响应头中带有Content-Range: bytes 1048576-2097151/10737418240表示这次返回的是对象的一部分。这里有一个容易踩的细节服务端并不保证一定返回 206。如果对象存储不支持 Range或者处理逻辑有问题可能直接返回 200 和完整对象。所以在客户端实现里一定要对 206 和 200 两种响应都做处理否则解析范围时出错会导致数据错位。2.2 缓存粒度整对象、分块与字节范围既然要缓存第一个问题就是“以什么粒度缓存”。主要有三种选择。维度整对象缓存分块缓存block按请求范围缓存缓存最小单位一个完整对象固定大小的块每次请求的实际范围冷读大文件必须全量拉取按需拉块按需拉取内存占用取决于对象大小可控固定块数不可控碎片多随机读命中率低中高视范围重叠程度实现复杂度简单中等简单但难管理整对象缓存的逻辑最简单第一次访问时把整个文件拉下来放内存或本地磁盘后续读全部走本地。但它有一个致命问题当对象是 GB 级甚至 TB 级时缓存一个完整对象会瞬间打满内存缓存几个对象之后系统就不可用了。按请求范围缓存看似灵活实际工程里会导致缓存块大小不一替换策略难以设计内存碎片严重。最终我选择的方案是分块缓存把对象的字节空间按固定大小切成 block以 block 为最小单位做缓存。2.3 从缓存角度重新看 Rangebyte-range cache 的核心思路并不复杂一次Range请求可能覆盖几个 block缓存层先检查哪些 block 已经在缓存里哪些需要回源。回源时按 block 对齐到对象存储拉回的数据以 block 为单位写进缓存。假设block_size 4MB客户端请求bytes5MB-13MB。这个范围覆盖了 block 14MB-7MB、block 28MB-11MB、block 312MB-15MB的一部分。缓存层会按 block 查询缺失的就向上游对象存储发一次对应块的 Range 请求最终把三个 block 的数据合并返回给客户端。这种设计的优势在于下次无论请求哪个区间只要它落在已经缓存的 block 内就能直接命中。命中粒度从“整文件”缩小到了“4MB 的块”大幅提高了小范围随机读的复用率。把对象看成字节序列把缓存看成若干“热区”的集合byte-range cache 就是给对象存储加了一层自定义页缓存。3. 缓存设计中的核心决策点一个 byte-range cache 能不能真正好用主要看四个决策做得好不好分块大小、替换策略、一致性处理、预取。3.1 分块大小怎么定分块大小是最影响性能的参数。它实际上是在三种成本之间做权衡。分块太小比如 64KB会导致两个问题一是元数据开销变大每个块都要记录 key、起始位置、访问次数块数量过多时连查找本身的成本都会上升二是每命中一个逻辑区间要发起更多次块查询。分块太大比如 64MB则会让命中率下降。随机读一个 128KB 的特征区间却要回源 64MB带宽浪费严重。分块越大缓存浪费率越高。从工程实践看1MB 到 16MB 是常见区间。对象存储的多部分上传最小分片一般是 5MB因此 4MB 或 8MB 的 block 在对齐底层数据时比较自然。如果业务以顺序读为主可以适当放大如果以随机小读为主则应该缩小。一个实际可用的思路是先根据读请求的区间大小分布做一次统计取 P50 区间大小的 2 到 4 倍作为 block_size。这比拍脑袋定数字靠谱得多。3.2 替换策略LRU、LFU 还是两段式缓存空间是有限的当缓存写满时必须决定淘汰哪些 block。最常用的是 LRU最近最少使用的 block 被优先淘汰。LRU 实现简单适合大多数场景。但它有一个弱点一次性读取的冷数据容易把热数据挤出去。比如批量任务顺序读了一个大文件很多 block 永远不会再读却会把热 block 全部挤出缓存。LFU 按访问频率淘汰对于“少量 block 被高频访问”的场景更友好但实现需要记录频率而且存在“旧热数据不衰减”的问题。我在实际实现中选择了“LRU 为主 分代保护”的简化策略刚拉回的 block 进入年轻代只有被再次访问的 block 才晋升为热数据淘汰时优先淘汰年轻代中的冷数据。这样能避免顺序扫描对缓存的污染。3.3 一致性对象被覆盖了怎么办对象存储上的对象并不是一成不变的。业务可能重新上传同名对象也可能删除旧对象。如果缓存不感知对象版本变化就会返回旧数据。这在文件系统里对应“脏页未刷新”问题但在对象存储场景下解决思路不同因为对象存储往往强调不可变性或者通过版本 ID、ETag 来区分对象。稳妥的做法是在缓存项里记录对象的 ETag 或 Last-Modified。每次命中时如果做了强一致校验则与对象存储确认元数据如果不希望每次命中都校验可以设置一个 TTL在 TTL 内信任缓存超过 TTL 再校验。对于大多数读多写少的业务TTL 校验是成本与一致性之间更平衡的选择。3.4 要不要预取预取read-ahead是指在读取某个 block 时顺手把相邻的 block 也拉回缓存。对于顺序读场景预取能显著减少后续请求的等待时间。但预取不适合所有场景。如果业务是纯随机读预取拉回来的 block 大概率永远不会被用上反而占用缓存空间、增加回源量。折中的办法是第一次读取时不做预取当同一个对象在短时间内连续读取了当前块之后的相邻块例如连续命中两次顺序块就触发一次预取。这种“自适应预取”比固定预取更稳。4. 一个最小可运行的 byte-range cache 实现下面我们用 Python 实现一个最小可用的 byte-range cache。代码结构清晰核心逻辑可以直接迁移到其他语言比如 Go、Java、Rust。4.1 整体结构整个系统分为三层缓存管理器负责 block 的存储、查找、淘汰读取器负责拆分 Range 请求、合并缓存与回源逻辑HTTP 接口接收客户端的 Range 请求返回 206 响应。实际生产环境里对象存储可以是 S3、OSS、MinIO或者任何支持Range请求的 HTTP 服务。这里我们用requests模拟回源客户端。4.2 缓存管理器实现缓存管理器使用 Python 的OrderedDict实现 LRU。key 由对象名和 block 索引组成value 里保存该 block 的实际数据。# byte_range_cache.py import threading import time from collections import OrderedDict class ByteRangeCache: 以固定大小 block 为粒度的 LRU 缓存 def __init__(self, block_size4 * 1024 * 1024, max_blocks256): self.block_size block_size self.max_blocks max_blocks self._entries OrderedDict() self._lock threading.Lock() def _make_key(self, object_key: str, block_index: int): return (object_key, block_index) def get(self, object_key: str, start: int, end: int): 尝试在缓存中查找完全覆盖 [start, end] 区间的 block。 命中时返回数据未命中返回 None。 if end - start 1 self.block_size: return None block_index start // self.block_size key self._make_key(object_key, block_index) with self._lock: entry self._entries.get(key) if entry is None: return None if entry[start] ! start or entry[end] ! end: return None self._entries.move_to_end(key) return entry[data] def put(self, object_key: str, start: int, end: int, data: bytes): 写入一个 block并执行 LRU 淘汰 block_index start // self.block_size key self._make_key(object_key, block_index) with self._lock: if key not in self._entries: self._entries[key] { start: start, end: end, data: data, last_access: time.time(), } else: entry self._entries[key] entry[start] start entry[end] end entry[data] data entry[last_access] time.time() self._entries.move_to_end(key) while len(self._entries) self.max_blocks: self._entries.popitem(lastFalse) def size(self) - int: return len(self._entries)这段代码的关键点是get只处理“完全覆盖请求范围”的 block这样返回值就是客户端要的完整数据不需要截取put写入时使用move_to_end维护 LRU 顺序淘汰时从头部弹出因为OrderedDict的头部是最久未访问的数据。4.3 读取器与回源逻辑读取器的职责是把一个任意Range请求拆解成 block 列表优先查缓存未命中的 block 回源并写入缓存。# reader.py import requests class ObjectStorageHttpClient: 一个极简的对象存储 Range 读取客户端 def __init__(self, base_url: str): self.base_url base_url.rstrip(/) def read_range(self, object_key: str, start: int, end: int) - bytes: url f{self.base_url}/{object_key.lstrip(/)} headers {Range: fbytes{start}-{end}} resp requests.get(url, headersheaders, timeout30) if resp.status_code 206: return resp.content if resp.status_code 200: # 上游不支持 Range 时回退为整文件后截取 data resp.content return data[start:end 1] resp.raise_for_status() class ByteRangeReader: 按块读取优先走缓存 def __init__(self, cache, storage): self.cache cache self.storage storage def read(self, object_key: str, start: int, end: int) - bytes: result bytearray() cursor start block_size self.cache.block_size while cursor end: block_index cursor // block_size block_start block_index * block_size block_end min(block_start block_size - 1, end) # 1. 先查缓存 data self.cache.get(object_key, block_start, block_end) if data is None: # 2. 未命中则回源并写入缓存 data self.storage.read_range(object_key, block_start, block_end) self.cache.put(object_key, block_start, block_end, data) result.extend(data) cursor block_end 1 return bytes(result)这里需要注意回源读取时对齐到了 block 边界而不是原始请求的边界。也就是说即使客户端只需要5MB-6MB如果block_size 4MB实际回源范围是4MB-7MB或8MB-11MB中的一个。这部分多读的数据就是缓存预热的代价也是块大小不能过大的原因。4.4 接入 HTTP 服务最后提供一个最小 HTTP 服务用 Flask 实现。它解析Range头调用读取器然后返回206 Partial Content。# server.py from flask import Flask, Response, request from byte_range_cache import ByteRangeCache from reader import ByteRangeReader, ObjectStorageHttpClient app Flask(__name__) # 4MB 分块最多缓存 256 个 block约 1GB 内存上限 cache ByteRangeCache(block_size4 * 1024 * 1024, max_blocks256) storage ObjectStorageHttpClient(http://127.0.0.1:9000) reader ByteRangeReader(cache, storage) app.route(/path:object_key) def read_object(object_key): range_header request.headers.get(Range, ) if not range_header.startswith(bytes): return Response(Please use Range header, status400) try: range_spec range_header[len(bytes):] start_str, end_str range_spec.split(-, 1) start int(start_str) # 未指定结束位置时默认读一个 block 的数据 end int(end_str) if end_str else start cache.block_size - 1 except (ValueError, AttributeError): return Response(Invalid Range header, status400) data reader.read(object_key, start, end) resp Response(data, status206) resp.headers[Content-Range] fbytes {start}-{start len(data) - 1}/* resp.headers[X-Cache] block-cache return resp if __name__ __main__: app.run(host0.0.0.0, port8080)三个文件的依赖关系很清晰server.py只处理 HTTP 协议reader.py负责缓存与回源策略byte_range_cache.py只负责存储和淘汰。实际生产代码里我会把存储客户端替换成 boto3并把ObjectStorageHttpClient的上游地址换成真实对象存储 endpoint代码结构不需要变。4.5 如何运行与验证假设你用 MinIO 在本地模拟了一个对象存储。先创建 bucket 并上传一个测试文件# 启动 MinIO假设 endpoint 为 http://127.0.0.1:9000 # 创建 bucket 并上传一个 100MB 的测试文件 mc alias set local http://127.0.0.1:9000 minioadmin minioadmin mc mb local/test-bucket dd if/dev/urandom of/tmp/test.bin bs1M count100 mc cp /tmp/test.bin local/test-bucket/test.bin然后启动我们实现的缓存服务pip install flask requests python server.py第一次读取一个范围输出日志里会包含回源请求再次读取相同或重叠范围就不会有新的回源请求。curl -H Range: bytes1048576-2097151 \ http://127.0.0.1:8080/test-bucket/test.bin \ -o /tmp/part1.bin -v对比同一请求第二次执行时的耗时正常情况下第二次会明显更快因为数据已经缓存在本地内存里。5. 命中率与效果评估方法做完最小实现后最怕的问题就是“感觉有缓存但不知道有没有用”。所以需要有明确的评估指标。5.1 命中率怎么看byte-range cache 最核心的指标是块命中率计算公式是命中率 命中的 block 数 / 总请求的 block 数在代码里可以加两个计数器cache_hits和cache_misses。每处理一个 block命中则加一未命中则加一。然后通过一个监控接口或者日志输出class ByteRangeCacheStats: def __init__(self): self.hits 0 self.misses 0 def hit_rate(self): total self.hits self.misses return self.hits / total if total else 0命中率是结果指标但不同场景的合理命中率差别很大。比如视频抽帧任务如果反复读同一个文件的头部命中率可以到 90% 以上AI 数据集如果每个 epoch 都随机打乱后读同一批文件命中率取决于 block 是否能被复用通常也能达到 60% 到 80%如果业务是大文件全量顺序扫一遍后不再访问缓存再大也没用命中率趋近于 0。这种情况应该考虑关闭缓存避免白占内存。5.2 延迟和带宽评估除了命中率还要看两个业务指标平均读延迟和对象存储回源流量。平均读延迟 命中请求延迟 × 命中率 未命中请求延迟 × (1 - 命中率)如果命中请求延迟是 1ms未命中请求延迟是 50ms命中率 80%平均延迟就是 10.8ms相比无缓存时的 50ms降低约 80%。回源流量可以通过对象存储侧的日志或计费账单来观察。对比接入缓存前后同一时间窗口的出流量就能估算缓存带来的成本收益。5.3 压测时不要踩的坑压测时常见的错误是只用固定区间反复压。这样测出来的命中率是 100%因为 block 完全固定没有任何参考价值。更合理的做法是构造一个模拟真实访问的 trace包含不同对象的访问序列、区间偏移、区间长度。把 trace 重放到缓存服务上统计命中率。这比盲目用 ab 压测更有意义。如果暂时没有现成 trace也可以先用“Zipf 分布”生成区间少量 block 被大量访问大量 block 只被访问一两次。这种分布最接近真实内容型业务的读取模式。6. 常见问题与排查思路问题现象可能原因排查方式解决方案缓存始终不命中block 对齐方式不一致打印请求 start 和缓存 key对比偏移统一按start // block_size计算索引返回数据错位上游对象被覆盖缓存未失效抓包对比缓存数据和对象元数据 ETag记录 ETag对象版本变化时清理缓存内存持续上涨max_blocks 设置过大或淘汰失效监控缓存 size 和淘汰次数调小 max_blocks检查是否频繁写入 key并发回源导致上游压力大多个请求同时访问同一缺失 block看上游访问日志是否存在相同 Range对 block 回源做 singleflight合并并发请求命中率高但延迟仍高block 命中后数据拼接耗时过长profile 定位瓶颈使用零拷贝、减少 bytearray 复制小范围读导致带宽浪费block_size 过大统计请求区间长度分布调小 block_size第三行里的“对象被覆盖”是最隐蔽的问题。对象存储允许同名覆盖如果业务没有使用版本管理缓存里可能残留旧对象数据。解决思路是写入接口如果有更新操作同步触发对应对象的缓存清理或者每次命中时按一定概率校验 ETag。7. 生产环境落地建议7.1 缓存应该放在哪里byte-range cache 的位置决定了它的收益上限。最简单的部署方式是放在对象存储前面作为反向代理网关类似一个轻量的读缓存层。但更常见的是放在计算侧比如训练节点的本地磁盘或内存里这样能避免所有读请求都经过集中网关减少单点压力。如果缓存是分布式部署还需要考虑一致性哈希让同一对象的同一 block 尽量落在同一节点。不过对于大部分中小团队来说单机内存缓存已经能解决 70% 以上的读放大问题不必一开始就上分布式缓存。7.2 并发回源一定要抑制缓存系统中一个经典问题是缓存击穿某个 block 刚好过期或刚被淘汰大量请求同时发现未命中同时回源直接把上游打挂。解决方式叫 singleflight。核心思想是同一个 block 在同一时刻只允许一个请求回源其他请求等待该请求的结果。import threading from collections import defaultdict from concurrent.futures import Future class SingleFlight: def __init__(self): self._inflight defaultdict(list) self._lock threading.Lock() def get_or_execute(self, key, func): with self._lock: if key in self._inflight: future Future() self._inflight[key].append(future) else: future Future() self._inflight[key].append(future) self._execute(key, func) return future.result() def _execute(self, key, func): try: result func() with self._lock: futures self._inflight.pop(key, []) for f in futures: f.set_result(result) except Exception as exc: with self._lock: futures self._inflight.pop(key, []) for f in futures: f.set_exception(exc)实际生产中库如cachetools、golang.org/x/sync/singleflight都有现成实现不需要自己造轮子但原理是一样的。7.3 内存不够时怎么办纯内存缓存速度最快但是成本高、容量有限。当数据量超过内存容量时可以考虑两级缓存内存缓存负责热 block磁盘缓存负责温 block。磁盘缓存实现也不复杂把 block 数据写到本地文件内存里只保存 block 元数据和文件偏移。命中时从文件读取。SSD 的随机读性能足够支撑这个场景。如果连本地磁盘都不够用可以退化成只缓存索引和元数据不再缓存数据本身至少能为缓存命中判断节省一次上游请求。7.4 安全与鉴权不能绕过给对象存储加缓存层时很容易把鉴权也绕过去。如果缓存服务直接暴露在公网任何知道 URL 的人都能读取被缓存的数据。这是非常危险的设计。生产环境里缓存层必须复用对象存储的鉴权逻辑。要么在缓存层做同样的签名校验要么把缓存服务放在内网、只允许可信服务访问。不要因为“只是加个缓存”就省略权限控制。7.5 监控是长期演进的基础至少要监控这些指标块命中率缓存大小和淘汰数回源请求数、回源流量平均读延迟和 P99 延迟上游失败次数和重试率。这些指标可以帮助判断 block_size 是否合理、缓存空间是否足够、是否需要对特定对象做白名单缓存。没有监控的缓存系统很快就会变成“黑盒加速器”出了问题根本定位不到原因。8. 总结与后续方向byte-range cache 本质上是在对象存储和业务之间增加了一层字节级的页缓存。它解决的问题不是“缓存”本身而是对象存储作为 HTTP 服务在随机读场景下的读放大问题。这篇文章里我把设计的关键决策拆成了四个点分块大小、替换策略、一致性、预取。从一个最小 Python 实现出发写清楚了 Range 请求如何按 block 拆分、缓存如何命中、回源如何合并。最后讨论了生产环境中几个容易被忽视的工程问题并发回源、内存与磁盘的权衡、鉴权、监控。下一步如果你想继续深入有三个方向值得尝试把实现迁移到 Go 或 Java用零拷贝和并发回源把吞吐做到更高接入 Prometheus 指标让命中率和回源量变成可观测的线上数据把单机缓存改成分布式缓存使用一致性哈希做节点间数据路由。如果你的业务刚好在视频处理、AI 训练、容器镜像分发这类场景里被对象存储的读放大困扰可以先从本文的最小实现开始把命中率指标做出来再逐步调整 block_size 和预取策略。缓存的价值不是“看着加了缓存”而是把重复读真正挡在对象存储之前。