缓存 · XB 现场笔记

dnsmasq 区分转发缓存与本地配置名称

Sat, 15 Apr 2028 00:00:00 +0000

dnsmasq 可以向上游转发 DNS 查询，在有界缓存中保留支持的回答，也可以提供本地配置的名称。这些是不同的数据来源。重复得到相同回答，可能来自缓存命中，也可能来自本地配置。主机名与权威数据不一致、或者清缓存后仍然解析到原地址时，先确认来源十分重要；否则容易把有效配置误认为没有清干净的缓存。

坏掉的样子

启动 dnsmasq，不会自动让所有应用使用它。客户端必须把 DNS 查询交给预期监听，有的应用还会使用其他解析服务。同样，本地监听正常，也可能转发到错误上游或者读取了意外 hosts 配置。在增加缓存容量或重启服务前，应先确认真实查询路径。如果失败查询根本没到达这个进程，对它反复操作不会改变调用方看到的结果。

本地名称可以有意覆盖上游数据。清理转发缓存不会删除这个配置名称，因此反复清空也不能让上游地址获胜。应把本地记录当作有负责人、有用途的配置管理。即使回答的本地 TTL 为零，dnsmasq 仍可持续返回该值，因为它来自配置生成，不是靠保留某份转发回答维持。零 TTL 与删除本地配置并不是同一件事。

缓存容量和新鲜度解决不同问题。更大缓存可以保留更多合适条目，却不会延长条目的有效 TTL，也不会让上游故障期间所有名称都能查询成功。新名称与过期条目仍需要合适的解析路径。缓存大小也不直接代表可同时发送多少上游查询，更不能单独保证应用可用。应分别观察容量、寿命、并发与上游健康，而不是用一个参数代替所有约束。

快速验证

将脚本保存为 check-dnsmasq.py，准备 Docker 后执行 python3 check-dnsmasq.py。固定环境使用 dnsmasq 2.90 和 BIND 9.18.49。实验转发器忽略环境中的 resolv 和 hosts 文件，明确绑定回环监听，并只转发到自己的临时权威服务器。它不发布宿主端口，没有 DHCP 配置，结束后清理自己的实例，不影响现有服务：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid
recipe='FROM python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84\nRUN apt-get update && apt-get install -y --no-install-recommends bind9=1:9.18.49-1~deb12u2 bind9-dnsutils=1:9.18.49-1~deb12u2 dnsmasq-base=2.90-4~deb12u2 python3-dnspython=2.3.0-1 && rm -rf /var/lib/apt/lists/*\nCMD ["/usr/bin/python3"]\n'
program=r"""
from contextlib import ExitStack,contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import json,re,signal,subprocess,time
import dns.exception,dns.message,dns.query,dns.rcode,dns.rdatatype

def run(*args,check=True):
 result=subprocess.run(args,capture_output=True,text=True,timeout=15)
 if check:assert result.returncode==0,(args,result.returncode,result.stdout,result.stderr)
 return result
def query(name,kind='A',port=1053):
 return dns.query.udp(dns.message.make_query(name,kind),'127.0.0.1',port=port,timeout=1)
def values(response,kind='A'):
 wanted=dns.rdatatype.from_text(kind)
 return [item.to_text() for rrset in response.answer if rrset.rdtype==wanted for item in rrset]
def show(response):
 def section(records):return [{'name':str(rr.name),'type':dns.rdatatype.to_text(rr.rdtype),'ttl':rr.ttl,'data':[item.to_text() for item in rr]} for rr in records]
 return {'rcode':dns.rcode.to_text(response.rcode()),'answer':section(response.answer),'authority':section(response.authority)}
def wait(predicate,timeout=15):
 deadline=time.monotonic()+timeout
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except (OSError,dns.exception.Timeout):pass
 time.sleep(.05)
 raise AssertionError('DNS fixture condition did not become true')
def stop(process):
 if process.poll() is None:
 process.terminate()
 try:process.wait(timeout=5)
 except subprocess.TimeoutExpired:process.kill();process.wait(timeout=5)

@contextmanager
def lab(records,soa_ttl=8,minimum=4,extra=''):
 with TemporaryDirectory(prefix='xbcatm-dns-') as directory,ExitStack() as stack:
 root=Path(directory);zone=root/'zone';conf=root/'named.conf';log=root/'named.log';serial=1
 def save(body):
 zone.write_text(f'$ORIGIN lab.test.\n$TTL 30\n@ {soa_ttl} IN SOA ns.lab.test. hostmaster.lab.test. ({serial} 60 60 3600 {minimum})\n@ IN NS ns.lab.test.\nns IN A 127.0.0.1\n'+body+'\n')
 run('named-checkzone','lab.test',str(zone))
 save(records)
 conf.write_text(f'''options {{ directory "{root}"; listen-on port 1053 {{127.0.0.1;}}; listen-on-v6 {{none;}};
recursion no; dnssec-validation no; notify no; querylog yes; max-cache-size 8m; pid-file "{root}/named.pid"; session-keyfile none;
{extra} }};
controls {{}};
zone "lab.test" {{ type primary; file "{zone}"; }};
''')
 run('named-checkconf',str(conf))
 output=stack.enter_context(log.open('w'))
 authority=subprocess.Popen(['named','-g','-c',str(conf),'-n','1','-U','1'],stdout=output,stderr=subprocess.STDOUT)
 stack.callback(stop,authority)
 def ready():
 assert authority.poll() is None,log.read_text()
 response=query('lab.test.','SOA');return response.rcode()==0 and response.answer[0][0].serial==serial
 wait(ready)
 def update(body):
 nonlocal serial
 serial+=1;save(body);authority.send_signal(signal.SIGHUP);wait(ready)
 def cache(port=1054,upstream=1053,size=150,options=()):
 logfile=root/('cache-'+str(port)+'.log');stream=stack.enter_context(logfile.open('w'))
 command=['dnsmasq','--no-daemon','--conf-file=/dev/null','--no-resolv','--no-hosts','--bind-interfaces',
 '--listen-address=127.0.0.1','--port='+str(port),'--server=127.0.0.1#'+str(upstream),
 '--cache-size='+str(size),'--log-queries','--log-facility=-',*options]
 process=subprocess.Popen(command,stdout=stream,stderr=subprocess.STDOUT);stack.callback(stop,process)
 def cache_ready():
 assert process.poll() is None,logfile.read_text()
 return query('lab.test.','SOA',port).rcode()==0
 wait(cache_ready);return process,logfile
 def queries(name,kind='A'):
 return sum(bool(re.search(r'query: '+re.escape(name.rstrip('.'))+r' IN '+kind+r'\b',line)) for line in log.read_text().splitlines())
 yield root,update,cache,queries
with lab('cached 20 IN A 127.0.0.2\nuncached 20 IN A 127.0.0.3\nlocal 20 IN A 127.0.0.4') as (_,update,cache,queries):
 daemon,log=cache(options=('--host-record=local.lab.test,127.0.0.9',))
 for _ in range(3):assert values(query('cached.lab.test.',port=1054))==['127.0.0.2']
 wait(lambda: queries('cached.lab.test')==1)
 cache(port=1055,size=0)
 for _ in range(3):assert values(query('uncached.lab.test.',port=1055))==['127.0.0.3']
 wait(lambda: queries('uncached.lab.test')==3)
 local=query('local.lab.test.',port=1054);assert values(local)==['127.0.0.9'] and local.answer[0].ttl==0
 assert queries('local.lab.test')==0
 authoritative=query('local.lab.test.');assert values(authoritative)==['127.0.0.4']
 wait(lambda: queries('local.lab.test')==1)
 update('cached 20 IN A 127.0.0.8\nuncached 20 IN A 127.0.0.3\nlocal 20 IN A 127.0.0.4')
 stale=query('cached.lab.test.',port=1054);assert values(stale)==['127.0.0.2'] and queries('cached.lab.test')==1
 previous=log.read_text().count('cleared cache');daemon.send_signal(signal.SIGHUP)
 wait(lambda: log.read_text().count('cleared cache')>previous)
 refreshed=query('cached.lab.test.',port=1054);assert values(refreshed)==['127.0.0.8']
 wait(lambda: queries('cached.lab.test')==2)
 retained=query('local.lab.test.',port=1054);assert values(retained)==['127.0.0.9']
 print(json.dumps({'three_lookups_upstream_counts':{'cache_enabled':1,'cache_disabled':3},'local_record':show(local),
 'same_name_authority':show(authoritative),'before_SIGHUP':show(stale),'after_SIGHUP':show(refreshed),
 'configured_local_record_retained':show(retained)},sort_keys=True))
"""
name='xbcatm-dns-'+uuid.uuid4().hex[:10]
def docker(*args,**kwargs):return subprocess.run(['docker',*args],capture_output=True,text=True,timeout=300,**kwargs)
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'Dockerfile').write_text(recipe)
 built=docker('build','-t',name,str(root));assert built.returncode==0,built.stderr
 result=docker('run','--rm','-i','--name',name,'--network','none','--memory','384m','--pids-limit','128',name,
 '/usr/bin/python3','-',input=program)
 assert result.returncode==0,result.stderr
 print(json.dumps(json.loads(result.stdout),sort_keys=True))
finally:
 docker('rm','-f',name);docker('image','rm',name)

通过启用缓存的监听查询 cached.lab.test 三次，都返回 127.0.0.2，权威日志却只记录一次。第二个监听使用 cache-size=0，经它对另一个名称查询三次，就产生三次上游请求。这个对照直接验证缓存对转发工作量的影响，不用响应速度猜测是否命中，也不声称测得某个固定延迟改善。回环网络的快慢本身不足以证明数据来源。

第一个监听另有 host-record=local.lab.test,127.0.0.9。查询得到 127.0.0.9，TTL 为零，权威没有记录对应上游查询。直接向权威查询同名则得到 127.0.0.4，计数随之增加。这说明差异来自明确的本地覆盖；后一个正向对照也验证了计数器确实能记录上游流量，避免把始终为零的错误日志匹配当作可靠证据。

接着权威将 cached.lab.test 改为 127.0.0.8，缓存仍在剩余有效期内返回旧值 127.0.0.2。脚本只向这个特定 dnsmasq 进程发送 SIGHUP，并等待日志确认缓存已清除。下一次查询到达权威，返回 127.0.0.8，对应权威次数从一次增加到两次。信号、日志、回答和回源计数共同验证清理产生了实际效果。

同一次信号之后，local.lab.test 仍返回配置中的 127.0.0.9。转发缓存状态被清除，不代表显式本地记录消失。因此“刷新 DNS”不是完整排障说明：预期结果取决于哪个进程持有什么数据，以及该数据属于缓存、配置，还是另一个组件保存的状态。只有先识别来源，才能判断清理操作是否适用以及成功标准是什么。

有意识地管理监听与数据来源

一起检查有效配置、监听地址、上游目的地和客户端设置，避免两个本地解析器互相转发形成循环。本例去掉环境输入是为了隔离行为；真实安装可能有意读取 hosts、DHCP 租约或解析器管理软件生成的数据。应记录这些依赖，使自动重写和本地覆盖在排障时可见，而不是把它们隐藏在“系统 DNS”这个笼统名称之下。

按照 dnsmasq 手册，SIGHUP 会清缓存并重载特定数据来源，但通常不会重新读取主配置文件。应针对修改种类使用文档规定的服务操作，不能把清缓存成功当作监听、转发或其他启动配置编辑已经生效的证明。变更后还应从真实客户端路径检查目标行为，避免只验证进程仍在运行，就忽略新配置根本没有加载。

监听暴露应限制在预期客户端范围，尤其在可达网络上提供递归转发时。DHCP、DNSSEC 验证和加密上游传输都需要独立配置与验证，本实验没有证明这些能力。查询日志有助于诊断，也可能揭示客户端访问的名称，应根据环境选择范围和保留时间，而不是习惯性永久开启所有细节。日志用途应与实际排障需求对应。

最后，只有预期来源是权威时，才把缓存回答与该权威比较；本地配置名称应与它的配置比较。分别跟踪上游失败、缓存命中和条目周转，才能判断下一项有用修改涉及容量、寿命、上游服务还是本地命名规则。这样的观察能够解释差异的原因，而不是把每次不一致都归结为需要再清一遍缓存。

来源

dnsmasq manual，转发、cache-size、host-record、本地 TTL 与 SIGHUP 行为，已核验 2026-09-12。
RFC 1035 domain names，DNS 资源记录与缓存寿命，已核验 2026-09-12。

微缓存短暂复用新鲜条目，并显式合并并发未命中

Sun, 12 Mar 2028 00:00:00 +0000

微缓存让可复用响应保持很短的新鲜度寿命，常见尺度是几秒。在这个窗口里，请求同一选中表示的后续访问可以复用新鲜条目。响应可能落后于源站刚发生的更新，但不能仅因为它来自缓存，就称它在 HTTP 意义上已经过期。何时过期、是否允许提供过期内容、如何协调并发填充，是三个不同策略，需要分别定义。

坏掉的样子

TTL 短并不意味着共享响应对所有用户都安全。如果个性化请求读取或填充通用缓存条目，一个用户的表示就可能在另一个上下文里被交付。proxy_cache_bypass 根据条件禁止从缓存读取；proxy_no_cache 根据条件禁止保存响应。只控制其中一侧，可能让另一条路径不符合预期隐私边界。读取已有公开条目和保存新私有响应都需要考虑。

缓存键决定哪些请求共享响应。忽略有意义的查询参数或主机维度，可能合并不同表示；把任意变化数据全部放进键，又可能让复用失效。下面实验只有一个后端 authority，并保留包含参数的完整请求 URI。真实服务如果按租户、语言或其他输入改变内容，就必须确定自己的表示身份，不能把示例键当成适用于所有应用的通用公式。

仅仅启用缓存，也不保证冷启动突发只产生一次回源。在任何响应保存完成前，多个请求可能同时未命中同一条目。proxy_cache_lock 负责协调新条目的填充，并有有限的超时和年龄控制。这个锁不是 TTL，缩短新鲜度寿命也不会隐式开启锁。新鲜条目复用与并发未命中合并，需要通过不同对照才能验证。

快速验证

下文集成实验的结果保留自历史运行记录；本次修订没有重新执行该实验，不能将这些记录当成本次环境的新实测。

将脚本保存为 check-microcache.py，准备 Python、Docker 和固定镜像后执行。记录环境为 Linux arm64 上的 nginx 1.28.0。可丢弃后端报告每条路径的请求计数，nginx 使用两秒有效期，并显式设置 Cookie 与 Authorization 绕过条件。监听仅发布到宿主回环，使用的会话和授权值都是公开测试标记，不连接真实账户：

from contextlib import contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import http.client,json,socket,subprocess,time,uuid

NGINX='nginx@sha256:552e7481ca93ffccd046aa658dbbed22caefbc09c66fa7cd247cbb90b8a5c609'
PYTHON='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def wait(predicate):
 deadline=time.monotonic()+15
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except OSError:pass
 time.sleep(.1)
 raise AssertionError('fixture did not become ready')

@contextmanager
def lab(configuration,files=None,backend=None):
 name='xbcatm-nginx-'+uuid.uuid4().hex[:10];tags=[name+':proxy',name+':backend'];containers=[name+'-proxy',name+'-backend']
 try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'files').mkdir();(root/'nginx.conf').write_text(configuration)
 for path,content in (files or {}).items():
 target=root/'files'/path;target.parent.mkdir(parents=True,exist_ok=True)
 target.write_bytes(content if isinstance(content,bytes) else content.encode())
 docker('network','create',name)
 if backend is not None:
 (root/'backend.py').write_text(backend)
 (root/'backend.Dockerfile').write_text(f'FROM {PYTHON}\nCOPY backend.py /backend.py\nCMD ["python", "/backend.py"]\n')
 docker('build','--network','none','-f',str(root/'backend.Dockerfile'),'-t',tags[1],str(root))
 docker('run','-d','--name',containers[1],'--network',name,'--network-alias','backend',tags[1])
 wait(lambda:docker('exec',containers[1],'python','-c','import socket;s=socket.create_connection(("127.0.0.1",8081),timeout=.5);s.close()',check=False).returncode==0)
 (root/'Dockerfile').write_text(f'FROM {NGINX}\nCOPY nginx.conf /etc/nginx/nginx.conf\nCOPY files /srv\n')
 docker('build','--network','none','-t',tags[0],str(root))
 docker('run','--rm','--network',name,tags[0],'nginx','-t')
 docker('run','-d','--name',containers[0],'--network',name,'-p','127.0.0.1::8080',tags[0])
 details=json.loads(docker('inspect',containers[0]).stdout)[0]
 binding=details['NetworkSettings']['Ports']['8080/tcp'][0];assert binding['HostIp']=='127.0.0.1';port=int(binding['HostPort'])
 def ready():
 connection=socket.create_connection(('127.0.0.1',port),timeout=.5);connection.close();return True
 wait(ready)
 def request(path,method='GET',headers=None,body=None):
 connection=http.client.HTTPConnection('127.0.0.1',port,timeout=5)
 try:
 connection.request(method,path,body=body,headers=headers or {})
 response=connection.getresponse();return response.status,{k.lower():v for k,v in response.getheaders()},response.read()
 finally:connection.close()
 request.port=port
 yield containers[0],request
 finally:
 docker('rm','-f',*containers,check=False);docker('image','rm',*tags,check=False);docker('network','rm',name,check=False)

def config(locations,extra=''):
 return 'worker_processes 1;\nerror_log /tmp/error.log notice;\nevents {}\nhttp {\naccess_log off;\n'+extra+'\nserver { listen 8080; root /srv;\n'+locations+'\n}\n}\n'
from concurrent.futures import ThreadPoolExecutor
import threading
backend=r'''
from http.server import BaseHTTPRequestHandler,ThreadingHTTPServer
from urllib.parse import urlsplit,parse_qs
import json,threading
lock=threading.Lock();counts={};gates={'/lock':threading.Event(),'/nolock':threading.Event()}
class Handler(BaseHTTPRequestHandler):
 protocol_version='HTTP/1.1'
 def log_message(self,*args):pass
 def do_GET(self):
 parsed=urlsplit(self.path)
 if parsed.path=='/control/state':
 with lock:data=dict(counts)
 elif parsed.path=='/control/release':
 gates[parse_qs(parsed.query)['path'][0]].set();data={'released':True}
 else:
 with lock:counts[self.path]=counts.get(self.path,0)+1;count=counts[self.path]
 if parsed.path in gates:assert gates[parsed.path].wait(15)
 data={'path':self.path,'count':count,'cookie':self.headers.get('Cookie'),'authorization_present':bool(self.headers.get('Authorization'))}
 body=json.dumps(data,sort_keys=True).encode();self.send_response(200)
 if parsed.path=='/cookie':self.send_header('Set-Cookie','fixture=public-example; Path=/')
 if parsed.path=='/private':self.send_header('Cache-Control','private')
 if parsed.path=='/no-store':self.send_header('Cache-Control','no-store')
 self.send_header('Content-Type','application/json');self.send_header('Content-Length',str(len(body)));self.end_headers();self.wfile.write(body)
ThreadingHTTPServer(('0.0.0.0',8081),Handler).serve_forever()
'''
extra='''
proxy_cache_path /tmp/cache levels=1:2 keys_zone=pages:1m inactive=30s max_size=10m;
map $http_cookie $skip_cookie { default 1; "" 0; }
map $http_authorization $skip_auth { default 1; "" 0; }
proxy_cache pages; proxy_cache_key "$scheme|$proxy_host|$request_uri"; proxy_cache_valid 200 2s;
proxy_cache_bypass $skip_cookie $skip_auth; proxy_no_cache $skip_cookie $skip_auth;
proxy_cache_lock on; proxy_cache_lock_timeout 5s; proxy_cache_lock_age 5s;
add_header X-Cache $upstream_cache_status always;
'''
locations='''
location /control/ { proxy_cache off; proxy_pass http://backend:8081; }
location = /nolock { proxy_cache_lock off; proxy_pass http://backend:8081; }
location / { proxy_pass http://backend:8081; }
'''
with lab(config(locations,extra),backend=backend) as (_,request):
 def get(path,headers=None):
 status,h,b=request(path,headers=headers);assert status==200;return h.get('x-cache'),json.loads(b)
 results={}
 first=get('/item?x=1');second=get('/item?x=1');assert first[0]=='MISS' and second==('HIT',first[1])
 other=get('/item?x=2');assert other[0]=='MISS' and other[1]['path']!=first[1]['path']
 results['fresh']=[first[0],second[0]];results['different_query']=other[0]
 for name,headers in [('cookie',{'Cookie':'session=public-fixture'}),('authorization',{'Authorization':'Bearer public-fixture'})]:
 private=get('/item?x=1',headers);assert private[0]=='BYPASS' and private[1]!=first[1]
 assert get('/item?x=1')==('HIT',first[1])
 new='/new-'+name;assert get(new,headers)[0]=='BYPASS'
 public=get(new);assert public[0]=='MISS' and public[1]['cookie'] is None and not public[1]['authorization_present']
 results[name]={'warm_key':'BYPASS','public_after_private_miss':public[0]}
 for path in ['/cookie','private','no-store']:
 path='/'+path.lstrip('/');a=get(path);b=get(path)
 assert a[0]==b[0]=='MISS' and a[1]['count']==1 and b[1]['count']==2
 results[path]=[a[0],b[0]]
 deadline=time.monotonic()+6
 while time.monotonic()<deadline:
 value=get('/item?x=2')
 if value[0]=='EXPIRED':break
 assert value[0]=='HIT';time.sleep(.15)
 else:raise AssertionError('TTL did not expire')
 assert value[1]['count']==2;results['after_ttl']={'status':value[0],'count':value[1]['count']}
 for path,number,origin_count in [('/lock',6,1),('/nolock',4,4)]:
 barrier=threading.Barrier(number+1)
 def client():barrier.wait();return get(path)
 with ThreadPoolExecutor(max_workers=number) as pool:
 futures=[pool.submit(client) for _ in range(number)];barrier.wait()
 wait(lambda:get('/control/state')[1].get(path)==origin_count)
 time.sleep(.3);before=get('/control/state')[1][path]
 assert before==origin_count and not any(f.done() for f in futures)
 get('/control/release?path='+path);responses=[f.result(timeout=10) for f in futures]
 assert get('/control/state')[1][path]==origin_count
 statuses=sorted(r[0] for r in responses)
 if path=='/lock':assert statuses==['HIT']*5+['MISS'] and all(r[1]==responses[0][1] for r in responses)
 else:assert statuses==['MISS']*4
 results[path]={'origin_requests_while_held':before,'cache_statuses':statuses}
 print(json.dumps(results,sort_keys=True))

首次公开请求 /item?x=1 报告 MISS，下一次报告 HIT，并保留相同后端结果。/item?x=2 有自己的 MISS，响应中的路径也不同。持续检查第二个条目，最终观察到 EXPIRED，后端计数变为二。这依据服务器时钟观察实际过期，不假定精确到亚秒的切换时刻；测试关注状态变化及重新计算，而不是某个固定睡眠值。

携带示例会话 Cookie 或授权标记时，即使公开条目已经预热，请求仍报告 BYPASS。之后的公开请求仍返回原公开 HIT。另一个对照先用这些头访问尚未出现的键，再公开访问；公开请求结果是 MISS，证明之前私有上下文的响应没有填充可复用条目。这样同时覆盖了绕过读取和禁止保存，而不只是证明某次私有请求到达后端。

后端带有 Set-Cookie、Cache-Control: private 或 Cache-Control: no-store 的响应，各自连续两次都报告 MISS，源站计数也增加。配置没有忽略这些响应控制。这区分了客户端上下文触发的绕过策略和源站声明的存储限制；不能以缓存只保留几秒为理由，覆盖其中任何一种隐私信号。是否允许共享应先于寿命长短判断。

对于开启锁的冷条目，六个客户端同时开始，后端故意暂不返回响应。放行前后端只看到一次请求；放行后，一个客户端报告 MISS，五个报告 HIT，并得到相同结果。对于另一个关闭锁的条目，四个被保持的客户端产生四次回源，全部报告 MISS。受控放行使重叠的未命中直接可见，而不是从总耗时推测是否发生请求合并。

分别决定新鲜度与过载行为

本实验的两秒设置用于符合条件的 200 响应，相关源站缓存头可以优先于配置有效期。应先决定哪些响应能共享，再选择寿命，并让缓存键对应真正改变内容的输入。高命中率不能证明选中的表示正确；如果键把不同用户或不同内容合并，命中率甚至可能很好，但语义已经错误。验证内容身份和减少回源需要一起进行。

等待锁的请求用额外等待换取较少源站工作。本实验在锁限制内放行后端，并没有证明限制到期或后端失败时仍永远只有一次回源。应结合服务可接受延迟和失败行为，审阅锁等待超时、锁年龄以及可能采用的过期响应策略。是否允许返回过期条目，不能由已经设置短 TTL 这一事实代替决定。

观察缓存状态时，同时核对源站计数和响应身份。MISS 表示请求表示没有作为缓存命中提供，BYPASS 则标明这里显式排除读取的路径。新鲜 HIT、EXPIRED 后重新填充，以及有意提供过期内容，不应混成一个笼统的“已缓存”结果。它们对正确性与后端负载的影响不同，正是需要分别测量和解释的原因。

来源

nginx proxy module，缓存有效期、缓存锁、绕过读取、禁止保存与响应头控制，已核验 2026-10-15。
nginx content caching guide，缓存键、状态观察与缓存行为，已核验 2026-10-15。
RFC 9111 HTTP Caching，新鲜与过期响应，以及 private、no-store 指令，已核验 2026-10-15。

DNS TTL 在重复回源查询与保留旧回答之间取舍

Wed, 01 Mar 2028 00:00:00 +0000

DNS TTL 是附着于缓存数据的寿命，不是每秒执行的刷新任务。只要条目仍被保留且有效，缓存可以复用它；过期后的下一次请求通常需要重新解析，除非启用了其他明确行为。无人查询的记录，并不一定在 TTL 归零时主动产生上游请求。因此讨论成本时，要同时看请求到达方式与缓存状态，不能把 TTL 直接当成定时查询频率。

坏掉的样子

持续查询相同数据时，缩短 TTL 可能增加上游工作，却不会让所有权威流量按同一个固定倍数增长。查询频率、解析器共享程度、缓存容量、预取和名称多样性都会影响结果。一个热门名称使用短 TTL，与大量只问一次的名称流，行为不同。没有这些负载条件，就无法仅凭 TTL 数字预测真实查询量或容量需求。

长 TTL 允许在权威数据修改后继续使用先前回答。该缓存仍可能符合最初收到的寿命要求，尽管内容已经不同于最新区域。把所有不一致都叫成过期或损坏，会混淆实际契约。TTL 表示允许保留多久，不承诺持续与权威同步。修改 TTL 同样不能追溯改变已经保存的更长寿命，需要等那些旧副本自然退出普通有效期。

多层转发通常不会让每一跳重新获得原始完整 TTL。缓存返回剩余寿命，下一层再继续计时。按层数累加完整 TTL，会虚构普通合规转发并不产生的传播延迟。本地 TTL 覆盖、提供陈旧回答等是另外的配置行为，存在时应明确识别。不能先假设所有解析器都遵守同一种特殊策略，再用这个假设解释实际观测。

快速验证

将脚本保存为 check-ttl-cost.py，准备 Docker 后执行 python3 check-ttl-cost.py。固定容器使用 BIND 9.18.49 与 dnsmasq 2.90，运行时没有外部网络。权威服务器记录实际查询；最初一个转发器服务两个名称，随后在它后面启动第二个转发器，检查交给下游的 TTL。所有服务和日志都属于临时实验，不修改现有解析基础设施：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid
recipe='FROM python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84\nRUN apt-get update && apt-get install -y --no-install-recommends bind9=1:9.18.49-1~deb12u2 bind9-dnsutils=1:9.18.49-1~deb12u2 dnsmasq-base=2.90-4~deb12u2 python3-dnspython=2.3.0-1 && rm -rf /var/lib/apt/lists/*\nCMD ["/usr/bin/python3"]\n'
program=r"""
from contextlib import ExitStack,contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import json,re,signal,subprocess,time
import dns.exception,dns.message,dns.query,dns.rcode,dns.rdatatype

def run(*args,check=True):
 result=subprocess.run(args,capture_output=True,text=True,timeout=15)
 if check:assert result.returncode==0,(args,result.returncode,result.stdout,result.stderr)
 return result
def query(name,kind='A',port=1053):
 return dns.query.udp(dns.message.make_query(name,kind),'127.0.0.1',port=port,timeout=1)
def values(response,kind='A'):
 wanted=dns.rdatatype.from_text(kind)
 return [item.to_text() for rrset in response.answer if rrset.rdtype==wanted for item in rrset]
def show(response):
 def section(records):return [{'name':str(rr.name),'type':dns.rdatatype.to_text(rr.rdtype),'ttl':rr.ttl,'data':[item.to_text() for item in rr]} for rr in records]
 return {'rcode':dns.rcode.to_text(response.rcode()),'answer':section(response.answer),'authority':section(response.authority)}
def wait(predicate,timeout=15):
 deadline=time.monotonic()+timeout
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except (OSError,dns.exception.Timeout):pass
 time.sleep(.05)
 raise AssertionError('DNS fixture condition did not become true')
def stop(process):
 if process.poll() is None:
 process.terminate()
 try:process.wait(timeout=5)
 except subprocess.TimeoutExpired:process.kill();process.wait(timeout=5)

@contextmanager
def lab(records,soa_ttl=8,minimum=4,extra=''):
 with TemporaryDirectory(prefix='xbcatm-dns-') as directory,ExitStack() as stack:
 root=Path(directory);zone=root/'zone';conf=root/'named.conf';log=root/'named.log';serial=1
 def save(body):
 zone.write_text(f'$ORIGIN lab.test.\n$TTL 30\n@ {soa_ttl} IN SOA ns.lab.test. hostmaster.lab.test. ({serial} 60 60 3600 {minimum})\n@ IN NS ns.lab.test.\nns IN A 127.0.0.1\n'+body+'\n')
 run('named-checkzone','lab.test',str(zone))
 save(records)
 conf.write_text(f'''options {{ directory "{root}"; listen-on port 1053 {{127.0.0.1;}}; listen-on-v6 {{none;}};
recursion no; dnssec-validation no; notify no; querylog yes; max-cache-size 8m; pid-file "{root}/named.pid"; session-keyfile none;
{extra} }};
controls {{}};
zone "lab.test" {{ type primary; file "{zone}"; }};
''')
 run('named-checkconf',str(conf))
 output=stack.enter_context(log.open('w'))
 authority=subprocess.Popen(['named','-g','-c',str(conf),'-n','1','-U','1'],stdout=output,stderr=subprocess.STDOUT)
 stack.callback(stop,authority)
 def ready():
 assert authority.poll() is None,log.read_text()
 response=query('lab.test.','SOA');return response.rcode()==0 and response.answer[0][0].serial==serial
 wait(ready)
 def update(body):
 nonlocal serial
 serial+=1;save(body);authority.send_signal(signal.SIGHUP);wait(ready)
 def cache(port=1054,upstream=1053,size=150,options=()):
 logfile=root/('cache-'+str(port)+'.log');stream=stack.enter_context(logfile.open('w'))
 command=['dnsmasq','--no-daemon','--conf-file=/dev/null','--no-resolv','--no-hosts','--bind-interfaces',
 '--listen-address=127.0.0.1','--port='+str(port),'--server=127.0.0.1#'+str(upstream),
 '--cache-size='+str(size),'--log-queries','--log-facility=-',*options]
 process=subprocess.Popen(command,stdout=stream,stderr=subprocess.STDOUT);stack.callback(stop,process)
 def cache_ready():
 assert process.poll() is None,logfile.read_text()
 return query('lab.test.','SOA',port).rcode()==0
 wait(cache_ready);return process,logfile
 def queries(name,kind='A'):
 return sum(bool(re.search(r'query: '+re.escape(name.rstrip('.'))+r' IN '+kind+r'\b',line)) for line in log.read_text().splitlines())
 yield root,update,cache,queries
with lab('short 1 IN A 127.0.0.2\nlong 20 IN A 127.0.0.3\nchain 6 IN A 127.0.0.4') as (_,update,cache,queries):
 cache();samples=[]
 for i in range(3):
 pair={name:show(query(name+'.lab.test.',port=1054)) for name in ('short','long')};samples.append(pair)
 if i<2:time.sleep(1.2)
 wait(lambda: queries('short.lab.test')==3 and queries('long.lab.test')==1)
 first=query('chain.lab.test.',port=1054);assert first.answer[0].ttl==6
 wait(lambda: queries('chain.lab.test')==1)
 time.sleep(2.2);cache(port=1055,upstream=1054)
 downstream=query('chain.lab.test.',port=1055);upstream=query('chain.lab.test.',port=1054)
 assert values(downstream)==['127.0.0.4'] and 0<downstream.answer[0].ttl<6
 assert abs(downstream.answer[0].ttl-upstream.answer[0].ttl)<=1
 assert queries('chain.lab.test')==1
 update('short 1 IN A 127.0.0.2\nlong 20 IN A 127.0.0.3\nchain 6 IN A 127.0.0.5')
 wait(lambda: values(query('chain.lab.test.',port=1055))==['127.0.0.5'],timeout=8)
 wait(lambda: queries('chain.lab.test')==2)
 print(json.dumps({'three_lookups_each':samples,'authority_query_counts':{'short':queries('short.lab.test'),'long':queries('long.lab.test')},
 'cache_chain':{'original':show(first),'downstream_first':show(downstream),'upstream_remaining':show(upstream),'authority_queries_after_expiry':queries('chain.lab.test')}},sort_keys=True))
"""
name='xbcatm-dns-'+uuid.uuid4().hex[:10]
def docker(*args,**kwargs):return subprocess.run(['docker',*args],capture_output=True,text=True,timeout=300,**kwargs)
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'Dockerfile').write_text(recipe)
 built=docker('build','-t',name,str(root));assert built.returncode==0,built.stderr
 result=docker('run','--rm','-i','--name',name,'--network','none','--memory','384m','--pids-limit','128',name,
 '/usr/bin/python3','-',input=program)
 assert result.returncode==0,result.stderr
 print(json.dumps(json.loads(result.stdout),sort_keys=True))
finally:
 docker('rm','-f',name);docker('image','rm',name)

short.lab.test 的 TTL 为一秒，long.lab.test 为二十秒。程序各查询三次，轮次间等待一点二秒。权威日志显示短寿命记录收到三次查询，长寿命记录只有一次，而每一轮客户端都得到成功回答。这个差异说明受控请求节奏下的上游工作量，不是应用延迟提升的基准测试，更不能据此推导公网解析性能增加多少倍。

长寿命回答的剩余 TTL 随轮次下降，短寿命回答每次刷新后重新从一秒开始。脚本直接检查权威日志，不以“响应很快”假定命中缓存。回环网络里没有命中的查询也可能很快，单看耗时无法证明是否联系权威。先确认真实查询计数，再解释缓存复用，才能让实验结论对应实际执行路径，而非依赖肉眼感受。

在双层案例中，第一个转发器缓存 chain.lab.test，初始 TTL 为六秒。等待两点二秒后，新启动的第二层通过它查询。实测下游回答 TTL 为三秒，与上游剩余值在整数秒计时误差范围内一致，并没有重新获得六秒。权威计数仍为一次，证明下游填充复用了第一层现有条目，而不是恰好重新取得另一份新鲜权威回答。

随后权威修改该记录地址。经第二层查询最终得到新地址，权威次数增加为两次。这验证已有数据到期后，两层转发都能正常获得更新。精确到期小数受实现和调度影响；断言关注剩余寿命被传递、没有提前增加额外权威查询，以及最终取得修改后的值。这个实验反对简单累加 TTL，并不声称所有应用缓存都自动具有相同行为。

依据真实需求选择寿命

选择 TTL 时，同时考虑变更频率、可接受的旧回答重叠期和查询量。共享繁忙解析器可以让很多客户端复用一次回答，彼此隔离的缓存则会重复填充。条目可能因容量淘汰而在 TTL 之前消失，因此长寿命不保证命中。应测量命中、未命中、上游请求和可用容量，不能把 TTL 当作缓存大小控制，也不能把提前淘汰误判为协议错误。

计划迁移时，应提前降低 TTL，让更早获得的长寿命副本有时间过期，并据真实保留数据安排端点重叠。稳定后提高 TTL，可减少热门记录的重复解析，同时也延长下一次变更的普通等待窗口。配置单位应关注记录集：名称、类别和类型相同的记录，应使用一致 TTL，而不是给各个地址配置不同寿命来模拟优先级或权重。

最后，对照应用实际使用的各个解析器，查看回答内容和剩余寿命。直接权威查询与递归缓存回答展示的是不同状态，不能拿其中一个覆盖另一个。应用自有缓存和已经建立的连接，还可能具有实验之外的生命周期。估算用户多久发现新端点、以及 TTL 调整需要多少权威容量前，先把这些寿命与 DNS 缓存寿命区分清楚。

来源

RFC 1035 domain names，TTL 缓存寿命与缓存记录处理，已核验 2026-09-12。
RFC 2181 DNS clarifications，TTL 限制与记录集内部一致的寿命，已核验 2026-09-12。
dnsmasq manual，缓存容量、转发与 TTL 选项，已核验 2026-09-12。

Docker 构建缓存复用已记录的工作，也可能复用过期结果

Sun, 20 Feb 2028 00:00:00 +0000

Docker 构建缓存保存构建操作的结果，让后续构建在相关输入仍匹配时复用已有工作。缓存命中不表示命令重新运行并生成相同输出，而是构建器接受了一份先前结果。这个区别直接影响软件包安装、生成时间戳、远程下载，以及输出可能变化却没有相应声明输入变化的操作。理解缓存时，首先要区分“再次执行”和“取出已经执行过的结果”。

坏掉的样子

没有变化的 RUN apt-get update 可以直接复用昨天的结果，完全不访问软件仓库。构建器通常不会为了判断这条 RUN 是否仍然新鲜，先检查远端仓库有没有更新。因此，缓存构建成功不能独立证明软件包已经收到最新安全修复。刷新策略必须明确，并与项目要求的可复现性一致，不能依赖某次构建恰好缓存失效。

COPY 的输入不同于普通命令字符串。文件内容和相关元数据参与缓存计算，但源文件修改时间本身不参与。部署脚本如果只是 touch 文件，依赖它的 RUN 仍可能继续命中缓存。反过来，即使文本完全相同，改变可执行权限也可能使 COPY 失效，从而重新执行后续工作。排查时需要比较实际输入，不能只看文件大小和肉眼可见的文字。

基础镜像、步骤实际使用的构建参数和前置依赖也会影响结果。缓存失效沿依赖传播，不能把复杂多阶段构建一律解释成从某行开始全部重做的直线。下面使用简单的单阶段链：复制文件发生变化，就使其后的时间戳 RUN 重新执行，而固定基础镜像的文件系统层仍可继续复用。这种受控结构让实验结论容易对应到真实原因。

快速验证

使用宿主 Python 运行脚本，并连接一个可用于实验的 Docker 构建器。如果本地没有指定摘要，先拉取它。实测环境是 Docker 29.3.1、Buildx 0.32.1，以及 Linux arm64 的 Python 3.11.16 基础镜像。构建和容器均关闭网络。脚本删除自己的临时标签，不清理其他镜像，也不对全局构建缓存执行 prune：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,os,shlex,subprocess,uuid

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(["docker",*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def inspect(image):return json.loads(docker("image","inspect",image).stdout)[0]

name='xbcatm-cache-'+uuid.uuid4().hex[:10];tag=name+':probe'
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);app=root/'app.txt';app.write_text('initial '+name);app.chmod(0o644)
 build_code="from pathlib import Path;import time;Path('/built-at').write_text(str(time.time_ns()))"
 (root/'Dockerfile').write_text(f'FROM {BASE}\nCOPY app.txt /app.txt\nRUN python -c {shlex.quote(build_code)}\n')
 def build(*options):return docker('build','--network','none','--progress','plain',*options,'-t',tag,str(root))
 def stamp():return docker('run','--rm','--network','none',tag,'python','-c',"from pathlib import Path;print(Path('/built-at').read_text())").stdout.strip()
 build();initial=stamp();base_layers=inspect(BASE)['RootFS']['Layers']
 result=build();assert stamp()==initial and 'CACHED' in result.stderr
 timestamp=app.stat().st_mtime_ns+10_000_000_000;os.utime(app,ns=(timestamp,timestamp))
 build();assert stamp()==initial
 print('unchanged inputs reuse the RUN result; changing only source mtime also leaves that result cached')
 app.chmod(0o755);build();mode_changed=stamp();assert mode_changed!=initial
 app.write_text('changed '+name);build();content_changed=stamp();assert content_changed!=mode_changed
 print('changing copied-file permissions or content invalidates COPY and reruns the dependent RUN')
 build('--no-cache');assert stamp()!=content_changed
 assert inspect(tag)['RootFS']['Layers'][:len(base_layers)]==base_layers
 print('no-cache reruns the instruction while this pinned base retains the same filesystem layer prefix')
finally:docker('image','rm',tag,check=False)

首次构建把纳秒时间戳写进 /built-at。第二次用相同输入构建，日志出现缓存操作，镜像中的时间戳也完全相同。这比比较构建耗时更有说服力：命令可能执行得很快，但保留下来的同一个时间戳表明，这里复用了之前记录的结果。测试同时看日志和目标文件，避免把其他步骤命中缓存误认为目标 RUN 命中。

随后脚本只推进源文件的修改时间，镜像内时间戳保持不变。这直接验证文档所说的 mtime 排除规则，不代表所有文件元数据都被忽略。接着把模式从 0644 改为 0755，时间戳更新，证明本次 COPY 依赖会受到可执行位变化的影响。两步只改变一个因素，能够区分时间与权限的不同作用。

再修改文件文本，会得到另一个时间戳。输入中包含本次实验的唯一名字，避免以前的同类实验碰巧提供初始应用结果。每一步都读取实际镜像内容进行断言，而不是看到构建日志任意位置有 CACHED 就宣布被研究的操作已经复用。对于多条 RUN 的真实项目，也应采用能定位具体步骤的证据。

最后，应用输入保持不变，使用 --no-cache 后 RUN 再次执行。镜像检查仍显示与原来相同的固定基础层前缀。这个选项禁止构建指令复用缓存，不会把明确选择的基础摘要自动替换成另一个新版本。需要更新基础镜像时，应选择预期的新产物；浮动标签是否重新查询，则还涉及单独的拉取策略。

把新鲜度变成明确输入

让稳定的依赖输入先于频繁修改的源码，并通过窄范围 COPY 避免无关文件成为依赖。如果要求重复得到受控结果，就固定软件包版本或经过校验的下载产物。需要主动刷新依赖时，更新这些声明并审阅产物，不应把“这次没有命中缓存”本身当作安全更新策略，因为远端内容和安装规则仍可能不可控。

密钥挂载还需要单独考虑：密钥内容变化不会自动使构建缓存失效。如果密钥影响一次需要刷新的下载，可以使用明确的非敏感修订输入，或显式要求相关步骤重新执行。不要为了改变缓存键，把真实凭据塞进构建参数；缓存控制与凭据传递有不同的安全边界，不应混在一个字段里处理。

缓存命中日志说明性能方面的复用，真正执行的测试说明行为。记录最终产物身份，测试该产物，并保留足以解释它如何生成的构建输入。快速重建只有在复用的工作仍符合本次发布意图时才有价值；否则，速度只是把陈旧结果更快地交给了下一阶段。

来源

Docker build cache invalidation，缓存输入、修改时间、RUN 复用与显式失效，已核验 2026-09-12。
Dockerfile reference，COPY 元数据、RUN 指令与构建参数，已核验 2026-09-12。

nginx 验证器是否可靠，取决于表示身份是否准确

Thu, 17 Feb 2028 00:00:00 +0000

验证器让接收方询问：自己保存的表示，是否仍与当前选中的表示相符。条件 GET 验证成功时，可以返回没有正文的 304，避免重新传输内容。新鲜度是另一个决定，它控制已存响应何时能直接复用而不发送这次请求。ETag 本身不指定缓存寿命，304 也不是一份替代正文；客户端需要保留原响应，才能利用成功验证的结果。

坏掉的样子

把所有 ETag 都叫作正文哈希，会掩盖 nginx 的一个重要实现细节。在这里测试的 1.28.0 静态文件实现中，生成的标签组合了修改时间和内容长度，并不计算文件内容哈希。如果替换字节时保留这两个输入，就可能保留同一个标签。于是，持有不同旧字节的客户端仍收到看似成功的验证，错误不能仅靠“响应里有 ETag”来排除。

强弱验证器适用于不同比较。对于需要字节身份的用途，强验证器必须能区分表示数据变化；弱验证器则可以把字节不同、但被认为语义等价的表示归在一起。W/ 并不是“接受字节等价变化”的标志，也不意味着这个标签适用于所有前提条件或字节范围续传。使用哪种比较，需要依据具体请求条件，而不是凭标签外观猜测。

条件请求不保证省掉应用计算。服务器可能先生成表示，之后才判断验证器是否匹配。这个静态 nginx 示例根本没有应用渲染器。较小的响应在这里证明节省了正文传输，却不能证明数据库查询、渲染成本或回源请求数必然减少。评估优化效果时，应把实际减少的数据传输和实际减少的后台工作分别测量。

快速验证

把脚本保存为 check-validators.py，先取得固定摘要的 nginx 镜像，再用 Python 和 Docker 运行。它通过宿主回环提供一个可丢弃的四字节静态文件，实测 nginx 版本为 1.28.0。实验只控制容器内文件的时间属性，不修改宿主时间，也不修改共享 Docker 虚拟机时钟：

from contextlib import contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import http.client,json,socket,subprocess,time,uuid

NGINX='nginx@sha256:552e7481ca93ffccd046aa658dbbed22caefbc09c66fa7cd247cbb90b8a5c609'
PYTHON='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def wait(predicate):
 deadline=time.monotonic()+15
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except OSError:pass
 time.sleep(.1)
 raise AssertionError('fixture did not become ready')

@contextmanager
def lab(configuration,files=None,backend=None):
 name='xbcatm-nginx-'+uuid.uuid4().hex[:10];tags=[name+':proxy',name+':backend'];containers=[name+'-proxy',name+'-backend']
 try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'files').mkdir();(root/'nginx.conf').write_text(configuration)
 for path,content in (files or {}).items():
 target=root/'files'/path;target.parent.mkdir(parents=True,exist_ok=True)
 target.write_bytes(content if isinstance(content,bytes) else content.encode())
 docker('network','create',name)
 if backend is not None:
 (root/'backend.py').write_text(backend)
 (root/'backend.Dockerfile').write_text(f'FROM {PYTHON}\nCOPY backend.py /backend.py\nCMD ["python", "/backend.py"]\n')
 docker('build','--network','none','-f',str(root/'backend.Dockerfile'),'-t',tags[1],str(root))
 docker('run','-d','--name',containers[1],'--network',name,'--network-alias','backend',tags[1])
 wait(lambda:docker('exec',containers[1],'python','-c','import socket;s=socket.create_connection(("127.0.0.1",8081),timeout=.5);s.close()',check=False).returncode==0)
 (root/'Dockerfile').write_text(f'FROM {NGINX}\nCOPY nginx.conf /etc/nginx/nginx.conf\nCOPY files /srv\n')
 docker('build','--network','none','-t',tags[0],str(root))
 docker('run','--rm','--network',name,tags[0],'nginx','-t')
 docker('run','-d','--name',containers[0],'--network',name,'-p','127.0.0.1::8080',tags[0])
 details=json.loads(docker('inspect',containers[0]).stdout)[0]
 binding=details['NetworkSettings']['Ports']['8080/tcp'][0];assert binding['HostIp']=='127.0.0.1';port=int(binding['HostPort'])
 def ready():
 connection=socket.create_connection(('127.0.0.1',port),timeout=.5);connection.close();return True
 wait(ready)
 def request(path,method='GET',headers=None,body=None):
 connection=http.client.HTTPConnection('127.0.0.1',port,timeout=5)
 try:
 connection.request(method,path,body=body,headers=headers or {})
 response=connection.getresponse();return response.status,{k.lower():v for k,v in response.getheaders()},response.read()
 finally:connection.close()
 request.port=port
 yield containers[0],request
 finally:
 docker('rm','-f',*containers,check=False);docker('image','rm',*tags,check=False);docker('network','rm',name,check=False)

def config(locations,extra=''):
 return 'worker_processes 1;\nerror_log /tmp/error.log notice;\nevents {}\nhttp {\naccess_log off;\n'+extra+'\nserver { listen 8080; root /srv;\n'+locations+'\n}\n}\n'
files={'asset.txt':'AAAA','noetag.txt':'AAAA'}
with lab(config('location = /noetag.txt { etag off; }'),files) as (proxy,request):
 def timestamp(value):docker('exec',proxy,'touch','-m','-d','@'+str(value),'/srv/asset.txt')
 timestamp(1577836800)
 status,headers,body=request('/asset.txt');assert status==200 and body==b'AAAA'
 tag=headers['etag'];modified=headers['last-modified'];results={'etag':tag,'last_modified':modified}
 cases={
 'matching_tag':({'If-None-Match':tag},304),
 'weak_comparison':({'If-None-Match':'W/'+tag},304),
 'matching_date':({'If-Modified-Since':modified},304),
 'tag_takes_precedence':({'If-None-Match':'"different"','If-Modified-Since':modified},200),
 'weak_if_match_rejected':({'If-Match':'W/'+tag},412),
 }
 for name,(conditions,expected) in cases.items():
 status,_,body=request('/asset.txt',headers=conditions);assert status==expected,(name,status)
 if status==304:assert body==b''
 results[name]=status
 docker('exec',proxy,'sh','-c','printf BBBB > /srv/asset.txt');timestamp(1577836800)
 status,current,body=request('/asset.txt');assert status==200 and body==b'BBBB' and current['etag']==tag
 status,_,body=request('/asset.txt',headers={'If-None-Match':tag});assert status==304 and body==b''
 results['changed_bytes_preserved_metadata']=status
 timestamp(1577836802)
 status,current,body=request('/asset.txt',headers={'If-None-Match':tag})
 assert status==200 and body==b'BBBB' and current['etag']!=tag and current['last-modified']!=modified
 results['changed_metadata']={'status':status,'etag':current['etag']}
 status,current,_=request('/noetag.txt');assert status==200 and 'etag' not in current
 print(json.dumps(results,sort_keys=True))

最初文件内容是 AAAA，修改时间固定为 2020-01-01，产生 ETag "5e0be100-4"。GET 在 If-None-Match 中携带这个标签时，得到正文为空的 304。把请求标签加上 W/ 仍返回 304，因为该条件采用弱比较。在本次配置中，携带相等 If-Modified-Since 日期，也会得到 304。这些结果展示标签与日期两条验证路径。

如果同时发送不匹配的 If-None-Match 和匹配日期，则返回 200。实体标签条件优先于日期条件；不能通过补一个有利时间戳，让不匹配标签被忽略。单独的 If-Match 检查会拒绝弱请求标签并返回 412。这里实际执行的是 GET 前提条件检查，并没有执行写入业务流程，因此不能把结果扩展为完整并发写保护已经验证。

随后脚本把 AAAA 改成 BBBB，并恢复原修改时间。无条件 GET 证明正文已经变化，而标签仍完全相同。再次发送旧标签，又得到 304。这是有意构造的反例：即使 nginx 正确执行自己的标签生成算法，部署时保留元数据也可能破坏期望的表示身份契约。检查正文变化和标签变化必须配对进行，不能只看一个成功状态码。

把文件时间推进两秒后，生成的标签和 Last-Modified 都变化了。携带旧标签的请求随后得到 200 和 BBBB。最后一个对照在另一资源上关闭 etag，确认不再生成 ETag 响应头。关闭标签只是移除这一验证器，不会自动得到更强的替代，也不会自动关闭所有缓存。要采取哪种验证策略，仍需与实际发布方式一起设计。

让部署保持验证器契约

如果需要不同版本的字节分别拥有稳定地址，可以用内容导出的文件名在 URL 层区分版本。对于必须保留的稳定 URL，应确保表示字节变化时部署元数据也随之变化，或者由服务应用明确提供合适的内容派生验证器。审阅时既要考虑快速发生的同长度更新，也要检查复制新内容时保留时间戳的工具，避免只覆盖普通手工修改路径。

Last-Modified 同样需要谨慎理解。它是精度有限的时间戳，不是密码学身份。不能把任何日期都直接视为续传所需的强验证器；协议规定的条件和服务器真实更新行为都有关，尤其是一个有效时间精度窗口内可能出现多个版本时。实验推进两秒是为了明确改变输入，并不是宣称等待两秒能解决所有发布一致性问题。

最后，应检查经过中间层和内容编码后真正交付的表示。在要求强比较的场景，一种表示的验证器不能错误地标识另一串不同字节。把缓存寿命、条件验证、隐私和字节完整性分别作为明确决策，并在部署检查中同时验证未变化和已变化两种情况，才能发现这类只在更新时出现的问题。

来源

RFC 9110 HTTP Semantics，强弱验证器、条件优先级及 304、412 响应，已核验 2026-09-12。
RFC 9111 HTTP Caching，新鲜度、已存响应与成功验证，已核验 2026-09-12。
nginx 1.28.0 core source，根据修改时间与内容长度生成静态 ETag 的实现，已核验 2026-09-12。
nginx HTTP core module，etag 与 if_modified_since 配置，已核验 2026-09-12。

PostgreSQL 使用两层数据缓存

Thu, 27 Jan 2028 00:00:00 +0000

普通缓冲式关系文件读写中，PostgreSQL 的共享缓冲位于操作系统文件缓存之上。命中共享缓冲时，不需要再次通过下面的文件读取路径；没有命中时，也可能由操作系统直接从内存提供数据。同一文件内容可以在两层各有副本，所以这里并不承诺数据库与内核共用同一份物理内存，更不能把两层缓存理解为完全没有重复占用。

坏掉的样子

执行计划里的共享读取计数，表示块被读入 PostgreSQL 缓冲池，不证明存储设备实际执行了一次物理读取。如果把每次共享读取都算成磁盘未命中，已经温热的操作系统缓存也会被误认为冰冷，从而引出错误的内存配置判断。同样，第二次查询更快，也不能独自说明究竟是哪一层缓存发生了变化，或是否只是其他执行条件改变。

缓存驻留是临时状态。其他查询可能挤走页面，工作集超过容量时，也不能指望所有页永久留在内存里；关系扫描采用的缓冲策略还可能影响复用方式。因此应使用已知大小的工作集、检查实际访问路径，并把耗时结论与真正观察到的缓存层事实分开。没有设备层测量，就不能仅凭一个计划字段宣布磁盘速度发生了变化。

快速验证

使用 PostgreSQL 18 可丢弃实例和超级用户，确保附带的缓冲观察与预热扩展可安装、且尚未安装。本轮在 PostgreSQL 18.6 单用户后端重跑 SQL，使用一百二十八兆字节共享缓冲；未测试 psql 传输与并发活动。下面的数据可以轻松放下。通过一个全新的 psql -X -v ON_ERROR_STOP=1 会话按顺序执行。关系驱逐函数用于开发测试，这里只针对隔离实验创建的对象操作：

CREATE SCHEMA cache_layer_demo;
CREATE EXTENSION pg_buffercache WITH SCHEMA cache_layer_demo;
CREATE EXTENSION pg_prewarm WITH SCHEMA cache_layer_demo;
CREATE TABLE cache_layer_demo.items (id integer PRIMARY KEY,payload text)
 WITH (autovacuum_enabled=false);
INSERT INTO cache_layer_demo.items
SELECT g,repeat(md5(g::text),10) FROM generate_series(1,12000) AS g;
VACUUM (ANALYZE) cache_layer_demo.items;
CREATE VIEW cache_layer_demo.residency AS
SELECT count(*) AS heap_buffers FROM cache_layer_demo.pg_buffercache
WHERE reldatabase=(SELECT oid FROM pg_database WHERE datname=current_database())
 AND relfilenode=pg_relation_filenode('cache_layer_demo.items')
 AND relforknumber=0;
SET max_parallel_workers_per_gather=0;
SELECT pg_relation_size('cache_layer_demo.items')/current_setting('block_size')::int AS heap_blocks;
SELECT heap_buffers>0 AS initially_buffered FROM cache_layer_demo.residency;

本次构建的主堆有五百四十六个块，初始缓存比较返回真。观察视图限制数据库、文件标识与主分支，并假定这个新建实验只使用默认表空间。通用监控还必须区分表空间，因为文件编号不是数据库内跨表空间唯一的物理身份。每个缓冲条目的观察是一致的，但整个视图并不是同一瞬间的原子缓存快照。接着，仅驱逐这个关系的共享缓冲：

SELECT * FROM cache_layer_demo.pg_buffercache_evict_relation('cache_layer_demo.items'::regclass);
SELECT heap_buffers=0 AS no_shared_heap_buffers FROM cache_layer_demo.residency;

函数返回驱逐、刷出和未能驱逐的数量，本次分别为五百五十、五百五十和零。总数包含辅助分支，所以比只统计主堆的块数更大。后面的比较确认主堆共享缓冲已为空，但这个结果没有回答操作系统里是否仍然缓存着同一批文件页面。两层的状态需要分别观察，不能从一层为空推断另一层也为空。

通过操作系统同步读取主堆，但不把内容加载进数据库共享缓冲：

SELECT cache_layer_demo.pg_prewarm('cache_layer_demo.items','read','main');
SELECT heap_buffers=0 AS still_no_shared_heap_buffers FROM cache_layer_demo.residency;

预热函数处理了五百四十六个块，共享缓冲数量仍是零。这里选择的是同步读取模式；若改用缓冲模式，就会把页加载到数据库缓冲池。现在执行一个需要访问全部载荷的查询：

EXPLAIN (ANALYZE,BUFFERS,COSTS OFF,TIMING OFF,SUMMARY OFF,FORMAT JSON)
SELECT sum(length(payload)) FROM cache_layer_demo.items;

顺序扫描报告五百四十六次共享读取，共享命中为零。这与操作系统缓存已经温热完全相容，不能把它翻译成五百四十六次设备读操作。再执行同样的查询：

EXPLAIN (ANALYZE,BUFFERS,COSTS OFF,TIMING OFF,SUMMARY OFF,FORMAT JSON)
SELECT sum(length(payload)) FROM cache_layer_demo.items;

第二次扫描共享读取为零，共享命中为五百四十六。两次都处理一万两千行，所以缓冲计数变化并不是因为查询少读了业务记录。最后核对驻留状态和聚合结果，再清理实验与扩展：

SELECT heap_buffers>0 AS now_shared FROM cache_layer_demo.residency;
SELECT sum(length(payload)) FROM cache_layer_demo.items;
RESET max_parallel_workers_per_gather;
DROP SCHEMA cache_layer_demo CASCADE;

载荷字符总数应为三百八十四万，共享驻留比较为真。精确块数取决于行布局和构建参数；关键观察是同步预热后共享缓冲仍为空，首次查询发生共享读取，再次查询转为命中。这些结果没有测量设备延迟，也不保证某个固定倍数的加速。用它们说明缓存层次是合适的，用来预测生产查询耗时则证据不足。

为整个服务器分配内存

资源配置文档对内存充足的专用服务器，给出了共享缓冲约占系统内存四分之一的起始建议，但这不是任何负载都最优的常数。连接本身、并发排序与哈希、维护任务，以及操作系统缓存，都在使用同一个主机预算。只增加一层的容量，可能把其他工作所需的余量挤掉，因此不能孤立地看共享命中率决定配置。

修改之前应测量有代表性的工作集与并发请求。全部缓存已经温热的微型测试会隐藏读写压力，完全冷启动测试又可能夸大平时高度复用页面的负载代价。把缓存层计数、设备层观察和查询结果结合起来，才能把配置调整的收益归到它实际改变的那一部分，而不是把所有内存读取都叫作磁盘优化。

来源

PostgreSQL 18 资源消耗，共享缓冲与操作系统缓存的内存预算，已核验 2026-10-15。
PostgreSQL 18 pg_prewarm，同步读取和数据库缓冲预热模式，已核验 2026-10-15。
PostgreSQL 18 pg_buffercache，缓冲身份及开发测试用的关系驱逐函数，已核验 2026-10-15。
PostgreSQL 文件布局，数据库、表空间与关系文件身份，已核验 2026-10-15。

Redis 的过期是截止时间，逐出是容量策略

Sun, 26 Dec 2027 00:00:00 +0000

过期与逐出都可能让一次成功查找变成未命中，但它们回答的是不同问题。过期服从键的截止时间，逐出则在内存压力下移除符合条件的键。延长 TTL 不能阻止容量驱动的逐出，扩大内存也不能纠正应用写错的截止时间。必须先确定实际发生了哪种变化，才能判断应该检查写入协议、调整容量，还是重新设计缓存用途。

时间与容量是两个独立维度

带有过期设置的键在 Redis 中称为 volatile。Redis 会在访问和主动清理过程中检查过期键，但这不承诺键一定存活到截止时间。显式删除、替换以及适用的逐出策略，都可能提前改变结果。因此，不管最初设定的期限还有多久，缓存客户端都必须能处理未命中，不能把较长 TTL 当作某条数据不会丢失的保证。

maxmemory 是 Redis 进行内存管理决策时使用的统计上限，不是操作系统 RSS 的硬上限。复制与追加日志缓冲区可能包含不计入逐出判断的内存，进程开销、分配器行为和持久化任务也需要容量余量。大型命令还可能短暂超过配置值。规划时既要考虑缓存预算，也要考虑运行整个进程的环境，不能把两者设成同一个数字就认为足够。

先确定候选范围，再讨论排序

allkeys 类策略不管键有没有 TTL，都会把它纳入候选；volatile 类策略则只考虑带过期设置的键。在各自候选范围内，LRU 偏向最久未访问的键，LFU 使用访问频率信息，random 类策略随机选择。Redis 的 LRU、LFU 是近似算法，不保证全局精确的受害键顺序。volatile-ttl 偏向剩余寿命较短的条目，也不是只清除已经到期的数据。

noeviction 在无法满足内存限制时拒绝增长内存的命令，而不是为了腾空间丢键；已有数据仍可能正常读取。但它不是持久性保证，普通过期、显式删除、进程故障和持久化配置仍然分别起作用。应检查当前实例实际配置，不能根据某种部署形式或集群名称，推断所有环境都使用相同默认策略。

volatile 策略如果找不到带 TTL 的候选键，在这种场景下就表现得像 noeviction。选了 volatile-lru，不会自动把持久键变成可丢弃数据。反过来，把会话或权威记录与可重建缓存混放在 allkeys 策略之下，它们也会成为候选。键名前缀只是命名约定，不会给逐出算法建立独立的数据保护边界。

坏掉的样子

未命中突然增加，可能来自过期、逐出、主动失效或键构造变化。需要把 expired_keys、evicted_keys 的增量，与同期请求负载和写命令结果一起看。这些是累计计数，应比较有限时间区间，并考虑重启或重置；仅看到逐出数上升，还不能知道哪个应用功能失去了哪些数据。

除了读取，也要监控被拒绝的写入。热缓存可能继续返回看似合理的值，而写入方已经不断收到内存错误。忽略这些错误，会把容量问题变成应用一致性缺陷。此时延长 TTL 可能只会让旧值保留更久，却不能恢复替换能力；重试策略也不能把内存压力进一步放大成无上限的请求风暴。

将权威状态和可丢弃缓存分开，是架构选择，不是事故中可以直接执行的数据迁移命令。改变现有实例策略之前，应确认可恢复性、持久化和数据归属。下面的实验只修改自己创建的进程，用三个独立候选策略验证行为，不切换生产实例的配置，也不操作现有键空间。

快速验证

准备 POSIX 环境、C 编译器、make、curl、tar 与 Python 3.10 或更新版本。本次在 macOS 上使用 Python 3.14.4、Redis 8.10.1 和 redis-py 8.1.0。使用 libc 编译 Redis 核心，在临时虚拟环境安装固定客户端；源码与依赖下载需要联网，不进行系统级安装，也不编译附带的可选模块。

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

使用 "$redis_lab/venv/bin/python" 执行 Python 代码。每种策略都创建自己的 Unix socket、空数据集和进程，并关闭 TCP 及持久化。内存限制设置为测得的初始分配量再加两个 MiB，有限次写入使用六十四 KiB 的值，启用 TTL 的分支统一设置一小时。结束时关闭每个实验进程，仅清理自己的临时运行目录。

from contextlib import contextmanager
import os
from pathlib import Path
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance(policy="noeviction"):
 with TemporaryDirectory(prefix="redis-lab-", dir="/tmp") as directory:
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--save", "", "--appendonly", "no", "--dir", directory,
 "--maxmemory-policy", policy,
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=True,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode == 0, errors.decode()


for policy, expiring in [("allkeys-lru", True), ("noeviction", True),
 ("volatile-lru", False)]:
 with instance(policy) as client:
 baseline = client.info("memory")["used_memory"]
 client.config_set("maxmemory", baseline + 2 * 1024 * 1024)
 payload = "x" * 65536
 written, rejected = 0, False
 for index in range(128):
 try:
 client.set(f"item:{index}", payload, ex=3600 if expiring else None)
 except redis.exceptions.OutOfMemoryError:
 rejected = True
 break
 written += 1
 stats = client.info("stats")
 remaining = client.dbsize()
 assert stats["expired_keys"] == 0
 if policy == "allkeys-lru":
 assert written == 128 and not rejected
 assert stats["evicted_keys"] > 0 and remaining < written
 assert client.ttl("item:127") > 0
 else:
 assert rejected and 0 < written < 128
 assert stats["evicted_keys"] == 0 and remaining == written
 assert client.get("item:0") == payload
 if not expiring:
 assert client.ttl("item:0") == -1
 print(policy, {"written": written, "remaining": remaining,
 "evicted": stats["evicted_keys"],
 "expired": stats["expired_keys"], "rejected": rejected})

本次 allkeys-lru 接受一百二十八次写入，留下二十三个键，报告一百零五次逐出和零次过期；最新保留键仍有正的 TTL。这说明丢失发生在期限到来之前，原因是容量逐出，但不把这次观察夸大成对精确 LRU 受害顺序的证明，也不要求另一台机器得到相同的键数。

noeviction 接受二十三次写入后拒绝下一次分配，原有键仍能读取，逐出计数保持为零。没有任何带期限键的 volatile-lru 也出现同类拒绝。实际数量受分配开销和构建影响，因此断言检查的是关系，不是强制匹配这组数字。它不是吞吐基准，也不覆盖复制、故障切换、持久化峰值或操作系统级内存限制。

来源

Redis 键逐出，maxmemory 统计、候选策略与近似排序，已核验 2026-09-08。
Redis EXPIRE，键级截止时间及过期行为，已核验 2026-09-08。
Redis INFO，内存统计及逐出、过期计数，已核验 2026-09-08。
Redis 8.10.1 编译说明，独立核心构建与分配器选择，已核验 2026-09-08。

Cache-Control 是缓存与源站之间的约定

Mon, 20 Dec 2027 00:00:00 +0000

缓存策略需要行为测试，而不只是检查头部是否存在。两个响应即使都带 max-age，也可能因为其中一个要求验证、另一个禁止存储而表现不同。请求本身同样影响结果：浏览器可以绕过已有副本，却不修改源站的响应策略，也不删除更早保存的缓存条目。要知道用户真正拿到什么，必须观察完整的重复请求过程。

双方都要读同一份约定

Cache-Control 指令具有方向性。请求指令不会自动复制到响应里，RFC 9111 还明确将请求指令描述为建议性的要求；响应指令则约束遵守协议的缓存。中间层即使自己不实现缓存，也必须在转发中保留相应缓存指令。部署配置可能另有覆盖规则，但“代理按自己的配置做了”不等于已经证明源站声明的策略得到执行。

应拆开三个问题：这条响应能否存储，当前年龄是否仍在适用的新鲜度寿命内，这次请求是否允许不经验证直接复用。这里的 no-store 禁止 HTTP 缓存存储；不带字段名限定的 no-cache 允许存储，但复用前必须成功验证。示例不包含能够在特定条件下覆盖 no-store 的 must-understand 组合，不能据此推导所有指令组合的行为。max-age 设定新鲜度，must-revalidate 则禁止响应过期后未经验证就复用。响应仍然新鲜时，must-revalidate 本身并不要求每次回源，不能把它误解成 no-cache。

不带字段名限定的 private 将存储限制到单用户缓存，public 在其他条件允许时明确授予缓存许可，并不是每一条可缓存响应都必须写 public。s-maxage 覆盖共享缓存的新鲜度，并要求过期之后先验证再复用；它不适用于浏览器私有缓存。Vary 则提供请求匹配维度。这些机制都不会识别应用当前登录的是哪个账户，也不会因为有效期很短，就自动让个人数据变得适合共享。

坏掉的样子

测试时每次添加新的查询参数，会改变缓存键，可能完全掩盖原本的复用行为。在开发者工具中禁用缓存，也可能造成相同误判；某些自动化请求拦截机制同样会禁用 HTTP 缓存。有效测试应在一个隔离上下文中重复访问完全相同的网址，一边统计源站实际收到的请求，一边断言返回正文，而不是仅凭页面看起来没变化就判断命中。

Fetch 的 cache 选项属于浏览器接口，不是响应头。它的 no-store 模式跳过缓存查找，也不把新响应写回 HTTP 缓存；reload 跳过查找，但可以更新缓存。两者都不等于抹除全部旧副本。源站修改响应头，也不能迫使尚未过期的条目立刻回源。浏览器历史恢复、Service Worker 自行保存的内容又是其他机制，不属于下面实验的覆盖范围。

no-cache 也不保证获得 304。只有存在合适的验证器，并且所选表示仍然有效，才有机会节省正文传输。没有 ETag 或 Last-Modified 时，每次访问可能仍返回完整的 200 响应。因此要同时测量回源次数和传输正文，不能看到“每次都请求了源站”就认为重验证一定已经发挥性能收益。

快速验证

作者记录过一次 macOS 上使用 Node 26.0.0、Playwright 1.63.0 及其配套 Chromium 153.0.8010.12 无头浏览器的验证；本轮审阅没有重跑这项浏览器实验。将依赖装入临时目录；Linux 还需具备 Playwright 文档要求的浏览器系统依赖。下载需要联网。使用 NODE_PATH="$cache_browser_lab/node_modules" PLAYWRIGHT_BROWSERS_PATH="$cache_browser_lab/browsers" node 执行 JavaScript，测试请求只访问自动分配的回环端口，不使用现有浏览器配置。

cache_browser_lab=$(mktemp -d)
npm install --prefix "$cache_browser_lab" --ignore-scripts --no-audit --no-fund --package-lock=false playwright@1.63.0
PLAYWRIGHT_BROWSERS_PATH="$cache_browser_lab/browsers" node "$cache_browser_lab/node_modules/playwright/cli.js" install chromium --only-shell --no-remove

const assert = require("node:assert/strict");
const http = require("node:http");
const { once } = require("node:events");
const { chromium } = require("playwright");

const policies = new Map([
 ["/fresh", "max-age=3600"],
 ["/must", "max-age=3600, must-revalidate"],
 ["/validate", "no-cache, max-age=3600"],
 ["/discard", "no-store, max-age=3600"],
]);
const hits = new Map();
const server = http.createServer((request, response) => {
 const route = new URL(request.url, "http://127.0.0.1").pathname;
 if (route === "/") {
 response.writeHead(200, { "Content-Type": "text/html", "Cache-Control": "no-store" });
 response.end("<!doctype html><title>Cache experiment</title>");
 } else if (policies.has(route)) {
 const count = (hits.get(route) || 0) + 1;
 hits.set(route, count);
 response.writeHead(200, {
 "Content-Type": "text/plain", "Cache-Control": policies.get(route),
 });
 response.end(`${route}:${count}`);
 } else {
 response.writeHead(404, { "Cache-Control": "no-store" });
 response.end();
 }
});

async function main() {
 server.listen(0, "127.0.0.1");
 await once(server, "listening");
 let browser;
 try {
 browser = await chromium.launch();
 console.log("Chromium", browser.version());
 const context = await browser.newContext({ serviceWorkers: "block" });
 try {
 const page = await context.newPage();
 await page.goto(`http://127.0.0.1:${server.address().port}/`);
 const read = (route, cache = "default") => page.evaluate(async ({ route, cache }) => {
 const response = await fetch(route, { cache });
 if (!response.ok) throw new Error(`HTTP ${response.status}`);
 return response.text();
 }, { route, cache });
 for (const [route, expectedHits] of [
 ["/fresh", 1], ["/must", 1], ["/validate", 2], ["/discard", 2],
 ]) {
 const first = await read(route);
 const second = await read(route);
 assert.equal(first, `${route}:1`);
 assert.equal(second, `${route}:${expectedHits}`);
 assert.equal(hits.get(route), expectedHits);
 console.log(route, "origin requests:", hits.get(route));
 }
 assert.equal(await read("/fresh", "no-store"), "/fresh:2");
 assert.equal(await read("/fresh"), "/fresh:1");
 assert.equal(hits.get("/fresh"), 2);
 assert.equal(await read("/fresh", "reload"), "/fresh:3");
 assert.equal(await read("/fresh"), "/fresh:3");
 assert.equal(hits.get("/fresh"), 3);
 console.log("no-store bypass retained version 1; reload stored version 3");
 } finally {
 await context.close();
 }
 } finally {
 if (browser) await browser.close();
 await new Promise((resolve, reject) => server.close(error => error ? reject(error) : resolve()));
 }
}

main().catch(error => { console.error(error); process.exitCode = 1; });

最初四条路由的回源次数依次为一、一、二、二。两个新鲜策略都复用第一次拿到的正文；no-cache 与 no-store 即使搭配很长的 max-age，也会再次访问源站。这里有意不提供验证器，所以回源返回的是完整正文。仅凭这些次数，不能区分 no-cache 和 no-store 的存储资格，实验也没有做出这种推断。

后续 no-store 模式取得版本二，但紧接着的普通请求仍返回先前缓存的版本一。reload 模式取得并保存版本三，下一次普通请求便复用版本三。源站计数器证明这些确实是缓存决策，不是两次响应字符串碰巧相同。最后关闭服务器和隔离浏览器上下文，不改变日常使用的浏览器状态。

这些观察只覆盖这个 Chromium HTTP 缓存和列出的请求，没有验证共享 CDN、重启后的持久化、陈旧响应或账户隔离。它们需要各自的验收。局部实验的价值在于明确客户端实际执行了什么，而不是把一次可复现的本地结果延伸成整条生产交付链都正确的结论。

来源

RFC 9111：Cache-Control，指令方向性及存储、复用要求，已核验 2026-09-07。
MDN：Request.cache，default、no-store 和 reload 行为，已核验 2026-09-07。
Playwright 浏览器上下文，隔离且非持久化的上下文，已核验 2026-09-07。
Playwright 浏览器安装，配套无头浏览器与系统依赖，已核验 2026-09-07。
Fetch 标准：缓存模式，no-store 绕过缓存与 reload 更新缓存的区别，已核验 2026-10-15。

布隆过滤器能廉价地说一句“也许”

Wed, 15 Dec 2027 00:00:00 +0000

布隆过滤器能廉价地排除某个元素属于它所表示的集合，而肯定答案只能解释为“可能存在”。这种不对称依赖更新正确、哈希规则保持一致。对于已经插入的元素，普通只增不减算法没有假阴性；但过时或损坏的过滤器仍可能把数据库里真实存在的键判断成不存在，不能把算法性质无限扩大成应用保证。

位图保存的是候选线索，不是记录

先准备一张包含 m 个零位的位图，并为每个键计算 k 个哈希位置。插入时将这些位置全部置一；查询时，只要任意所需位置为零，就返回否定，否则返回“也许”。不同键可能共用位置，所以全部位置都是一，并不能证明查询的键真的被插入过。

再次插入同一个键，不会改变已经置好的位。过滤器没有保存原始键和值，也不能枚举原集合。如果误判会影响正确性，精确集合或数据库仍然是权威答案；不能仅凭“也许存在”就授予权限、扣款，或者丢弃必须处理的工作。少一次查询的收益不能替代业务判断。

按预计元素规模分配空间

在哈希近似均匀且相互独立的常用模型下，插入 n 个不同元素后的假阳性概率近似为 p = (1 − exp(−kn/m))^k。固定 m 和 n 时，k 接近 (m/n) ln(2) 可以使这个近似值最小。哈希次数并不是越多越好：除了增加计算，它也会更快地把位图填满。

选择合适的哈希数量后，百分之一的误判目标大约需要每个元素九点六位，尚未计算实现开销。一千万个元素因此需要大约一千二百万字节的位图，并不是几百万个位就够用。讨论空间时必须区分位、字节、位图本体以及整个进程的内存，避免把不同口径混在一起。

假阳性率针对的是确定不存在的元素查询，不是所有肯定答案中错误答案所占的比例；后者还取决于调用方有多大概率查询真实存在的元素。应使用已知非成员测量，并将有限样本的观察值与概率模型区分开来，不能看到一次误判较少就宣称达到了严格概率保证。

让表示的集合跟上权威数据

如果准备根据否定答案跳过数据库查询，过滤器就必须包含所有相关数据库插入。先发布新行、稍后才更新过滤器，会产生可见性缺口。重建过程也需要定义快照和增量更新如何交接；过滤器的一次查询成功，并不能证明应用层这些步骤已经原子完成。

写入方和读取方还必须保持位数、哈希构造、种子或域前缀以及字节编码一致。改变这些输入就会改变位置。普通布隆过滤器不能通过清除某个元素对应的位来安全删除，因为其他元素可能依赖同一位；计数型或其他支持删除的结构，使用的是不同契约，不能把接口混为一谈。

坏掉的样子

向固定大小的位图插入过多元素，会提高假阳性率，逐渐失去减少昂贵查询的收益。正确插入的元素仍不会被误判为不存在，但查询越来越难得到否定答案。扩大固定过滤器需要重建或采用相应增长设计，不能只修改取模用的位数，否则已有位的位置含义就变了。

真实产品不一定像下面的固定大小模型。Redis 的 BF.RESERVE 在允许扩展时可以增加子过滤器，禁止扩展时则在达到容量后拒绝插入。子过滤器会增加内存和查询工作；应检查实际配置与实现，不能假定产品会像没有容量检查的插入循环一样静默变得饱和。

更新丢失、编码不一致、快照落后和错误删除，都可能破坏应用期望的否定答案安全性。除了观察假阳性，还要记录插入失败与过滤器新鲜度。过滤器是一项优化，它的维护仍属于数据生命周期的一部分，不是创建一次之后就可以忽略的永久索引。

快速验证

保存为 bloom_check.py，用 Python 3.10 以上版本执行 python3 bloom_check.py。实验已在 Python 3.14.4 上运行，仅用标准库。七个带域前缀的 SHA-256 摘要、明确的 UTF-8 编码和固定键序列保证测试可重现，不需要外部服务、网络访问或文件写入。

from hashlib import sha256
from math import exp


M, K, N = 10000, 7, 1000


def offsets(value):
 data = value.encode("utf-8")
 return tuple(int.from_bytes(sha256(index.to_bytes(2, "big") + data).digest(), "big") % M
 for index in range(K))


def add(bits, value):
 for position in offsets(value):
 bits[position // 8] |= 1 << (position % 8)


def maybe(bits, value):
 return all(bits[position // 8] & (1 << (position % 8)) for position in offsets(value))


bits = bytearray((M + 7) // 8)
inserted = [f"item:{index}" for index in range(N)]
truth = set(inserted)
for value in inserted:
 add(bits, value)
assert all(maybe(bits, value) for value in inserted)
before = bytes(bits)
add(bits, inserted[0])
assert bytes(bits) == before

absent = [f"absent:{index}" for index in range(10000)]
assert truth.isdisjoint(absent)
false_positives = [value for value in absent if maybe(bits, value)]
assert 0 < len(false_positives) < len(absent)
estimate = (1 - exp(-K * N / M)) ** K
print(f"{N} inserted; bitmap={len(bits)} bytes; estimate={estimate:.4%}")
print(f"absent probes: {len(false_positives)}/{len(absent)} false positives")
assert false_positives[0] not in truth
print("a maybe still needs exact lookup:", false_positives[0])

victim = inserted[0]
victim_offsets = set(offsets(victim))
retained = next(value for value in inserted[1:] if victim_offsets.intersection(offsets(value)))
broken = bytearray(bits)
for position in victim_offsets:
 broken[position // 8] &= ~(1 << (position % 8))
assert retained in truth and maybe(bits, retained) and not maybe(broken, retained)
print("clearing bits for", victim, "incorrectly rejects retained", retained)

new_value = next(f"new:{index}" for index in range(1000) if not maybe(bits, f"new:{index}"))
truth.add(new_value)
assert new_value in truth and not maybe(bits, new_value)
add(bits, new_value)
assert maybe(bits, new_value)
print("an origin insertion is invisible until the filter is also updated")

# Use a separate fixed bitmap so the capacity experiment has exactly 5000 items.
overfull = bytearray((M + 7) // 8)
for index in range(5000):
 add(overfull, f"item:{index}")
overfull_positives = sum(maybe(overfull, value) for value in absent)
assert overfull_positives > len(false_positives)
assert all(maybe(overfull, f"item:{index}") for index in range(5000))
print(f"5000 inserted in the same bit budget: {overfull_positives}/{len(absent)} false positives")

一万位的位图本体占用一千二百五十字节。插入一千个元素后，所有已插入元素均返回肯定，重复插入不改变位图；一万个已知不存在的查询中，有七十三个返回“也许”。公式近似值约为百分之零点八一九四，本次有限样本的观察值为百分之零点七三，二者不要求逐位相等。

清除 item:0 对应的位，会错误拒绝仍然保留的 item:79。新加入权威集合的元素在更新过滤器之前也不可见。另一张同样大小的位图插入五千个元素后，对同一组不存在查询产生八千零一十六次假阳性，同时仍识别所有已经插入的元素；这展示了固定空间被过度使用的代价。

这些断言将算法允许的假阳性，与维护错误引入的假阴性分开验证。实验没有测量生产内存开销，没有测试并发更新、序列化兼容性，也没有执行 Redis 的布隆过滤器命令。不能从这段标准库模型推断某个服务的实际容量、时延或故障恢复保证。

来源

Redis 布隆过滤器，概率成员查询与后续权威查询，已核验 2026-09-08。
Redis BF.RESERVE，空间公式、容量与扩展行为，已核验 2026-09-08。
Python hashlib，确定性的 SHA-256 摘要构造，已核验 2026-09-08。

缓存的新鲜度要对着时钟判断

Fri, 03 Dec 2027 00:00:00 +0000

响应经过另一个缓存，不代表自动获得一份全新的新鲜度额度。缓存必须计入交付路径上已经积累的年龄，再增加自己的本地停留时间。否则，每一层看起来都只缓存六十秒，串在一起却可能把旧内容直接复用远超源站预期的时间。判断新鲜度需要明确时间来源，不能只把配置中的秒数当成最终交付保证。

先算清年龄

Age 估计从响应生成或成功验证以来经过的秒数，其中包括缓存停留与网络传输。收到的 Age 是计算当前年龄的输入，不是在本地存放期间保持不变的计数器。Date 提供响应生成时间；把这些信息联系起来时，时钟同步和实际测得的请求、响应时刻都可能影响结果。只截取一组响应头，不能看到它随后在缓存里又停留了多久。

RFC 9111 给出两条年龄估计路径：接收时刻减去 Date，负数归零，得到表观年龄；收到的 Age 加响应延迟，得到校正年龄值。保守算法取两者较大值，再加本地停留时间。例如请求时刻为一百秒，接收为一百零二秒，Date 为九十五秒，收到的 Age 为十秒，当前时刻为一百零七秒，表观年龄是七秒，校正值是十二秒，当前年龄最终为十七秒。只读原始 Age 就漏算了七秒。

新鲜度寿命也有优先顺序。共享缓存存在 s-maxage 时先用它，否则 max-age 优先于 Expires 减 Date；私有缓存忽略 s-maxage。没有显式过期信息时，在允许的条件下可能使用启发式寿命，但并不存在统一固定时长。只有适用的新鲜度寿命严格大于当前年龄，响应才是新鲜的；恰好相等时已经到达陈旧边界，而不是再多送一次的许可。

坏掉的样子

新鲜不代表适合任意请求。存储许可、网址与 Vary 匹配、验证要求仍然有效。即使寿命设得很长，no-cache 也要求复用前验证。ETag 是验证器，不是免于询问源站的许可。成功重验证可以更新保存的元数据而不重新传正文，但仅仅从另一个缓存收到响应，不能把年龄清零，否则每经过一层就会错误地延长直接复用期限。

提供陈旧响应需要另外的许可，不能把源站故障当成自动授权。must-revalidate 禁止过期后未经成功验证就复用，即使网络断开也不例外。stale-while-revalidate 可以允许在有界的陈旧窗口内一边返回旧内容、一边验证，但仍受适用限制约束，也不会把旧内容重新变成新鲜内容。RFC 9111 已废弃 Warning 字段，因此没有旧式 Warning: 110 不能作为新鲜度证据。

还要区分“存储保留多久”和“直接复用多久”。过期后保留正文，可能有助于重验证或受许可的陈旧窗口，所以缓存后端的淘汰期限可能长于新鲜度寿命。如果调用方直接把这个存储期限当成可返回旧内容的许可，就可能越过响应策略。缓存键仍存在和这次请求可以命中不是一回事，必须检查实际的复用决策。

快速验证

准备 Node.js 与 npm，本次实际使用 Node 26.0.0 和 http-cache-semantics 4.2.0。安装后用 NODE_PATH="$freshness_lab/node_modules" node 执行 JavaScript。程序覆盖的是库内测试时钟，不修改系统时间；输入是虚构元数据，没有网络请求，也不用等待真实时间流逝。只有依赖安装需要联网。

freshness_lab=$(mktemp -d)
npm install --prefix "$freshness_lab" --ignore-scripts --no-audit --no-fund --package-lock=false http-cache-semantics@4.2.0

const assert = require("node:assert/strict");
const CachePolicy = require("http-cache-semantics");

const start = Date.parse("2026-09-07T00:00:00Z");
let clock = start;
class TestPolicy extends CachePolicy {
 now() { return clock; }
}
const request = { url: "https://example.test/news", method: "GET", headers: {} };
const headers = {
 date: new Date(start).toUTCString(),
 age: "20",
 expires: new Date(start + 3600000).toUTCString(),
 "cache-control": "public, max-age=60, s-maxage=30",
};
const shared = new TestPolicy(request, { headers }, { shared: true });
const single = new TestPolicy(request, { headers }, { shared: false });
assert.equal(shared.maxAge(), 30);
assert.equal(single.maxAge(), 60);
for (const [elapsed, sharedHit, privateHit] of [
 [0, true, true], [9, true, true], [10, false, true], [40, false, false],
]) {
 clock = start + elapsed * 1000;
 assert.equal(shared.age(), 20 + elapsed);
 assert.equal(shared.responseHeaders().age, String(20 + elapsed));
 assert.equal(shared.satisfiesWithoutRevalidation(request), sharedHit);
 assert.equal(single.satisfiesWithoutRevalidation(request), privateHit);
 console.log("elapsed:", elapsed, "age:", shared.age(), "reuse:", sharedHit, privateHit);
}

clock = start;
const background = new TestPolicy(request, { headers: {
 age: "20", "cache-control": "public, max-age=30, stale-while-revalidate=20",
} });
clock += 15000;
const decision = background.evaluateRequest(request);
assert.equal(background.timeToLive(), 15000);
assert.equal(background.satisfiesWithoutRevalidation(request), false);
assert(decision.response);
assert.equal(decision.revalidation.synchronous, false);
console.log("stale window: retain 15000 ms, serve and revalidate");
clock += 15000;
assert.equal(background.evaluateRequest(request).response, undefined);
assert.equal(background.evaluateRequest(request).revalidation.synchronous, true);

clock = start;
const oldDate = new TestPolicy(request, { headers: {
 date: new Date(start - 3600000).toUTCString(),
 "cache-control": "public, max-age=60",
} });
assert.equal(oldDate.age(), 0);
assert.equal(oldDate.satisfiesWithoutRevalidation(request), true);
console.log("library limitation: old Date alone does not increase age");

经过零、九、十和四十秒后，计算出的年龄依次是二十、二十九、三十和六十秒。两种模式最初都允许复用；共享模式恰好在三十秒年龄处停止，私有模式到六十秒停止。未来的 Expires 不会覆盖显式寿命。程序同时检查向下游返回的 Age，而不是只断言一个命中布尔值，避免把年龄传播这一半遗漏掉。

独立的陈旧窗口案例达到三十五秒年龄，即超过新鲜期五秒。剩余保留时间是一万五千毫秒，但验证仍然必要。库允许返回缓存响应，同时给出异步重验证决策；它自己不会执行那次网络请求。到五十秒年龄时，窗口许可结束，必须先同步验证。这个结果直接说明后端还能保留条目，不代表可以不经判断地直接使用它。

最后一项有意暴露实现限制：这个库计算年龄时刻意忽略服务器 Date，所以只有一个小时前的 Date、没有 Age 的响应，仍从零开始计龄。它采用收到的 Age 加本地停留时间，不计算实际响应延迟，也不执行上文保守算法中的表观年龄分支。因此，这些断言证明的是固定版本的决策行为，不是完整的 RFC 年龄算法一致性。实际中间层的时序和字段传播仍要另行验证，不能把库测试的通过误写成整条交付链的证明。

来源

RFC 9111：新鲜度，寿命优先级、当前年龄与陈旧响应限制，已核验 2026-09-07。
MDN：Cache-Control，新鲜度与 stale-while-revalidate 指令，已核验 2026-09-07。
http-cache-semantics 4.2.0，保留期限、重验证决策及文档明确说明的 Date 限制，已核验 2026-09-07。

缓存集中失效会放大回源工作

Mon, 22 Nov 2027 00:00:00 +0000

缓存雪崩或击穿所造成的一个关键风险，是并发未命中对同一依赖发起大量重复工作。同时到期只是触发条件之一：容量淘汰、刚部署的空缓存、缓存服务不可用，都可能造成类似突发。即使只有一把热门键，也足以压垮后端。判断风险时应数清楚：一份结果尚未计算完的这段时间内，到底有多少次重建真正抵达数据源。

在真实边界内合并工作

Go 的 singleflight Group 对同一键，在这个 Group 内最多保持一次在途函数执行；重复调用者共享结果，也共享错误。不同 Group 之间不会协调，即使它们位于同一个进程；不同服务实例通常也各有自己的 Group。因此它既不是分布式锁，也不是保存已完成结果的缓存。把 Group 放在每个请求内部重新创建，无法实现跨请求合并。

实际使用时，应让请求共享同一个 Group，并使键准确表示等价工作。不同租户、权限、币种或响应表示如果错误地使用同一个键，可能拿到不属于自己的结果。对于缓存回填，在共享函数内部应再次检查缓存，确实仍缺失才访问数据源，并在函数返回前完成成功结果的缓存写入。这些存储操作都不是 singleflight 自动提供的能力。

错开时间不能改变新鲜度承诺

随机抖动可以打散不同条目或独立副本的到期时间，却不能阻止访问同一过期热键的人一起未命中。如果最大 TTL 是业务规定的新鲜度上限，在有界范围内随机缩短寿命，不会偷偷越过这个上限；任意增加正向抖动则改变了原有承诺。不能脱离请求量、计算成本和允许陈旧程度，宣称几个百分点或几秒钟就普遍足够。

提前刷新和允许使用旧响应，有机会避免用户等待，但必须有明确业务语义。暂时展示上一版公开目录可能可接受，已经撤销的权限或当前余额则未必可以。并发合并只减少重复计算，不负责判断陈旧内容能否使用；如果缓存完全是空的，系统仍需要取得一份数据源结果，不能把后台刷新当作无条件的可用性保证。

坏掉的样子

共享加载函数一旦卡住，可能同时拖住很多等待者。要为数据源调用设置执行期限，也让每个调用者能限制自己的等待时间。DoChan 返回的是结果通道，不是取消机制：某个等待者离开，不会自动停止底层执行。Forget 允许同一键重新启动一次执行，但并不取消原有执行，用它解除等待可能重新制造两次并行加载。

错误只在本次执行仍处于在途状态时共享。执行结束后立刻重试，会向故障依赖发起一轮又一轮新请求。应根据依赖的实际约束设置重试与准入策略，对可以缓存的“不存在”和瞬时失败分别处理。另一个常见误判是把进程内的数字推广到全局：一百个各有 Group 的实例，仍可能同时产生一百次重建，本地只执行一次不等于源站只收到一次。

快速验证

需要 Go 1.25 或更新版本；本次使用 Go 1.27.0 和 x/sync v0.22.0。在下面创建的独立模块目录中，将 Go 代码放入 main.go，再运行 go run -race main.go。只有依赖安装需要外网。程序从“已经发生冷缓存未命中”的边界开始，用有计数器的加载函数观察行为，没有连接真实数据库、缓存服务，也没有实现 TTL 定时器。

stampede_lab=$(mktemp -d)
cd "$stampede_lab"
go mod init example.invalid/stampede-lab
go get golang.org/x/sync@v0.22.0

package main

import (
 "errors"
 "fmt"
 "sync"
 "sync/atomic"

 "golang.org/x/sync/singleflight"
)

const callers = 12

func require(ok bool) {
 if !ok {
 panic("unexpected result")
 }
}

func wave(groups []*singleflight.Group, failure error) int32 {
 var calls atomic.Int32
 gate := make(chan struct{})
 results := make([]<-chan singleflight.Result, callers)
 load := func() (any, error) {
 calls.Add(1)
 <-gate
 if failure != nil {
 return nil, failure
 }
 return "catalog-v1", nil
 }
 for i := range results {
 results[i] = groups[i%len(groups)].DoChan("catalog", load)
 }
 close(gate)
 for _, result := range results {
 r := <-result
 require(r.Shared && r.Err == failure)
 if failure == nil {
 require(r.Val == "catalog-v1")
 } else {
 require(r.Val == nil)
 }
 }
 return calls.Load()
}

func main() {
 var plain atomic.Int32
 var workers sync.WaitGroup
 gate := make(chan struct{})
 for range callers {
 workers.Add(1)
 go func() {
 defer workers.Done()
 plain.Add(1)
 <-gate
 }()
 }
 close(gate)
 workers.Wait()
 require(plain.Load() == callers)
 fmt.Println("without coalescing: 12 loader calls")

 group := new(singleflight.Group)
 require(wave([]*singleflight.Group{group}, nil) == 1)
 require(wave([]*singleflight.Group{group}, nil) == 1)
 fmt.Println("one Group: 1 call per wave; completed results are not cached")
 other := new(singleflight.Group)
 require(wave([]*singleflight.Group{group, other}, nil) == 2)
 fmt.Println("two independent Groups: 2 loader calls")

 failure := errors.New("origin unavailable")
 require(wave([]*singleflight.Group{group}, failure) == 1)
 require(wave([]*singleflight.Group{group}, nil) == 1)
 fmt.Println("one error reaches 12 callers; next wave starts a new load")
}

未合并的基线执行十二次加载。所有调用加入同一个 Group 时，每一轮只执行一次；在同一个 Group 上再运行第二轮，仍会新增一次执行，说明完成结果并未被保存。把十二名调用者分给两个独立 Group，就得到两次加载。故障轮次让十二名调用者收到同一个错误，随后成功的轮次仍会重新加载，而不是读取已缓存的错误结果。

实验用通道闸门让共享加载保持在途，直到所有 DoChan 调用完成注册才放行，因此无需靠睡眠长度或碰巧的调度顺序制造重叠。这里同一轮的所有结果都会标记 Shared 为真，包括最初发起者收到的结果。每个结果通道只接收一次即可；DoChan 不会关闭这些通道，如果对它执行 range 并等待结束，程序就会一直等待。

验收真实服务时，应在隔离环境安排冷缓存测试，同时记录加载次数、等待人数、请求延迟和失败数。验证范围需要包括多个实例和数据源超时，不能只看正常运行时漂亮的缓存命中率。这次 race 检查证明的是此程序在观察到的执行中没有报告数据竞争，并不覆盖生产缓存所有交错顺序，更不代表全局容量、超时及恢复策略已经验收。

来源

Go x/sync v0.22.0：singleflight，Group 范围、DoChan、错误共享与 Forget，已核验 2026-09-07。
AWS Builders’ Library：缓存挑战与策略，冷缓存、请求合并、失败行为与基于实测的过期策略，已核验 2026-09-07。

LRU 缓存淘汰最久未用的条目

Fri, 12 Nov 2027 00:00:00 +0000

LRU 按最近使用顺序选择淘汰对象，而不是按历史热度、存放年龄或业务重要程度选择。有界缓存需要腾出空间时，精确的最近最少使用策略会移除最后一次有效访问发生得最早的条目。它利用的是时间局部性，既不保证命中有价值的数据，也不保证留下来的数据仍然新鲜。

沿访问顺序找出淘汰对象

假设缓存只能存三个条目，并按从旧到新的方向列出。依次加载 A、B、C 后，顺序为 A、B、C；再次读取 A，顺序变成 B、C、A；此时加载 D，就淘汰 B，留下 C、A、D。普通字典即使保留插入顺序，也不会因为某个条目被读取就自动调整它的位置。

实现必须明确哪些操作算作一次访问。常见精确方案把查找表与双向链表结合起来，以较低成本完成查找、移到最近端和从最旧端移除。维护顺序需要额外元数据，也让缓存命中变成状态更新；并发实现还必须协调这些更新，不能把读取缓存理解成永远没有写入开销。

精确顺序与采样近似不是同一契约

Redis 使用近似 LRU：抽取候选并维护较好的淘汰候选池，而不是为每个键保存完整的精确访问顺序。采样数量可以配置，更多采样用额外计算换取更接近精确 LRU 的结果。它不承诺下面小模型的逐个淘汰顺序，也不能由此推导所有淘汰操作都有固定耗时。

候选资格同样重要。Redis 的 allkeys-lru 可以淘汰任意键，volatile-lru 则只考虑带过期信息的键。设置了有效期，并不保证键在截止时间之前不会被淘汰；如果没有符合条件的带过期时间的键，volatile 策略在内存压力处理上会表现得像 noeviction。

容量约束不是新鲜度约束

限制三个条目，不等于限制三千字节。不同键、值和维护结构占用不同空间，按数量限制的缓存仍可能持有很大的对象。Python 的 lru_cache 会持有参数与返回值的引用，直到条目被淘汰或缓存被清空。选择容量单位时，应对应真正需要控制的资源，而不是只看条目数是否稳定。

最近访问也不能说明源数据有没有变化。频繁读取一个过时答案，反而可能让它一直留在缓存中。有效期、显式失效和版本化键分别处理新鲜度问题；淘汰规则既不是一致性协议，也不是备份策略，不能因为缓存命中就跳过业务对数据有效性的判断。

坏掉的样子

一次扫描大量只用一遍的条目，可能挤掉本来有用的工作集。容量为三时循环访问四个不同键，即使这些键都在被反复请求，也可能每次都未命中。LRU 不会因为过去访问次数很多就永久保留一个键。LFU、插入前的准入策略或调整容量可能适合某些负载，但不能仅凭“读多”就自动选出正确方案。

应在有代表性的时间段一起观察命中、未命中、淘汰、保留字节数以及未命中的代价。很高的命中率也可能掩盖少量特别昂贵的回源；单看淘汰数量，不知道被移除的数据是否有价值。修改策略前，先还原实际访问轨迹，再解释缓存为什么做出了这些选择。

缓存命中还必须允许安全复用。带副作用的函数，或每次调用都必须创建独立可变对象的函数，不适合直接做记忆化。Python 的 lru_cache 能保持多线程下内部结构一致，但同时发生的未命中仍可能让被包装函数执行多次。线程安全不等于抑制同一项工作被重复执行。

快速验证

将代码保存为 lru_check.py，用 Python 3.10 以上版本执行 python3 lru_check.py。实验已在 Python 3.14.4 上运行，只使用标准库：OrderedDict 展示精确访问顺序，真正的 functools 装饰器另行验证记忆化行为。不启动 Redis，不发送网络请求，也不写文件。

from collections import OrderedDict
from functools import lru_cache


def access(cache, key, capacity):
 assert capacity > 0
 hit = key in cache
 evicted = None
 if hit:
 cache.move_to_end(key)
 else:
 cache[key] = key.lower()
 if len(cache) > capacity:
 evicted, _ = cache.popitem(last=False)
 return hit, evicted, tuple(cache)


cache = OrderedDict()
observed = [access(cache, key, 3) for key in "ABCAD"]
assert observed == [
 (False, None, ("A",)),
 (False, None, ("A", "B")),
 (False, None, ("A", "B", "C")),
 (True, None, ("B", "C", "A")),
 (False, "B", ("C", "A", "D")),
]
print("ABCAD: touching A makes B the victim; final oldest -> newest:", tuple(cache))

for key in "XYZ":
 access(cache, key, 3)
assert tuple(cache) == ("X", "Y", "Z")
assert access(cache, "A", 3)[0] is False
print("a one-time XYZ scan displaces the old working set")

cache.clear()
hits = sum(access(cache, key, 3)[0] for key in "ABCD" * 3)
assert hits == 0
print("capacity 3, repeated ABCD: 0 hits in 12 accesses")

origin = {"A": 1, "B": 2, "C": 3}
loads = []


@lru_cache(maxsize=2)
def read(key):
 loads.append(key)
 return origin[key]


assert [read(key) for key in "ABACB"] == [1, 2, 1, 3, 2]
assert loads == ["A", "B", "C", "B"]
assert tuple(read.cache_info()) == (1, 4, 2, 2)
print("functools trace:", read.cache_info(), "origin reads:", loads)
origin["B"] = 20
assert read("B") == 2
read.cache_clear()
assert read("B") == 20
assert tuple(read.cache_info()) == (0, 1, 2, 1)
print("a recent cached B stays stale until explicit invalidation")

第一组断言检查每一步的顺序，而不只是最后的容量：读取 A 后，B 成为下一次淘汰对象。随后一次性访问 X、Y、Z，会挤走原工作集；再循环访问 A、B、C、D，容量为三的缓存十二次访问全部未命中。结果说明“这些键经常出现”并不足以保证 LRU 有收益，还取决于它们之间隔了多少其他访问。

装饰器包装的函数读取一份内存中的源数据。A、B、A、C、B 的轨迹得到一次命中、四次未命中和两个保留条目；记录的源读取列表明确指出哪些调用实际重新计算。把源数据 B 从二改为二十后，缓存仍返回二，直到执行 cache_clear 才读到二十；清空操作也会重置统计。

这些是确定性的正确性检查，不是延迟或内存基准。实验没有执行 Redis 采样淘汰、有效期处理、并发未命中、按字节限制容量或生产访问分布。先用轨迹理解规则，再针对真实缓存实现和真实工作负载验证，不能把小模型的结果直接当成生产命中率承诺。

来源

Python functools，LRU 记忆化、统计、对象引用、失效与并发调用边界，已核验 2026-09-08。
Python collections，OrderedDict 重排与端点移除，已核验 2026-09-08。
Redis 键淘汰，近似 LRU、采样与候选资格，已核验 2026-09-08。

一致性哈希减少重新映射

Sun, 19 Sep 2027 00:00:00 +0000

一致性哈希限制成员变化时的数据放置变化，但它本身不搬运数据、不让副本达成一致，也不把单个热键的请求自动分散。经典顺时针哈希环把键交给哈希位置之后遇到的第一个节点点位；如果位置恰好相等，就归该点，超过最大点位则绕回最小点位。理解这个查找方向，是判断迁移范围的前提。

先把归属区间画对

一个点拥有的是前驱之后到自身为止的区间，即 (前驱, 当前点]。假设 A 位于 20，B 位于 50，C 位于 80，那么 B 负责大于 20 且不大于 50 的位置；超过 80 的键绕回 A。这不是从 B 到其后继 C 的弧段，左右端点是否包含也不是可以随意改变的细节。

在 35 加入 D，它从顺时针后继 B 手中取得大于 20 到 35 的位置；移除 B，则将 B 原来负责的区间交给 C。未受影响的点位保持原位置及归属，这才是算法有用的性质。仅说“移动一小段弧”还不够，因为原来某段弧可能就占据整个环的很大一部分。

作为对照，直接用 hash(key) 对节点数量取模来选择数组下标，新增节点会改变除数，很多键随之选到别的下标。四个等容量且平衡的节点扩到五个时，理想哈希环大约需要迁移五分之一的键，但真实迁移比例取决于点位与键分布，不能把这个比例当成所有部署都成立的保证。

虚拟节点分散区间，不拆分单个键

为每台物理节点分配多个环上点位，通常能减轻少量随机点造成的不平衡。每台机器持有多个较小区间，新节点可以从不同邻居取得一部分归属；不同容量还可以通过权重分配不同数量的点。但点越多，路由表的内存和维护工作也会增加，并非只有收益没有成本。

在本文的主归属模型中，一个键仍然只选择一台物理机器。如果绝大部分请求都针对这个键，增加虚拟节点不会让这些请求自动跨机器分担。即使每台机器的键数量接近，也不意味着字节数、请求频率或处理成本接近。复制、读流量分配和热键处理需要另外的策略。

稳定性也不等于平衡。所有参与方需要对成员集合、持久节点身份、键的字节编码、哈希规则和点数达成一致。稳定摘要可以让大家重现位置，却无法弥补成员视图不同或工作负载倾斜。如果每次成员变化都重新生成全部旧节点的点，保持既有归属的性质也就被破坏了。

放置结果不是迁移协议或一致性协议

路由算出了新归属，不代表缓存值或持久数据已经到达新节点。缓存可能经历未命中和源站负载上升，持久存储则需要数据迁移与所有权切换协议。发布期间仍使用旧环和已经使用新环的客户端，可能对同一个键作出不同选择；恢复与同步语义要由外围系统解决。

实际产品还使用不同算法和元数据。Redis Cluster 重新分配固定哈希槽的归属，并不是本文这种直接映射节点点位的环；Cassandra 还叠加副本放置和 token 管理规则，Envoy 则用哈希选择上游服务。不能从一个产品的放置示意图，推导另一个产品的故障安全保证。

坏掉的样子

每台机器只有一个点时可能严重失衡，重命名节点也可能意外迁移其点位。改变字节编码或哈希配置，即使没有任何机器加入，也能让大量键重新分配。应把这些映射输入视为部署配置，并在发布前比较新旧归属，而不是只检查服务进程是否正常运行。

还应把迁移键数、迁移字节数和真实请求流量分开测量。虚拟节点改善的是统计上的放置分布，不保证最大负载上界。成员频繁变化时，应为数据迁移或冷缓存回源预留资源，并检查客户端如何学习新视图。放置计算实验不能代替可用性与数据完整性验收。

快速验证

把以下代码保存为 ring_check.py，使用 Python 3.10 以上版本执行 python3 ring_check.py。本例已用 Python 3.14.4 运行，只依赖标准库，不启动服务，也不进行网络请求或文件写入。固定的 SHA-256 和明确的 UTF-8 输入，让生成的测试数据可以复现。

from bisect import bisect_left
from collections import Counter
from hashlib import sha256


def token(value):
 return int.from_bytes(sha256(value.encode("utf-8")).digest(), "big")


def ring(nodes, copies):
 entries = sorted(
 (token(f"node:{node}:{copy}"), node)
 for node in nodes for copy in range(copies)
 )
 positions, owners = zip(*entries)
 assert len(set(positions)) == len(positions), "fixture token collision"
 return positions, owners


def lookup(layout, position):
 positions, owners = layout
 return owners[bisect_left(positions, position) % len(positions)]


simple = ((20, 50, 80), ("A", "B", "C"))
joined = ((20, 35, 50, 80), ("A", "D", "B", "C"))
removed = ((20, 80), ("A", "C"))
assert [lookup(simple, value) for value in (0, 20, 21, 50, 51, 80, 81)] == [
 "A", "A", "B", "B", "C", "C", "A",
]
for value in range(100):
 assert lookup(joined, value) == ("D" if 20 < value <= 35 else lookup(simple, value))
 assert lookup(removed, value) == ("C" if 20 < value <= 50 else lookup(simple, value))
assert lookup(joined, 35) == "D"
assert lookup(removed, 50) == "C"
print("a point owns (predecessor, point]; lookups wrap clockwise")

nodes = ("A", "B", "C", "D")
positions = [token(f"key:{index}") for index in range(20000)]
base = ring(nodes, 256)
expanded = ring(nodes + ("E",), 256)
contracted = ring(tuple(node for node in nodes if node != "B"), 256)
assert base == ring(tuple(reversed(nodes)), 256)
before = [lookup(base, position) for position in positions]
after_add = [lookup(expanded, position) for position in positions]
after_remove = [lookup(contracted, position) for position in positions]
add_count = sum(old != new for old, new in zip(before, after_add))
remove_count = sum(old != new for old, new in zip(before, after_remove))
assert 0 < add_count < len(positions)
assert add_count == after_add.count("E")
assert all(old == new or new == "E" for old, new in zip(before, after_add))
assert remove_count == before.count("B")
assert all(old == new or old == "B" for old, new in zip(before, after_remove))
modulo_count = sum(
 nodes[position % 4] != (nodes + ("E",))[position % 5]
 for position in positions
)
print(f"add E: {add_count}/20000 keys move ({add_count / 200:.2f}%)")
print(f"remove B: {remove_count}/20000 keys move ({remove_count / 200:.2f}%)")
print(f"modulo 4 -> 5: {modulo_count}/20000 keys move ({modulo_count / 200:.2f}%)")

single = ring(nodes, 1)
for label, layout in (("one point", single), ("256 points", base)):
 counts = Counter(lookup(layout, position) for position in positions)
 print(label, {node: counts[node] for node in nodes})

hot_owner = lookup(base, token("key:hot"))
synthetic_requests = Counter(before)
synthetic_requests[hot_owner] += 100000
assert synthetic_requests[hot_owner] == before.count(hot_owner) + 100000
print("100000 extra requests for one hot key all target", hot_owner)
print("synthetic request counts", dict(sorted(synthetic_requests.items())))

整数例子检查了从零到 99 的每个位置，覆盖区间端点和绕环情况。对 20,000 个确定生成的键，每台节点配置 256 个点时，新增 E 迁移 4,023 个键，移除 B 迁移 4,895 个，而取模方式扩容迁移 16,013 个。断言还要求新增造成的所有迁移都流向 E，删除造成的所有迁移都来自 B，验证的不只是数量看起来变少。

输出中的数量展示了这组数据使用 256 个点后的平衡改善，不是普遍的负载上界。再给一个热键增加 100,000 次合成请求，它们仍全部指向 D。这些是计算出来的归属和需求计数，并非实际发送的生产请求，也没有测量网络搬运字节数或故障恢复时间。

来源

Apache Cassandra 的 Dynamo 架构，顺时针归属、token 区间和虚拟节点，已核验 2026-09-08。
Envoy 负载均衡算法，环哈希、稳定节点身份、权重和分布，已核验 2026-09-08。
Python hashlib，可移植的 SHA-256 摘要构建，已核验 2026-09-08。
Redis Cluster 规范，采用固定槽映射的另一种放置设计，已核验 2026-09-08。

缓存失效是主动推进，不是祈祷

Thu, 05 Aug 2027 00:00:00 +0000

源站文件改了，并不意味着每个已经保存响应的缓存都会收到通知。失效操作控制的是哪些已存副本还可以继续复用，而不只是更新磁盘上的内容。可靠的发布要区分到期、重新验证、定点移除以及使用新 URL：它们解决不同范围的问题，也没有哪一种能远程擦掉读者已经下载的所有字节。

到期不是广播通知

源站发生变化后，一份仍然新鲜的响应可能继续被合法使用。新鲜度由缓存寿命和当前年龄共同决定，年龄计算涉及缓存元数据与经过的时间，并非只从源站的 Date 字段开始倒计时。到期改变的是直接复用时必须满足的条件，既不保证存储介质立即删除条目，也不会让无人访问的缓存主动联系源站。

验证器同样不是内容变化的推送通道。请求需要重新验证时，正确的 ETag 才能帮助源站确认表示未变，或者返回替代正文。浏览器手上的响应还新鲜、没有理由回源时，新增验证器并不能强迫它询问。把源站策略改成 no-cache 或 no-store，也无法追溯修改浏览器之前已经收到的缓存指令。

先确定失效覆盖范围

RFC 9111 要求：缓存收到不安全方法对应的成功或重定向响应时，必须使目标 URI 的已存响应失效。这个义务只涉及该请求实际经过的缓存，不是向整个网络广播。通过另一条接口修改数据库，不会自动覆盖所有派生页面、查询参数变体、不同语言表示和搜索列表，应用需要识别这些真实依赖。

CDN 的清理接口也只管理服务商控制的副本，无法直接清空独立浏览器缓存。应按服务商的实际契约确认受影响的主机、路径、变体以及缓存标签。先让替代内容在源站可用，再发起清理、跟踪完成状态，并比较实际响应正文和缓存状态。接口已经接受清理请求，并不能单独证明它已传播，也不能证明源站已经能返回预期的新字节。

坏掉的样子

如果源站尚未更新就先清理边缘，下一次未命中可能立即把旧内容重新填回去。已经在途的回填也可能和失效操作竞争，具体结果取决于缓存实现。反复执行全站清理不能证明这些竞争已经解决，反而会让更多对象变冷、增加回源负担。应准确圈定受影响对象，并评估清理之后源站需要承担的请求量。

对于静态资产，应先发布带内容指纹的新文件名，再切换 HTML 或清单中的引用。在旧文档仍可能引用旧资产期间，旧文件也应继续可用。新 URL 可以避开旧缓存条目，但前提是读者先拿到更新后的引用文档。只生成一个新文件名，却不更新文档，或者文档本身仍被直接复用，都不会使现有读者自动转向新版本。

涉及机密信息删除时，边界还要更严格。删除源站文件或清理 CDN 不能撤销已经下载的字节，缓存策略也不等于访问授权。应从源头防止敏感响应进入不合适的缓存，而不是泄露后依赖清理挽救。对于紧急修复，要先定义“可见”的对象：新访问者、已经打开的标签页、所有曾下载的副本，不能共享同一种到达保证。

快速验证

准备 Python 3.10 或更新版本及 POSIX shell；实际运行使用 Python 3.14.4、CacheControl 0.14.4 和 Requests 2.34.2。安装下列固定版本后，用 "$invalidation_lab/venv/bin/python" 执行 Python 代码。程序在自动分配的回环端口启动一个 HTTP 服务，并建立两个互不共享存储的内存私有缓存；关闭环境代理，不访问外部服务器，最后关闭客户端、线程和服务。只有依赖安装需要联网。

invalidation_lab=$(mktemp -d)
python3 -m venv "$invalidation_lab/venv"
"$invalidation_lab/venv/bin/python" -m pip install CacheControl==0.14.4 requests==2.34.2

from collections import Counter
from http.server import BaseHTTPRequestHandler, HTTPServer
from threading import Thread

import requests
from cachecontrol import CacheControl
from cachecontrol.cache import DictCache

assets = {"/manual.txt": b"A"}
counts = Counter()


class Origin(BaseHTTPRequestHandler):
 def log_message(self, *_):
 pass

 def do_GET(self):
 counts[self.path] += 1
 body = assets.get(self.path, b"missing")
 status = 200 if self.path in assets else 404
 self.send_response(status)
 self.send_header("Cache-Control", "max-age=600" if status == 200 else "no-store")
 self.send_header("Content-Length", str(len(body)))
 self.end_headers()
 self.wfile.write(body)


server = HTTPServer(("127.0.0.1", 0), Origin)
worker = Thread(target=server.serve_forever)
worker.start()
base = f"http://127.0.0.1:{server.server_port}"
caches = [DictCache(), DictCache()]
clients = []
try:
 for cache in caches:
 client = CacheControl(requests.Session(), cache=cache)
 client.trust_env = False
 clients.append(client)

 def check(index, path, status, body, cached):
 response = clients[index].get(base + path, timeout=3)
 assert (response.status_code, response.content, response.from_cache) == (
 status, body, cached
 )

 for index in range(2):
 check(index, "/manual.txt", 200, b"A", False)
 check(index, "/manual.txt", 200, b"A", True)
 assert counts["/manual.txt"] == 2
 print("warm: two independent caches hold A; origin requests=2")

 assets["/manual.txt"] = b"B"
 caches[0].delete(base + "/manual.txt")
 check(0, "/manual.txt", 200, b"B", False)
 check(1, "/manual.txt", 200, b"A", True)
 assert counts["/manual.txt"] == 3
 print("targeted invalidation: cache 0=B; cache 1=A")

 check(1, "/manual.v2.txt", 404, b"missing", False)
 assets["/manual.v2.txt"] = b"B"
 for index in range(2):
 check(index, "/manual.v2.txt", 200, b"B", False)
 check(index, "/manual.v2.txt", 200, b"B", True)
 assert counts["/manual.v2.txt"] == 3
 check(1, "/manual.txt", 200, b"A", True)
 print("new URL: 404 before publication, then both caches=B")
 print("old URL: cache 1 still holds A")
finally:
 for client in clients:
 client.close()
 server.shutdown()
 worker.join()
 server.server_close()

两名客户端各自第一次向源站获取 A，随后命中自己的缓存，所以初始回源总数是两次。把源站内容改成 B 后，只删除零号缓存中精确 URL 对应的条目：零号客户端重新取得 B，一号仍直接返回 A，不会产生新回源。此时旧 URL 的回源总数为三次。结果直接展示了定点移除的作用范围，并没有证明所有副本已经收敛。

新文件名第一次请求返回带 no-store 的 404，特意暴露了“先引用、后发布”的错误顺序。发布这个文件后，两名客户端都能取得并缓存 B；由于前面的错误响应不存储，它不会挡住这次读取。然而一号客户端再访问旧 URL，仍然命中 A。新旧 URL 是不同条目，发布新版本并不意味着旧条目已被擦除。

这是使用真实 HTTP 请求和缓存存储的局部实验，不是 CDN 清理实现，也没有测试浏览器行为、全球传播或在途回填竞态。CacheControl 的安全模型是私有缓存，不能把这段程序扩成多用户共享边缘。实验只证明明确操作过的条目会变化，其他缓存仍按各自收到的策略工作；上线验收必须另外检查真实服务商规则和实际请求链路。

来源

RFC 9111：使已存响应失效，不安全方法与失效范围，已核验 2026-09-07。
CloudFront：清理与版本化文件名，清理边缘不会清空独立缓存，已核验 2026-09-07。
CacheControl 用法，会话与独立缓存存储，已核验 2026-09-07。
CacheControl 安全模型，私有缓存的适用限制，已核验 2026-09-07。

过期缓存需要明确的重新验证与陈旧响应策略

Thu, 24 Jun 2027 00:00:00 +0000

nginx 代理缓存需要分别作出几项决定：怎样识别已存响应，什么时候允许读取，什么时候允许保存新响应，以及过期副本还能怎样使用。如果把这些都看成一个 TTL 设置，故障就很难解释。验证时应同时观察请求实际经过的路径与交付字节，而不只是确认 nginx 接受了配置文件。

存储容量与新鲜度分开看

proxy_cache_path 声明磁盘存储位置及保存元数据的共享内存 keys_zone，proxy_cache 再为请求启用这个区域。元数据区大小不等于正文缓存容量。max_size 由缓存维护机制管理，不是瞬时硬磁盘配额；inactive 保留策略也不是响应的新鲜度寿命。已经过期的响应仍可能留在存储中，用于后续重新验证。

默认缓存键为 $scheme$proxy_host$request_uri，其中 request_uri 已经包含查询串，后面再加 $is_args$args 就重复拼接了参数。也不能随意替换成规范化后的 URI，或遗漏会改变表示的输入。默认启用 HEAD 转换，因此 GET 与 HEAD 共享相应缓存行为；关闭转换时，就需要在缓存键中考虑请求方法。

核对真正生效的响应策略

proxy_cache_valid 按状态码提供配置寿命，但正常处理的源站新鲜度头具有更高优先级。X-Accel-Expires 还有自己的优先顺序；它不存在时，Cache-Control 和 Expires 才参与相应设置。忽略这些头会改变实际契约。下面的实验里，源站 max-age 为一秒，覆盖了配置的六十秒；no-store 则阻止响应进入存储。

proxy_cache_revalidate 让过期条目使用 ETag、Last-Modified 等验证器发送条件请求。匹配的 304 可以保留正文并更新元数据，变化后的 200 则提供替代字节。但重新验证不等于异步刷新。后台更新是另一项指令，还需要允许在更新期间返回旧内容，不能仅凭某一个开关推断整套刷新方式。

坏掉的样子

proxy_cache_bypass 控制不从缓存读取，proxy_no_cache 控制不保存新响应。要求两者都成立的路由，需要分别表达两个决策。一次绕过也不意味着已经清除了原有条目。实验让这两项指令使用同一个专用测试头，并验证绕过之后，原有副本依然可用。这个头只是实验开关，不能当作真实身份认证或权限策略。

proxy_cache_use_stale http_500 允许在上游返回 500 时使用已有陈旧副本；完全冷的键没有副本可用，因此不会凭空获得保护。这项指令本身没有规定最大陈旧秒数。源站 stale-if-error 时间窗的优先级低于这些指令参数，额外加上它也不能限制这里的设置。启用之前必须先决定旧内容在业务上是否仍然可接受。

否则，一个表面成功的响应可能正在隐藏源站故障，或者继续交付已经不该使用的数据。应把上游结果、nginx 缓存状态和返回正文一起记录。配置语法检查不能证明账户隔离，一次热缓存命中也不代表并发冷加载正常。缓存锁、容量压力下的保留行为和多工作进程模式，都需要单独验证，不能从本次顺序实验推导出来。

快速验证

下文集成实验的结果保留自历史运行记录；本次修订没有重新执行该实验，不能将这些记录当成本次环境的新实测。

需要 POSIX 环境、C 编译器、make、curl、tar 以及 Python 3.11 或更新版本。本次在 macOS 上使用 clang 21.0.0、Python 3.14.4 和 nginx 1.30.4 执行。下列命令只编译一个独立的 HTTP 实验程序，不安装到系统，也不用 sudo；关闭 rewrite 和 gzip 模块以避免它们的外部依赖。这不是部署 TLS 服务的配置教程。

nginx_lab=$(mktemp -d)
curl --fail --location --output "$nginx_lab/nginx.tar.gz" https://nginx.org/download/nginx-1.30.4.tar.gz
tar -xzf "$nginx_lab/nginx.tar.gz" -C "$nginx_lab"
cd "$nginx_lab/nginx-1.30.4"
./configure --prefix="$nginx_lab/install" --without-http_rewrite_module --without-http_gzip_module
make -j2
export NGINX_BIN="$nginx_lab/nginx-1.30.4/objs/nginx"

在同一个 shell 中用 python3 执行 Python 代码。程序创建自己的配置和缓存目录，先检查语法，再在选定的回环端口启动源站与 nginx；两次短暂等待用于跨过真实到期时间。结束时关闭自己启动的代理进程和源站，仅移除临时运行目录。源码下载需要外网，实验请求全部留在本机，不操作现有 nginx 服务。

import hashlib
import os
from http.client import HTTPConnection
from http.server import BaseHTTPRequestHandler, HTTPServer
from pathlib import Path
import signal
import socket
import subprocess
from tempfile import TemporaryDirectory
from threading import Thread
import time

state = {"body": b"A", "fail": False}
seen = []


class Origin(BaseHTTPRequestHandler):
 def log_message(self, *_):
 pass

 def do_GET(self):
 tag = '"' + hashlib.sha256(state["body"]).hexdigest() + '"'
 conditional = self.headers.get("If-None-Match")
 if self.path == "/short" and state["fail"]:
 status, body = 500, b"failure"
 elif conditional == tag:
 status, body = 304, b""
 else:
 status, body = 200, state["body"]
 directive = "max-age=1" if self.path == "/short" else "max-age=60"
 if self.path == "/no-store" or status == 500:
 directive = "no-store"
 seen.append((self.path, status, conditional))
 self.send_response(status)
 self.send_header("Cache-Control", directive)
 if status != 500:
 self.send_header("ETag", tag)
 if status != 304:
 self.send_header("Content-Length", str(len(body)))
 self.end_headers()
 self.wfile.write(body)


origin = HTTPServer(("127.0.0.1", 0), Origin)
worker = Thread(target=origin.serve_forever)
worker.start()
try:
 with TemporaryDirectory(prefix="nginx-cache-lab-") as directory:
 root = Path(directory)
 with socket.socket() as reservation:
 reservation.bind(("127.0.0.1", 0))
 port = reservation.getsockname()[1]
 config = root / "nginx.conf"
 config.write_text(f"""
pid nginx.pid;
error_log stderr error;
events {{ worker_connections 64; }}
http {{
 access_log off;
 proxy_cache_path "{root}/cache" keys_zone=lab:1m max_size=10m;
 server {{
 listen 127.0.0.1:{port};
 location / {{
 proxy_pass http://127.0.0.1:{origin.server_port};
 proxy_cache lab;
 proxy_cache_valid 200 60s;
 proxy_cache_revalidate on;
 proxy_cache_use_stale http_500;
 proxy_cache_bypass $http_x_lab_bypass;
 proxy_no_cache $http_x_lab_bypass;
 proxy_connect_timeout 2s;
 proxy_read_timeout 2s;
 add_header X-Lab-Cache $upstream_cache_status always;
 }}
 }}
}}
""", encoding="utf-8")
 command = [os.environ["NGINX_BIN"], "-p", str(root) + "/",
 "-c", str(config), "-e", "stderr"]
 checked = subprocess.run(command + ["-t"], capture_output=True, text=True)
 assert checked.returncode == 0, checked.stderr
 process = subprocess.Popen(command + ["-g", "daemon off; master_process off;"],
 stdout=subprocess.DEVNULL, stderr=subprocess.PIPE, text=True)
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "nginx exited during startup"
 try:
 with socket.create_connection(("127.0.0.1", port), timeout=0.1):
 break
 except OSError:
 if time.monotonic() >= deadline:
 raise TimeoutError("nginx did not become ready")
 time.sleep(0.05)

 def get(path, expected, body, bypass=False):
 connection = HTTPConnection("127.0.0.1", port, timeout=3)
 try:
 connection.request("GET", path, headers={"X-Lab-Bypass": "1"} if bypass else {})
 response = connection.getresponse()
 actual = (response.status, response.getheader("X-Lab-Cache"), response.read())
 assert actual == (200, expected, body), actual
 print(path, expected, body.decode())
 finally:
 connection.close()

 get("/long", "MISS", b"A")
 get("/long", "HIT", b"A")
 state["body"] = b"B"
 get("/long", "BYPASS", b"B", bypass=True)
 get("/long", "HIT", b"A")
 assert sum(path == "/long" for path, _, _ in seen) == 2

 get("/short", "MISS", b"B")
 time.sleep(2.1)
 get("/short", "REVALIDATED", b"B")
 assert seen[-1][1:] == (304, '"' + hashlib.sha256(b"B").hexdigest() + '"')
 state["fail"] = True
 time.sleep(2.1)
 get("/short", "STALE", b"B")
 assert seen[-1][1] == 500
 state.update(body=b"C", fail=False)
 get("/short", "EXPIRED", b"C")
 get("/short", "HIT", b"C")
 get("/no-store", "MISS", b"C")
 get("/no-store", "MISS", b"C")
 assert sum(path == "/no-store" for path, _, _ in seen) == 2
 finally:
 if process.poll() is None:
 process.send_signal(signal.SIGQUIT)
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode == 0, errors
finally:
 origin.shutdown()
 worker.join()
 origin.server_close()

长寿命路径依次报告 MISS A、HIT A、BYPASS B、HIT A。源站在这条路径只收到两次请求，说明绕过请求获取了 B，却没有把它保存成新的共享副本，也没有删除之前的 A。短寿命路径先报告 MISS B；到期之后报告 REVALIDATED B，源站记录同时确认它确实收到正确的条件 ETag，并返回了 304。

注入源站 500 后，代理报告 STALE B，继续交付原来的正文。源站恢复并提供 C 后，EXPIRED C 替换缓存内容，接下来的访问成为 HIT C。两次 no-store 请求都保持 MISS，且都抵达源站。这里检查的是实际状态和字节，不把日志里出现一个状态词单独当作功能证明。

这些结果来自真实 nginx 的单进程隔离实验，不覆盖后台刷新、分布式失效、生产授权、磁盘压力处理或所有陈旧策略组合。真实发布还需要结合对应版本、完整配置和实际流量补齐这些范围。保留这种边界，才能区分“某条配置路径已经测过”和“整个代理部署已经验收”。

来源

nginx 代理模块，缓存键、头字段优先级、重新验证、绕过、保存和陈旧策略，已核验 2026-10-15。
nginx 编译配置，构建前缀和可选模块依赖，已核验 2026-10-15。
nginx 内容缓存指南，磁盘存储、共享元数据和缓存维护，已核验 2026-10-15。
RFC 9111：陈旧响应，新鲜度与允许使用旧响应的条件，已核验 2026-10-15。

读穿透缓存：未命中时取数回填

Wed, 26 May 2027 00:00:00 +0000

读穿透缓存给调用者提供统一的读取接口：命中时返回已存值，未命中时调用加载函数，再把结果保存起来。关键边界是由谁拥有这个 loader。把它放到缓存接口后面，可以减少重复的查找逻辑，但并不会自动解决并发、写入、访问授权或不同缓存副本之间的一致性。模式名称不是这些能力已经具备的证明。

找到真正负责加载的一层

在 cache-aside 模式中，应用显式查询缓存，未命中后访问数据源并回填；读穿透则让缓存组件拥有这条未命中路径。它可以是应用进程里的库，也可以是远程缓存服务。两种部署方式各有更新边界：修改进程内库的 loader，仍然需要把变更部署到使用它的进程，不能笼统宣称所有读者都会免部署地自动获得新逻辑。

单独一个 Redis GET 也不是读穿透加载器。字符串键不存在时，它返回 nil，不会自动发现并查询你的数据库。客户端库、缓存服务或应用适配层必须另外提供加载逻辑。下面的实验用带记忆功能的函数包装器提供统一读取接口，缓存和数据源都在当前进程内；这不是 Redis 服务端加载功能的演示。

读取模式没有定义写入模式

读穿透本身没有规定写操作经过哪里，写穿透是另一项安排。即便读写共用一个组件，仍需要定义数据源写入和缓存更新分别失败时的行为。绕过组件的其他写入方，可能让缓存保持旧值。应沿真实业务更新路径检查参与者，不能因为使用了一个模式名称，就假定所有写入都会配合清理。

TTL 限制的是某个缓存条目的复用时间，并不保证下一次重载从滞后副本或有缺陷的 loader 中取到最新真值。过期也不一定立即从内存中释放字节。寿命应依据数据需求选择，而非套用统一的几秒或几分钟；用户数据的 TTL 再短，也不构成权限隔离。命中率很高同样不能证明内容正确。

坏掉的样子

记录不存在与数据源不可用，是两个不同结果。缓存一次合法的“不存在”可以减少重复查询，但如果随后创建了记录，这个否定结果也可能继续遮住新记录，直到到期或失效。若把超时转换成一次正常返回的空值，就可能把故障写成错误的缓存内容。必须明确哪些结果允许保存，以及调用者如何区分缺失和失败。

并发加载是另一项独立契约。Cachetools 明确说明：锁保护缓存对象的访问，但被包装的函数在锁外运行，因此只有锁并不能抑制重复加载。它的 condition 选项另行处理同键的并发执行。下面的实验只运行单线程，刻意不使用这两个参数，不能把代码当成已经具备线程安全或分布式协作的实现。

失效还可能与一个已经读到旧源版本的加载操作竞争。删除某个键，并不天然阻止那个在途结果稍后重新写入。应根据真实的写入和加载协议选择协调方式，并测试操作顺序。也不要把大范围按键模式删除当作默认修复：它会让更多条目变冷，却没有证明源头缺陷已经解决。

快速验证

需要 Python 3.10 或更新版本；本次使用 Python 3.12.14 和 cachetools 7.1.8。安装固定依赖后，用 "$readthrough_lab/venv/bin/python" 执行 Python 代码。缓存存储、到期和函数记忆行为都由现有库负责；测试手动推进专用时钟，无需睡眠，也不修改系统时间。实验不联系 Redis 或外部数据库，只有依赖安装需要联网。

readthrough_lab=$(mktemp -d)
python3 -m venv "$readthrough_lab/venv"
"$readthrough_lab/venv/bin/python" -m pip install cachetools==7.1.8

from collections import Counter

from cachetools import TTLCache, cached

clock = [0]
cache = TTLCache(maxsize=8, ttl=10, timer=lambda: clock[0])
source = {"tea": 100}
failures = set()
loads = Counter()


@cached(cache=cache, info=True)
def price(sku):
 loads[sku] += 1
 if sku in failures:
 raise OSError("source unavailable")
 return source.get(sku)


assert price("tea") == price("tea") == 100
assert loads["tea"] == 1
source["tea"] = 120
clock[0] = 9
assert price("tea") == 100 and loads["tea"] == 1
clock[0] = 10
assert price("tea") == 120 and loads["tea"] == 2
print("hit does not extend TTL: old value at t=9; reload at t=10")

source["tea"] = 130
cache.pop(price.cache_key("tea"))
assert price("tea") == 130 and loads["tea"] == 3
print("explicit eviction: next read loads the updated source")

assert price("coffee") is None
source["coffee"] = 200
assert price("coffee") is None and loads["coffee"] == 1
cache.pop(price.cache_key("coffee"))
assert price("coffee") == 200 and loads["coffee"] == 2
print("None is cached: newly created data needs expiry or invalidation")

cache.pop(price.cache_key("tea"))
failures.add("tea")
for _ in range(2):
 try:
 price("tea")
 except OSError:
 pass
 else:
 raise AssertionError("failure was hidden")
assert loads["tea"] == 5
assert price.cache_key("tea") not in cache
failures.remove("tea")
assert price("tea") == price("tea") == 130
assert loads["tea"] == 6
print("exceptions are not cached: two failed loads, then one recovery load")
print(price.cache_info())

前两次读取只执行一次 loader。修改数据源之后，仍然有效的缓存价格不会随之改变，在第九秒仍返回 100；到了第十秒，条目过期，包装器才加载 120。这验证的是从插入开始计算的寿命，而不是每次访问都延长的滑动过期。随后按包装器实际使用的缓存键移除条目，下一次读取才取得新的价格 130。

不存在的 coffee 价格会以 None 形式缓存。仅创建源记录不会替换这份已存的空结果，显式移除后才能重新加载到 200。连续两次源故障都会执行 loader 并抛出异常，缓存中不留下 tea 条目；恢复以后，一次成功加载可以供应两次读取。最后报告四次命中和八次未命中，失败的加载也计入未命中。

这些断言证明的是这个包装器实际观察到的未命中、到期、空结果与错误行为，没有证明写入原子性、并发未命中抑制、内存压力下的淘汰或分布式一致性。验收真实服务时，要把 loader 的执行次数和结果分类与缓存统计一起记录。两次 HTTP 请求变快，或者 Redis 全局命中计数增加，都无法单独指出某个应用 loader 是否真的执行过。

来源

Cachetools 文档，TTLCache、cached、同步选项与异常处理，已核验 2026-09-07。
Redis GET，键缺失时返回 nil，不会加载其他数据源，已核验 2026-09-07。
AWS Builders’ Library：缓存挑战与策略，冷缓存、否定结果缓存与源站负载风险，已核验 2026-09-07。

陈旧缓存需要有界策略

Mon, 01 Feb 2027 00:00:00 +0000

陈旧响应可以在源站故障时维持公开手册的可读性，也可能保留过时价格、已撤销权限或误导性的状态。可用性并不天然高于正确性。启用这种行为之前，应先确定哪些信息允许继续使用、什么条件下可以复用，以及最多能旧多久，而不是看到一次错误响应就无条件拿旧成功结果代替。

用可用性换新鲜度

过期和淘汰是两件事。过期响应仍可留在缓存里，用于条件验证或受到许可的陈旧响应；但冷缓存或已经淘汰条目的缓存，没有旧正文可返回。陈旧指令无法凭空创造副本，保存着字节也不会自动授予复用权限。选中的响应还必须匹配当前请求，包括相关 Vary 维度和访问边界，不能拿另一个请求留下的成功内容填补故障。

如何表示

stale-while-revalidate 允许在有界窗口内返回旧响应，同时尝试不阻塞该响应的验证。stale-if-error 则允许在尝试访问源站遭遇符合条件的错误时使用旧响应。两者触发条件不同，都不强制缓存保存内容，也不能保证每种缓存实现都支持。请求到达时若已越过允许窗口，不能因为之前有过一次许可，就继续无限期使用旧内容。

对于 max-age=30, stale-if-error=60，额外六十秒从新鲜期结束后开始计算，不是从每一次失败尝试重新开始。候选响应的总年龄窗口约为九十秒。RFC 5861 指定了会形成 500、502、503、504 的错误场景。认证失败或资源不存在，不能随手重新包装成可用性故障，再用旧的成功响应掩盖真正需要客户端看到的结果。

成功的条件验证不一定重新下载正文。三零四响应可以依据验证元数据更新存储响应，同时保留原来的表示字节。应把这种结果与替换正文的二百响应、故障期间的陈旧命中分别记录；三种情况可能显示相同页面，却对应不同的新鲜度依据，不能仅靠正文是否改变判断验证是否发生。

坏掉的样子

每次重验证失败后都把 Age 清零，会把有界例外变成无限陈旧。保留旧正文却刷新存储时间戳，也会造成同类错误。失败时应保留年龄；只有真正的新响应或成功验证，才提供更新新鲜度的依据。后台验证通常由流量触发，所以一个长期无人访问的缓存，不一定会在下一次用户访问之前主动把内容更新好。

只读或幂等并不代表可以安全返回旧内容。一个 GET 也可能涉及对时效敏感的权限或价格。RFC 9111 禁止在适用的 no-cache、must-revalidate 等指令不允许时复用陈旧响应。应避免互相矛盾的策略，并测试实际部署的缓存如何处理这些限制。另外，RFC 5861 中关于旧 Warning 字段的建议，已被废弃该字段的 RFC 9111 更新，不能把它当作当前验收必需项。

观察指标中要区分陈旧响应和新鲜命中，记录总年龄、错误类别以及验证是否成功，同时避免记录秘密信息。如果每次都返回旧内容，漂亮的 HTTP 成功率可能掩盖持续故障的源站。恢复验收必须确认发生了真实替换或成功验证，而不是只看到源站进程重新启动，就宣布数据已经恢复新鲜。

快速验证

准备 Node.js 与 npm。本轮使用 Node 24.19.0 和已有的 http-cache-semantics 4.2.0 安装运行了 JavaScript。安装固定版本后，用 NODE_PATH="$stale_lab/node_modules" node 执行 JavaScript。这是使用虚构响应和受控时钟的确定性策略与正文选择实验，不发送请求，也不制造真实宕机；只有安装阶段需要联网。

stale_lab=$(mktemp -d)
npm install --prefix "$stale_lab" --ignore-scripts --no-audit --no-fund --package-lock=false http-cache-semantics@4.2.0

const assert = require("node:assert/strict");
const CachePolicy = require("http-cache-semantics");

const start = Date.parse("2026-09-07T00:00:00Z");
let clock = start;
class TestPolicy extends CachePolicy {
 now() { return clock; }
}
const request = { url: "https://example.test/manual", method: "GET", headers: {} };
const policy = new TestPolicy(request, { status: 200, headers: {
 "cache-control": "public, max-age=30, stale-if-error=60",
 etag: '"revision-a"', age: "0",
} });
const oldBody = Buffer.from("manual revision A");
clock = start + 35000;
const decision = policy.evaluateRequest(request);
assert.equal(decision.response, undefined);
assert.equal(decision.revalidation.synchronous, true);
assert.equal(decision.revalidation.headers["if-none-match"], '"revision-a"');
console.log("age 35: validate before using stale-if-error");

for (const status of [500, 502, 503, 504]) {
 const result = policy.revalidatedPolicy(request, { status, headers: { "cache-control": "no-store" } });
 assert.equal(result.modified, false);
 assert.equal(result.policy, policy);
 assert.equal(result.policy.responseHeaders().age, "35");
 const body = result.modified ? Buffer.from("origin error") : oldBody;
 assert.equal(body.toString(), "manual revision A");
 console.log(status, "uses old body without resetting Age");
}
const denied = policy.revalidatedPolicy(request, { status: 403, headers: { "cache-control": "no-store" } });
assert.equal(denied.modified, true);
assert.equal(denied.policy.storable(), false);
console.log("403 does not use the stale success response");

clock = start + 89000;
assert.equal(policy.revalidatedPolicy(request, { status: 503, headers: {} }).modified, false);
clock = start + 91000;
const expired = policy.revalidatedPolicy(request, { status: 503, headers: { "cache-control": "no-store" } });
assert.equal(expired.modified, true);
assert.equal(expired.policy.storable(), false);
console.log("age 89: stale allowed; age 91: error must be surfaced");

const recovered = policy.revalidatedPolicy(request, { status: 200, headers: {
 "cache-control": "public, max-age=30, stale-if-error=60",
 etag: '"revision-b"', age: "0",
} });
assert.equal(recovered.modified, true);
assert.equal(recovered.policy.age(), 0);
assert.equal(recovered.policy.satisfiesWithoutRevalidation(request), true);
const newBody = Buffer.from("manual revision B");
const delivered = recovered.modified ? newBody : oldBody;
assert.equal(delivered.toString(), "manual revision B");
console.log("recovery 200: replace the body and start the new policy");

年龄三十五秒时，正常决策要求同步验证；单独的 stale-if-error 不会授权立即把旧响应当作命中返回。随后四种符合条件的虚构错误都保留版本 A 和原策略，向下游返回的 Age 仍然是三十五秒，而不是被重置成零。403 分支不会复用旧成功正文，并且这条带 no-store 的错误响应不具备存储资格。

同一个旧条目在八十九秒年龄时仍可覆盖符合条件的错误，在九十一秒时则不行，重复失败没有延长窗口。之后收到带版本 B 的成功 200，会产生新鲜策略并选择新正文。实验同时检查元数据决策和调用方到底保留、替换了哪些字节，不是只确认一个布尔返回值看起来正确。

这个库不会代替调用方发请求、重试、安排后台任务或保存正文。断言只覆盖一个匹配的热缓存条目和这组无冲突策略，不覆盖网络超时处理、所有指令组合或完整 CDN。部署验收仍需沿真实链路测试冷缓存、窗口耗尽和故障恢复，并确认允许的陈旧程度没有越过该资源的正确性要求。

来源

RFC 5861：陈旧控制，扩展窗口和符合条件的错误状态，已核验 2026-09-07。
RFC 9111：提供陈旧响应，陈旧复用限制，已核验 2026-09-07。
http-cache-semantics 4.2.0，重验证决策和调用方负责的正文存储，已核验 2026-09-07。

不可变资源与内容指纹

Wed, 25 Nov 2026 00:00:00 +0000

资源指纹把文件字节的摘要放进地址。样式表发生变化，构建就为新内容生成另一个地址，页面因此能够选择新版本，而不用等待所有旧缓存同时过期。这项方法依赖发布流程遵守承诺：某个地址一旦对外提供，就不能随意替换成与名称摘要不符的内容。文件名看起来像摘要，不代表服务器已经落实这种约束。

名称配合新鲜度契约

构建程序可以对生成文件计算完整的 SHA-256，再把页面中的逻辑名称替换成相应地址。同样的字节保留相同名称，变化的字节通常得到不同名称；摘要截断越短，碰撞风险越需要认真评估。浏览器不会因为名称含有一串十六进制字符，就自动计算文件摘要验证完整性。实际缓存键还受到请求上下文和 Vary 等因素影响，命名方法不能取代 HTTP 缓存规则。

公开指纹资源常用的响应头是 Cache-Control: public, max-age=31536000, immutable。前者给出一年新鲜期，后者承诺该表示在新鲜期内不会改变，因此 RFC 8246 建议客户端避免不必要的条件请求。这不是永久保存许可：缓存可能被淘汰，用户可以强制刷新，客户端也可能不支持扩展。规范还建议在 HTTPS 等经过认证的上下文之外忽略 immutable，不能把它当作内容可信性的替代品。

负责引用这些资源的 HTML 需要独立缓存策略，例如较短新鲜期或合适的重新验证，让用户能够发现新版本。发布顺序应先让新资源可用，再暴露引用它们的页面或清单。旧页面、旧标签页和回退版本仍可能使用旧地址，资源保留期限必须覆盖这些真实使用方式。仅有指纹，不能让整个多文件发布自动成为原子事务。

public 只适合允许共享的表示。某份个性化下载即使带有内容摘要，也不会因此变成可供共享缓存保存的公开资源。响应策略仍然必须服从身份鉴别与保密要求；摘要只是命名依据，不能充当授权或隔离用户数据的措施。

坏掉的样子

覆盖旧指纹路径会制造两套互相矛盾的事实：已有用户继续从缓存读取红色样式，新客户端却在同一个地址读到蓝色字节。清理一个 CDN 节点，也不能把所有浏览器里的私有副本同步删除。发布检查应核对真实文件字节和记录的摘要，在开放流量之前拒绝这种变更，而不是依赖上线后提醒用户刷新。

立即删除上一版资源会产生另一类故障。缓存中的页面还可能引用昨日脚本，回退后的 HTML 也可能依赖已经移除的文件。保留源码提交不等于保留可直接恢复的构建产物。即使所有摘要都正确，先发布页面、后上传文件仍会造成暂时的缺失资源；多节点传播期间也需要检查依赖是否已经就绪。

快速验证

把下面代码保存为 immutable.py，使用 Python 3 执行 python3 immutable.py。程序启动回环服务，检查样式字节的摘要和缓存响应头，故意改写旧地址背后的内容，确认摘要不匹配，然后恢复原文并关闭服务。预期三个契约检查标志为真，而 browser_cache_tested_by_cli 为假。这个命令读取了真实 HTTP 响应，但没有实现浏览器缓存，因此不能单凭命令结果宣称已经验证客户端复用行为。

from hashlib import sha256
from http.client import HTTPConnection
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from threading import Event, Lock, Thread
from urllib.parse import urlsplit
import json
import sys

styles = {'one': b'body{background:rgb(127,29,29);color:white;font-family:sans-serif;margin:3rem}',
 'two': b'body{background:rgb(30,64,175);color:white;font-family:sans-serif;margin:3rem}'}
paths = {name: '/assets/' + sha256(data).hexdigest() + '.css' for name, data in styles.items()}
state = {'tampered': False, 'requests': []}
lock = Lock()


class Handler(BaseHTTPRequestHandler):
 def do_POST(self):
 if self.path not in ('/tamper', '/restore'):
 self.send_error(404)
 return
 with lock:
 state['tampered'] = self.path == '/tamper'
 self.send_response(204)
 self.end_headers()

 def do_GET(self):
 path = urlsplit(self.path).path
 cache = 'no-store'
 if path in ('/one', '/two'):
 name = path[1:]
 data = f'<!doctype html><html><head><meta name="viewport" content="width=device-width,initial-scale=1"><title>Immutable asset lab</title><link rel="icon" href="data:,"><link rel="stylesheet" href="{paths[name]}"></head><body><h1>Release {name}</h1><p>The background comes from the referenced CSS artifact.</p></body></html>'.encode()
 kind = 'text/html; charset=utf-8'
 elif path in paths.values():
 with lock:
 state['requests'].append(path)
 data = styles['two'] if path == paths['two'] or state['tampered'] else styles['one']
 kind, cache = 'text/css', 'public, max-age=31536000, immutable'
 elif path == '/events':
 with lock:
 data = json.dumps(state).encode()
 kind = 'application/json'
 else:
 self.send_error(404)
 return
 self.send_response(200)
 self.send_header('Content-Type', kind)
 self.send_header('Cache-Control', cache)
 self.send_header('Content-Length', str(len(data)))
 self.end_headers()
 self.wfile.write(data)

 def log_message(self, *args):
 pass


server = ThreadingHTTPServer(('127.0.0.1', 0), Handler)
thread = Thread(target=server.serve_forever)
thread.start()
try:
 origin = f'http://127.0.0.1:{server.server_port}'
 if '--serve' in sys.argv:
 print(json.dumps({'origin': origin, 'assets': paths}), flush=True)
 try:
 Event().wait()
 except KeyboardInterrupt:
 pass
 else:
 def request(method, path):
 connection = HTTPConnection('127.0.0.1', server.server_port, timeout=5)
 try:
 connection.request(method, path)
 response = connection.getresponse()
 return response.status, response.getheader('Cache-Control'), response.read()
 finally:
 connection.close()

 status, cache, original = request('GET', paths['one'])
 assert status == 200 and cache == 'public, max-age=31536000, immutable'
 assert sha256(original).hexdigest() in paths['one']
 assert request('POST', '/tamper')[0] == 204
 changed = request('GET', paths['one'])[2]
 assert sha256(changed).hexdigest() not in paths['one']
 assert request('GET', paths['two'])[2] == styles['two']
 assert request('POST', '/restore')[0] == 204
 assert request('GET', paths['one'])[2] == original
 print(json.dumps({'hash_name_contract_checked': True,
 'changed_old_url_detected': True, 'original_restored': True,
 'browser_cache_tested_by_cli': False}))
finally:
 server.shutdown()
 thread.join()
 server.server_close()

浏览器实验另行执行 python3 immutable.py --serve，把打印的完整源地址存入终端变量 ASSET_ORIGIN。用新的浏览器配置目录并保持正常缓存，先打开该源的 /one。随后执行 curl -X POST "$ASSET_ORIGIN/tamper"，再导航到 /one?after=mutation，最后打开 /two。访问 /events 可以查看服务端收到的资源请求；实验结束后按 Ctrl-C 关闭服务。不要对真实站点执行这个故意改写资源的步骤。

在 Chrome 152.0.7977.83 中，第一次页面为红色，改写服务器内容后的第二次导航仍为红色，旧样式路径总共只收到一次请求。新指纹路径对应的页面变为蓝色，新样式同样只请求一次。这证明了本例的缓存分离行为以及改写新鲜资源的风险。普通 max-age 新鲜度就足以解释这次复用，不能把结果全部归因于 immutable，也没有隔离测试刷新时的验证行为或 HTTPS。其他浏览器仍需独立验证；如果新地址此前已经缓存，换引用也不保证每次都产生新的网络传输。

来源

RFC 8246: HTTP Immutable Responses，新鲜期内的不可变承诺及认证上下文建议，已核验 2026-09-13。
MDN: HTTP caching，版本化地址、缓存新鲜度与验证，已核验 2026-09-13。

Age 头告诉我们缓存已存在多久

Fri, 06 Nov 2026 00:00:00 +0000

Age 是从源站生成或成功验证响应以来，已经经过多少秒的估计值，包含缓存驻留和网络传输时间。它不是对象的创建时间戳，也不是访问次数，更不只是最后一台代理在磁盘上保存副本的时长。要判断这个数字意味着什么，必须同时查看响应的新鲜度策略和实际请求上下文，不能把年龄直接等同于是否允许复用。

合并估计时不能重复计时

RFC 9111 定义了接收响应时的两种年龄估计。表观年龄用接收缓存的时钟减去 Date，如果得到负数，就按零处理。校正年龄从收到的 Age 数值出发，再加上发出请求到收到响应之间的时间。缺少 Age 时，这个输入按零参与计算，但并不意味着应当丢掉基于 Date 的另一种估计。

当缓存链满足相关 HTTP 行为要求时，RFC 允许直接使用校正年龄；更保守的计算则取表观年龄与校正年龄的较大值，再加本地驻留时间。下面的实验采用后者。把这两种估计直接相加，会重复计算互相重叠的时间；而每经过一个缓存就把 Age 清零，又会丢掉上游已经积累的历史。

请求、接收和本地驻留时间应使用一致的测量方法，Date 比较还依赖时钟同步。因此结果仍然是估计，而不是精确秒表。生产实现需要恰当处理时钟和输出整数值。下面只使用固定的整秒 UTC 时间与合法头字段，展示指定计算步骤，不构成一套完整的 HTTP 缓存实现。

新鲜度是另一个判断

当前年龄为四十五秒，寿命为六十秒时仍在新鲜期；同样的年龄放在三十秒寿命下，就已经陈旧。相等时也算陈旧，因为新鲜要求年龄严格小于寿命。不过，这个比较本身并不授权复用。请求限制、缓存键、Vary、存储规则和要求验证的指令，都可能让一份年龄很小的响应仍然不能直接返回。

对于共享缓存，s-maxage 覆盖 max-age，其数值既可能缩短，也可能延长适用寿命。stale-while-revalidate 并不是把旧响应重新变成新鲜，而是在策略与实现允许的条件下，一边验证一边有限使用陈旧副本。应把“允许服务旧内容”视为另一种状态，不要把所有宽限期都混进新鲜期的定义。

坏掉的样子

Age 很大，不自动证明发布出了问题。缓存寿命为一年的指纹资产，即使年龄很大也可能仍然新鲜。正文没有改变的表示，还可以在后来成功通过验证，只更新元数据而不替换字节。此后 Age 对应的是较新的验证历史，不一定反映这些字节最初被作者写出的时间，不能据此计算内容存在了多久。

同一 URL 的每次请求也不保证 Age 单调递增。请求可能到达不同边缘、选择不同表示、遇到条目淘汰，或经过成功的重新验证。Age 为零也可能来自刚缓存的响应；没有这个头，同样不能单独证明一定由源站直接应答。应对照匹配的请求、正文身份、验证器、Date、缓存策略和服务商诊断字段一起判断。

出现错误复用时，先区分是身份边界错了，还是寿命判断错了。年龄算得再准确，也修复不了缓存键遗漏币种或授权条件的问题。同样，缩短源站 max-age 不会追溯通知那些仍被认为新鲜的既有副本。应查看真正 GET 请求链路上的响应头；HEAD 可能有不同的实现路径，也不能告诉你实际交付了哪份正文。

快速验证

用 Python 3.11 或更新版本执行代码；本次使用 Python 3.14.4。只依赖标准库，HTTP 日期由 email.utils 负责解析和格式化。所有时间都是合成输入，不发起网络请求，不修改系统时钟，也无需睡眠。实验保证请求、接收和观察时间有序，Age 输入是合法非负整数；它不承担通用的畸形头字段解析职责。

from datetime import timedelta
from email.utils import format_datetime, parsedate_to_datetime

base = parsedate_to_datetime("Thu, 01 Jan 2026 00:00:00 GMT")


def at(seconds):
 return base + timedelta(seconds=seconds)


def current_age(headers, request_time, response_time, now):
 date_value = parsedate_to_datetime(headers["Date"])
 age_value = int(headers.get("Age", "0"))
 assert request_time <= response_time <= now and age_value >= 0
 apparent_age = max(0, (response_time - date_value).total_seconds())
 response_delay = (response_time - request_time).total_seconds()
 corrected_age_value = age_value + response_delay
 corrected_initial_age = max(apparent_age, corrected_age_value)
 resident_time = (now - response_time).total_seconds()
 return corrected_initial_age + resident_time


def headers(date_seconds, age=None):
 result = {"Date": format_datetime(at(date_seconds), usegmt=True)}
 if age is not None:
 result["Age"] = str(age)
 return result


cases = [
 ("Date estimate dominates", headers(0, 5), 10, 12, 20, 20),
 ("upstream Age dominates", headers(0, 50), 10, 12, 20, 60),
 ("future Date is clamped", headers(30, 5), 10, 12, 20, 15),
 ("Age absent means zero input", headers(0), 10, 12, 20, 20),
 ("after modeled validation", headers(100, 0), 100, 102, 105, 5),
]
for name, fields, sent, received, now, expected in cases:
 age = current_age(fields, at(sent), at(received), at(now))
 assert age == expected
 print(f"{name}: {age:g} seconds")

freshness_lifetime = 60
assert 45 < freshness_lifetime
assert not 60 < freshness_lifetime
print("lifetime=60: age 45 is fresh; age 60 is stale")

在第十二秒收到响应、第二十秒观察时，第一个案例返回二十，而不是二十七：基于 Date 的估计和校正估计描述了重叠时间，不能相加。把上游 Age 提高到五十后，请求延迟和本地驻留时间使最终结果为六十。即使 Date 在未来，表观年龄被截为零，上游年龄和已经经过的时间仍会让结果达到十五。

缺少 Age 的案例，仍然通过 Date 得到二十秒。模拟成功验证后的案例则使用新的响应元数据，得到五秒，而不是从先前生成时间起经过的一百零五秒。这并没有真的访问源站执行一次验证，只是在明确“已经成功验证”的前提下，检查后续元数据对应的年龄计算。

最后的断言把寿命为六十秒时的两个边界分开：四十五秒新鲜，六十秒陈旧。以上结果验证的是文中采用的算术步骤和边界，不是某个浏览器或 CDN 的实际 Age 生成逻辑，更不证明其路由、故障恢复或畸形字段处理行为。针对具体部署的结论，仍需要真实链路上的响应证据。

来源

RFC 9111：计算年龄，独立估计、请求延迟、驻留时间与保守校正，已核验 2026-09-07。
MDN：Age，头字段语法和非负秒数，已核验 2026-09-07。

Cache-Control：private 还是 shared

Fri, 23 Oct 2026 00:00:00 +0000

存储范围不是身份系统。Cache-Control: private 要求遵守协议的共享缓存不存储这条响应，却不会教会浏览器识别正文属于哪个应用账户。当一个人退出登录，另一个账户在同一浏览器中登录，然后访问相同网址时，这个区别就会变成实际的数据隔离问题，不能只凭响应头里出现 private 就判定安全。

有资格被缓存不代表能共享

不带字段名参数的 private 允许单用户缓存保存响应，但仍受其他缓存条件约束。浏览器是常见实现，并不是唯一实现。public 则明确允许某些原本可能受到限制的响应进入缓存，例如满足条件的带授权请求响应。已经符合缓存条件的普通响应不一定需要 public；出现 public 也不意味着所有缓存都必须保存它，存储许可和实际是否存储是不同事实。

不带参数的 no-cache 与 no-store 回答的是另一个问题。前者允许存储，但每次复用前必须成功验证；后者禁止私有和共享 HTTP 缓存存储及随后复用该响应。它们都不是加密、访问控制检查，也不承诺清除应用日志或用户之前保存的副本。本文讨论不带字段名参数的形式，不把实现支持较弱的按字段限定形式混进实验。

新鲜度还需要单独判断。错误的个人响应如果按共享键保存，即使只给五秒钟有效期，也可能有五秒钟把数据交给另一个人。缩短 max-age 不能修复身份边界。反过来，s-maxage 只是控制共享缓存的新鲜度，并不是 private 的另一种写法。先决定响应可在哪一层保存，再讨论可直接复用多久，才能避免用性能参数代替安全条件。

坏掉的样子

HTTP 的通用规则不会因为请求里有 Cookie 就自动禁止共享缓存。Authorization 确实有专门的共享缓存限制，但 public 等指令能够明确允许存储。为了提高命中率而添加 public，可能恰好撤掉应用之前依赖的限制。修改指令前应检查实际响应体和认证路径，不能只查看页面看起来是不是一份普通文档。

Vary 细化的是请求匹配条件，不授予存储许可。增加 Vary: Cookie 不会让 private 响应变得可以进入共享缓存。在私有缓存内，它可以区分不同 Cookie 字段，但这仍然只是字段匹配，不是授权判断。假设令牌文本没有变化，而账户权限已经被撤销，仅凭请求字段仍匹配，不能证明当前用户继续有权读取旧内容。

敏感账户数据需要明确的响应策略和账户切换测试，至少覆盖退出登录、同一浏览器配置中切换账户、权限发生变化。诊断记录也不应该包含真实凭据。只在源站检查到正确的 Cache-Control，还不能证明沿途每一个代理都遵守了它，部署后的响应正文与源站访问记录仍是必要证据。

快速验证

准备 Node.js 与 npm；本次实际使用 Node 26.0.0 和 http-cache-semantics 4.2.0。将固定版本安装到临时目录，然后使用 NODE_PATH="$cache_lab/node_modules" node 执行下面的 JavaScript。安装需要网络，实验本身不会发请求；其中的 Cookie 和 Authorization 值均为虚构文本，不对应任何真实账户或令牌。

cache_lab=$(mktemp -d)
npm install --prefix "$cache_lab" --ignore-scripts --no-audit --no-fund --package-lock=false http-cache-semantics@4.2.0

const assert = require("node:assert/strict");
const CachePolicy = require("http-cache-semantics");

const request = {
 url: "https://example.test/account",
 method: "GET",
 headers: { cookie: "account=alpha" },
};
const cases = [
 ["private, max-age=300", [false, false], [true, true]],
 ["public, max-age=300", [true, true], [true, true]],
 ["no-cache, max-age=300", [true, false], [true, false]],
 ["no-store, max-age=300", [false, false], [false, false]],
];
for (const [directive, sharedResult, privateResult] of cases) {
 for (const shared of [true, false]) {
 const policy = new CachePolicy(request, {
 status: 200,
 headers: { "cache-control": directive },
 }, { shared });
 const result = [policy.storable(),
 policy.storable() && policy.satisfiesWithoutRevalidation(request)];
 assert.deepEqual(result, shared ? sharedResult : privateResult);
 console.log(shared ? "shared" : "private", directive, result);
 }
}

const authorized = { ...request, headers: { authorization: "Bearer example" } };
for (const [directive, expected] of [
 ["max-age=300", false], ["public, max-age=300", true],
]) {
 const policy = new CachePolicy(authorized, {
 headers: { "cache-control": directive },
 }, { shared: true });
 assert.equal(policy.storable(), expected);
 console.log("authorized shared:", directive, expected);
}

const otherAccount = { ...request, headers: { cookie: "account=beta" } };
for (const vary of [false, true]) {
 const headers = { "cache-control": "private, max-age=300" };
 if (vary) headers.vary = "Cookie";
 const policy = new CachePolicy(request, { headers }, { shared: false });
 assert.equal(policy.satisfiesWithoutRevalidation(otherAccount), !vary);
 console.log("different cookie, Vary enabled:", vary, "reuse:", !vary);
}

每组结果依次表示“有资格存储”和“无需验证即可复用”。private 在共享模式下得到两项 false，在私有模式下得到两项 true；public 在两种模式中都得到两项 true。no-cache 可以存储但不能直接复用，no-store 则两项都不允许。代码有意先检查存储资格，调用方不能先把禁止存储的条目插入缓存，再希望后续查找逻辑补救这个错误。

Authorization 两项检查说明，明确加入 public 后，共享存储资格从 false 变成 true，但这不证明任何真实个人响应适合公开共享。最后两项只改变虚构 Cookie：没有 Vary 时，私有缓存中的旧条目仍能匹配；启用 Vary 后则不能匹配。这是 private 本身不会隔离应用账户的具体反例，而不是建议仅靠一个 Vary 字段完成安全设计。

本实验验证策略库，不代表已经验证浏览器、CDN 或退出登录实现。生产验收仍应使用两个不同账户，观察真实路径上的源站请求，并断言最终正文属于正确账户。先确定这项验收，再调整新鲜度或统计命中率，才能知道性能改善有没有越过数据边界。

来源

RFC 9111：响应缓存指令，存储范围、授权例外及带字段名参数的形式，已核验 2026-09-07。
MDN：Cache-Control，private、public、no-cache 与 no-store，已核验 2026-09-07。
http-cache-semantics 4.2.0，共享与私有模式、存储检查及请求匹配，已核验 2026-09-07。

缓存 · XB 现场笔记

dnsmasq 区分转发缓存与本地配置名称

坏掉的样子

快速验证

有意识地管理监听与数据来源

延伸阅读

来源

微缓存短暂复用新鲜条目，并显式合并并发未命中

坏掉的样子

快速验证

分别决定新鲜度与过载行为

延伸阅读

来源

DNS TTL 在重复回源查询与保留旧回答之间取舍

坏掉的样子

快速验证

依据真实需求选择寿命

延伸阅读

来源

Docker 构建缓存复用已记录的工作，也可能复用过期结果

坏掉的样子

快速验证

把新鲜度变成明确输入

延伸阅读

来源

nginx 验证器是否可靠，取决于表示身份是否准确

坏掉的样子

快速验证

让部署保持验证器契约

延伸阅读

来源

PostgreSQL 使用两层数据缓存

坏掉的样子

快速验证

为整个服务器分配内存

来源

Redis 的过期是截止时间，逐出是容量策略

时间与容量是两个独立维度

先确定候选范围，再讨论排序

坏掉的样子

快速验证

延伸阅读

来源

Cache-Control 是缓存与源站之间的约定

双方都要读同一份约定

坏掉的样子

快速验证

延伸阅读

来源

布隆过滤器能廉价地说一句“也许”

位图保存的是候选线索，不是记录

按预计元素规模分配空间

让表示的集合跟上权威数据

坏掉的样子

快速验证

延伸阅读

来源

缓存的新鲜度要对着时钟判断

先算清年龄

坏掉的样子

快速验证

延伸阅读

来源

缓存集中失效会放大回源工作

在真实边界内合并工作

错开时间不能改变新鲜度承诺

坏掉的样子

快速验证

延伸阅读

来源

LRU 缓存淘汰最久未用的条目

沿访问顺序找出淘汰对象

精确顺序与采样近似不是同一契约

容量约束不是新鲜度约束

坏掉的样子

快速验证

延伸阅读

来源

一致性哈希减少重新映射

先把归属区间画对