文章 · XB 现场笔记

InnoDB 死锁会回滚整个受害事务

Thu, 20 Apr 2028 00:00:00 +0000

当多个事务形成不兼容锁请求的等待环时，就发生 InnoDB 死锁。开启死锁检测后，引擎选择一个受害者，回滚它的整个事务，使其他参与者能够继续。应用收到错误 1213（SQLSTATE 40001）。若只重试报错的那条语句，就会漏掉同一事务中更早执行、但已经一起被回滚的工作。

坏掉的样子

不能给所有锁错误套用同一种回滚规则。默认关闭超时整笔回滚时，锁等待超时只撤销正在等待的那条语句，事务内此前执行的语句仍然待决。开启对应服务端选项后，超时才会改为回滚整个事务。死锁本来就会回滚整个受害事务，不能把默认超时的语句级行为误套在死锁上。

受害者选择也不保证某个固定会话永远输。应用必须检查真实错误，再以有界次数重试完整逻辑事务。不可逆的外部副作用如果没有单独去重契约，不应跟着数据库事务自动重放。提交回复途中连接断开，也不等于已经得到死锁回滚的确定结论；错误类型与已知事务结果需要分开判断。

快速验证

在可丢弃的 MySQL 8.4 实例上打开甲、乙和观察者三个全新管理客户端，先确认三个会话均处于自动提交模式，关闭客户端自动重新连接，保持会话身份稳定。本次实际执行版本是 MySQL 8.4.11。观察者先创建尚未使用的实验模式，并核对死锁检测开启、超时采用默认语句级回滚：

CREATE DATABASE xbcatm_deadlock_lab;
USE xbcatm_deadlock_lab;
CREATE TABLE accounts (id INT PRIMARY KEY, balance INT NOT NULL) ENGINE=InnoDB;
INSERT INTO accounts VALUES (1,100),(2,100);
SELECT @@innodb_deadlock_detect,@@innodb_rollback_on_timeout;

两个设置应分别为一和零。甲开始一项给两个账户各增加十的操作，先锁住第一个账户：

USE xbcatm_deadlock_lab;
SET SESSION innodb_lock_wait_timeout=30;
SET @increment=10;
START TRANSACTION;
UPDATE accounts SET balance=balance+@increment WHERE id=1;

乙开始一项各增加一百的操作，先锁住第二个账户：

USE xbcatm_deadlock_lab;
SET SESSION innodb_lock_wait_timeout=30;
SET @increment=100;
START TRANSACTION;
UPDATE accounts SET balance=balance+@increment WHERE id=2;

甲再请求乙持有的那一行，此时语句会等待：

UPDATE accounts SET balance=balance+@increment WHERE id=2;

在甲的三十秒锁等待超时之前，乙执行反向请求：

UPDATE accounts SET balance=balance+@increment WHERE id=1;

其中一个会话收到死锁错误，把实际报错者认作受害者；另一个更新则会完成。下面的提交只在幸存会话中执行：

COMMIT;

观察者检查已经提交的状态：

SELECT id,balance FROM accounts ORDER BY id;

如果甲幸存，两行均为一百一十；如果乙幸存，两行均为二百。受害者更早的更新也已经消失。本次运行选择乙为受害者，最后看到两行一百一十。在受害者原来的会话中，用户变量仍然记录该操作的原始增量；现在按一致顺序取得两行，重试完整操作：

SELECT @increment;
START TRANSACTION;
UPDATE accounts SET balance=balance+@increment WHERE id=1;
UPDATE accounts SET balance=balance+@increment WHERE id=2;
COMMIT;

观察者核对组合结果：

SELECT id,balance FROM accounts ORDER BY id;

两行都必须变成二百一十。接下来对照锁等待超时。观察者先重置实验数据：

UPDATE accounts SET balance=100;

甲持有第一行的写锁：

START TRANSACTION;
UPDATE accounts SET balance=balance+1 WHERE id=1;

乙修改第二行，并设定较短等待时间：

SET SESSION innodb_lock_wait_timeout=1;
START TRANSACTION;
UPDATE accounts SET balance=balance+5 WHERE id=2;

仍在乙中请求甲持有的行：

UPDATE accounts SET balance=balance+5 WHERE id=1;

这次得到 1205（SQLSTATE HY000）锁等待超时错误，而不是死锁错误。乙检查自己事务里仍然待决的工作：

SELECT id,balance FROM accounts ORDER BY id;

乙读到一百和一百零五；观察者却仍然看到已提交的一百和一百：

SELECT id,balance FROM accounts ORDER BY id;

超时没有撤销乙此前增加的五。现在显式丢弃剩余事务，先在乙回滚：

ROLLBACK;

再在甲回滚：

ROLLBACK;

最后由观察者确认原始余额，并删除实验模式：

SELECT id,balance FROM accounts ORDER BY id;
DROP DATABASE xbcatm_deadlock_lab;

这项验证通过真实数据值区分回滚范围，而不只是相信错误消息里的文字。遇到不符合预期的结果就停止，先回滚仍然打开的实验事务，再进行清理。特别是超时之后不要直接提交残余操作，否则可能把业务操作的一部分留下，却误认为整笔工作已经失败并全部撤销。

减少等待环，但不假定它们消失

对共同业务资源采用一致的取得顺序，缩短事务，并使用合适索引，避免锁住超出操作需要的记录。范围操作与二级索引维护，还可能引入这个双主键行例子之外的锁交互。一致顺序能够减少已经识别的等待环，但不能证明所有可能的死锁都被移除，也不能替代错误发生之后的正确恢复逻辑。

可以通过引擎状态查看最近一次检测到的死锁；如果事件频率需要更长历史，应配置相应采集。把涉及的语句和锁顺序关联回完整应用事务，不要只盯着最后那条报错语句。重试应该在截止时间和尝试次数约束下重新执行完整工作，同时区分超时语义。最终还要核对业务结果，避免仅因为最后一次语句没有报错，就认为逻辑操作已经完整恢复。

来源

MySQL 8.4 InnoDB 错误处理，死锁整笔回滚与可配置的超时回滚范围，已核验 2026-09-12。
MySQL 8.4 死锁示例，复现等待环并检查实际受害者，已核验 2026-09-12。
MySQL 8.4 InnoDB 锁，并发操作涉及的记录锁与范围锁，已核验 2026-09-12。

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。

LVM 快照在时间上定格一块块设备

Mon, 10 Apr 2028 00:00:00 +0000

LVM 快照既不是拷贝，也不是 reflink：它是一个挂在源逻辑卷上的、大小固定的写时复制异常存储。lvcreate -s -L 5G -n snap vg/data 从卷组里划走 5 GiB，之后 device-mapper 的 snapshot 目标会在某个源 chunk 第一次被写时，把它的原始内容记录下来。无论源卷多大，创建都是瞬时的，因为创建时什么都没复制。

这个大小就是你全部的安全余量，也正是最常被写错的参数。按“一周内没什么写入”配的存储，会被一次数据库 checkpoint 或一次 rsync 在一小时内吃光；而它填满时快照不会降级，而是直接失效并开始返回 I/O 错误。恢复点恰好在你最需要它的那一刻消失，所以存储的剩余空间该进监控面板，而不是躺在 runbook 里。

异常存储，不是副本

一个经典的 LVM 快照用到两个 device-mapper 目标：源卷被重新映射为 snapshot-origin，另有一个新的 snapshot 设备把它与 COW 设备组合起来。读未改动的 chunk 直接落到源卷；某个 chunk 第一次被写时，旧 chunk 被复制进 COW 设备，然后新数据才写下去。所以消耗量跟“发生过改动的不同 chunk 数”成正比，而不是跟写入次数成正比：fixture 往 16 个热 chunk 写了一百万次，只消耗 15 个异常，约 60 KiB。

用 lvs -a -o lv_name,lv_attr,origin,data_percent,lv_size 观察它。经典快照的 lv_attr 是 swi-a-s---：s 表示快照、w 表示可写，而状态位在存储耗尽时会变成 I。data_percent 是存储的填充度，这才是该告警的数字，阈值取 70% 或 80%；100% 不是警告，是讣告。--chunksize 决定异常存储的粒度：粒度越大，块映射表的元数据越省，但每一次改动要拷贝的旧数据也越多。快照还有效时可以用 lvextend 扩容 COW 设备；lvchange --monitor y 则让 dmeventd 自动做这件事。

耗尽即失效

内核文档说得很直白：COW 设备往往比源卷小，一旦填满，快照就变得无用并被禁用，开始返回错误。LVM 给出的容量经验是按预期写入量规划——常常取源卷的 20%——并在填满之前扩容。另外，存储里有一小块要用来存放 COW 块映射表，所以可用于数据的容量略小于 -L 的数值。

影响范围很窄，但时机很残忍：源卷照常运行，所以在读取该快照的备份任务失败之前，或者在你要用的那次回滚已经不可用之前，看不出任何异常。它没有中间状态：到了 100%，正确的心理模型是这份快照从未存在过。

合并回滚，以及 thin 如何改变失败形态

lvconvert --merge vg/snap 把快照中改动过的 chunk 合并回源卷，合并在后台进行，期间源卷仍然可用——对尚未合并的 chunk 的写入会被推迟。约束在源卷一侧：建立合并时它必须处于非活动状态，所以要么先卸载，要么先安排合并、之后再激活源卷。合并只对持久化快照有效，临时快照走不了这条路；合并会消耗掉这份快照，所以需要的东西先拷出来。

thin 快照改变的是失败形态，而不是消除失败。当源是 thin LV 且不给大小时，创建出来的就是 thin 快照；它共享 thin 池里的块，而不拥有自己的存储，所以它自身的分岔无法让它失效。此时共享资源变成了池：池一旦耗尽，坏掉的不是一份快照，而是池里所有 thin 卷，而 LVM 明确警告池可能因此损坏、且难以甚至无法修复。thin_pool_autoextend_threshold 与 dmeventd 的存在，正是因为池耗尽是一次池级事故。

坏掉的样子

最经典的是“备份悄悄不再是备份”。任务挂载快照开始拷贝，拷贝耗时超过了存储能覆盖的时长，存储在某刻到达 100%；快照随即失效，拷贝失败——更糟的情况是，监控只看任务的退出码，而任务读的早就是一个过期的挂载点。所以要盯每一个快照 LV 的 data_percent，70% 就告警，并且按保留窗口内最忙的那一小时来定容量，而不是按平均值。

第二种是“要用的时候合并不了”。lvconvert --merge 要求源卷处于关闭状态，而团队往往是在事故当中才发现这一点。合并开始后由 snapshot-merge 目标接管源卷，dmsetup status 里的已分配扇区数会持续下降，降到只剩元数据就表示合并完成。先在一个一次性卷上演练合并，另留一份不依赖快照的真实备份，并记住：存储已满的快照根本无法合并。

快速验证

在信任这份快照之前，先看存储的填充度：

lvs -a -o lv_name,vg_name,lv_attr,origin,data_percent,lv_size
lvs -a -o lv_name,data_percent,metadata_percent vg/thinpool
dmsetup status vg-snap
lvextend -L +2G vg/snap

data_percent 就是 COW 存储的填充度，健康的快照应当远低于 100；lv_attr 里出现状态位 I 说明快照已经失效。对 thin 快照而言，该看的是池上的 data_percent 与 metadata_percent；dmsetup status 会给出已分配扇区与总扇区之比，可以据此实时观察一次合并把扇区数排空的过程。

来源

lvcreate(8)，说明 -s/--snapshot、COW 与 thin 快照的区别以及容量建议，已核验 2026-09-16。
lvs(8)，定义 lv_attr 状态位，含无效快照，已核验 2026-09-16。
Device-mapper snapshot 支持，异常存储、失效语义与 lvconvert --merge 行为，已核验 2026-09-16。
lvmthin(7)，thin 快照、池耗尽与自动扩容，已核验 2026-09-16。

Consul 维护一份存活的健康服务清单

Thu, 06 Apr 2028 00:00:00 +0000

服务注册表的价值完全取决于它有多诚实。Consul 把注册的实例收进 catalog，并给它们挂上健康检查，于是「某个服务的健康实例在哪」这个问题的答案会随现实变化。注册本身很简单；检查才是全部的产品价值，因为一份列出死实例的注册表比静态清单更糟——它会主动把流量送进坑里。

这个答案的新鲜程度，取决于两个第一周之后没人再看的选择：检查多久跑一次，以及它到底测的是什么。每 30 秒跑一次的检查会瞎 30 秒；只证明进程存在的检查则永远瞎着。

注册，以及两个层级的检查

实例通过配置文件或注册 API 登记名字、地址、端口以及一条或多条检查。检查默认以 critical 状态起步，这是刻意的：在健康至少被验证过一次之前，服务无法进入可用池——想要初始就是 passing，必须显式写出来。检查的状态由它自己判定：脚本检查按退出码决定（0 为通过、非 0 为 critical），HTTP 检查按响应码决定，输出超过 4KB 会被截断，脚本检查默认 30 秒超时。也就是说，「检查通过」这几个字的含义完全取决于你写的那条命令。

同一台节点上有两个层级的检查。serfHealth 这样的节点级检查服务名为空，描述的是这台机器；service:web-1 这样的服务级检查绑定在某一条注册上。它们各自独立失败，但只取健康的过滤器要求节点上所有检查都通过，所以节点级检查变 critical 会一次带走这台机器上的所有服务，而服务级检查变 critical 只移除一个实例。

调用方实际拿到什么

catalog 会回答两个不同的问题。不加过滤时，/v1/health/service/web 返回全部注册以及每条检查的状态；加上 passing=true 时，只返回所有检查都通过的实例。DNS 与 SRV 永远按第二种方式回答，所以解析器不会拿到一个不能用的名字，而这个通过集合就是负载均衡池。

catalog 同时也是最终一致的，机制叫反熵。注册是即时的——agent 会通知 leader——但修复是周期性的：每个 agent 按一个间隔把自己的本地状态与 catalog 对齐，128 个节点以内的集群是 1 分钟，随集群规模增长而变长，并且每个 agent 的起始时间都会错开，以免所有人同时同步。同步失败只会被记进日志、等下一个周期重试，所以一条错误的 catalog 记录可以安静地存活长达一个间隔。读路径也有自己的取舍：默认情况下 agent 会把 catalog 读请求转发给 leader，并用一个假定领导地位短期稳定的 leader lease，因此很快但偶尔可能返回陈旧结果；consistent 模式要求 leader 先向多数派确认自己仍是 leader，stale 模式则允许任何 server 不做检查就回答。这三档没有对错，只有你愿意为一个多新的答案付出多少延迟。

坏掉的样子

第一种故障就是间隔本身。检查的新鲜度不会超过它的周期，所以一个在探测刚通过之后立刻死掉的服务，会一直留在轮换里直到下一次探测——30 秒的检查是 30 秒，60 秒的检查就是 60 秒。TTL 检查比慢间隔更糟，因为它是被动的：实例按自己的节奏上报，所以一个 TTL 为 120 秒的死实例会把 passing 状态保持满 120 秒。

第二种故障是检查回答了错误的问题。一个对进程跑 pgrep 的脚本会在整个死锁期间报告 passing——进程在、端口在监听，而每一条被路由过去的请求都挂住。catalog 无法把这种实例和健康实例区分开，所以对池子里的每个调用方来说，故障都是静默且彻底的。真正去探一次依赖的检查哪怕不完美，也会在一个间隔内收敛到真相；只探存活的检查永远不会。错误的代价还取决于方向：该通过却失败的检查会摘掉健康实例、白白损失容量；该失败却通过的检查则持续把流量喂给一个服务不了的东西，调用方只能从自己的错误率里发现。

快速验证

对比过滤与未过滤两个视图，并看看 DNS 发出去的是什么：

consul catalog services
consul health service web
curl -s 'http://127.0.0.1:8500/v1/health/service/web' | jq -r '.[] | "\(.Service.ID) \(.Checks[] | select(.Status!="passing") | .CheckID + "=" + .Status)"'
curl -s 'http://127.0.0.1:8500/v1/health/service/web?passing=true' | jq -r '.[] | "\(.Service.ID) \(.Node.Address):\(.Service.Port)"'
dig +short SRV web.service.consul

在未过滤结果里带着失败 CheckID 出现的实例，必须同时从 passing=true 列表和 SRV 应答里消失；如果它还在，说明这条检查根本没有被求值。节点级检查为 critical 的机器会从两个列表里整体消失，连带它上面的所有服务。

来源

Service discovery，catalog、注册与健康检查的角色，已核验 2026-09-16。
Health checks，检查类型、间隔与默认的 critical 初始状态，已核验 2026-09-16。
Health HTTP API，/v1/health/service 与 passing 过滤器，已核验 2026-09-16。
Anti-entropy，周期性同步间隔与其失败行为，已核验 2026-09-16。

调度器计算资源请求，而不是瞬时使用率

Sun, 02 Apr 2028 00:00:00 +0000

Kubernetes 调度判断的是 Pod 在资源请求和其他放置约束下是否适合某个节点，不是简单查看当前 CPU 曲线，然后把任务塞进看起来最空闲的位置。请求为未来需求提供记账输入，实际使用率则是另一种观测。决定一个表面空闲的集群是否有能力容纳特定 Pod 之前，需要同时理解两者，不能让其中一个指标替代全部容量判断。

以准入后的真实配置为依据

对于普通应用容器，调度器在判断节点是否容纳 Pod 时，会计算它们的请求。初始化需求、Pod 额外开销以及受支持的 Pod 级资源配置，也可能影响有效请求。最终经过准入的 Pod 才是实际输入，包括默认值和修改结果，而不只是操作者记得提交的源文件。排查时应读取保存下来的对象，确认控制面实际看到什么。

Node allocatable 也不同于硬件总容量，它表示按照节点配置可以提供给 Pod 的资源量。其他工作负载即使暂时空闲，其资源请求仍然占用调度记账中的空间。不过，请求并不表示应用已经实际分配了同样多的物理内存，也不表示独占相应数量的 CPU 核心。放置记账、实时消耗和独占策略属于不同机制，不能混用“预留”一词解释。

限制通过执行栈约束运行中的工作负载，通常不会在调度检查时替代已经显式填写的较小请求。因此，一个容器的 CPU limit 可以大于单个节点 CPU 容量，同时仍然凭较小 request 完成调度。这个被接受的限制不会制造额外处理器，也不承诺进程一定能够达到填写的上限；它只是配置了允许使用的边界。

坏掉的样子

Pending 可能源于请求资源不足，也可能由污点、亲和性、存储、拓扑或其他条件阻塞。改变资源值之前，应查看 PodScheduled 条件和调度事件。降低请求无法修复不匹配的节点选择器或不可用的卷；如果原请求本来真实，盲目降低还可能把调度失败转化成运行期争用，并没有建立合理容量方案。

默认值让省略字段尤其容易误读。填写 limit 而不填 request，且没有准入机制提供另一默认请求时，Kubernetes 会把该资源限制复制为请求。因此，只设置一个很大的 limit，也可能形成很大的调度需求。应查看实际对象中的两个映射，并考虑 LimitRange 的影响，再解释放置失败，不能假定省略请求就等于完全没有记账成本。

API 还会拒绝请求大于对应限制的配置。这属于准入校验失败，不是调度器在判断集群容量。区分这两个阶段，可以解释为什么一份清单根本无法创建 Pod，而另一份会创建可检查的对象，只是暂时没有分配节点。错误发生位置不同，修复所需证据也不同，不应统一归因于资源不足。

QoS 也不是免疫承诺。在传统每容器规则下，Guaranteed 要求所有相关容器同时具有 CPU 和内存请求与限制，并且分别相等。只让内存相等并不足够。即使类别为 Guaranteed，也可能遇到资源失败，不能用类别代替优先级、容量规划、应用正确性或实际节点压力分析。选择请求应考虑负载证据和故障代价，而不是追求某个标签。

快速验证

准备至少包含一个 Ready、没有污点工作节点的临时 Kubernetes 集群，确保 kubectl 可用，节点已有 python:3.11-slim-bookworm 镜像。保存为 request-placement.py，执行 python3 request-placement.py KUBECONFIG_PATH CONTEXT，明确指定测试参数。账号需要创建、删除命名空间。实测服务端为 Kubernetes 1.34.11，所选节点报告可分配十个 CPU。

import json
import subprocess
import sys
import time
from uuid import uuid4

assert len(sys.argv) == 3, 'usage: python3 example.py DISPOSABLE_KUBECONFIG CONTEXT'
base = ['kubectl', '--kubeconfig', sys.argv[1], '--context', sys.argv[2], '--request-timeout=30s']
image = 'python:3.11-slim-bookworm'


def k(*args, payload=None, expected=0):
 result = subprocess.run(base + list(args), input=json.dumps(payload) if payload is not None else None,
 capture_output=True, text=True, timeout=150)
 if expected is not None:
 assert result.returncode == expected, result.stderr
 return result


def obj(namespace, kind, name=None, selector=None):
 args = ['get', kind, '-n', namespace, '-o', 'json']
 if name:
 args.append(name)
 if selector:
 args += ['-l', selector]
 return json.loads(k(*args).stdout)


def apply(namespace, data):
 return k('apply', '-n', namespace, '-f', '-', payload=data)


def wait_for(read, ready, seconds=120):
 until = time.monotonic() + seconds
 while time.monotonic() < until:
 value = read()
 if ready(value):
 return value
 time.sleep(0.5)
 raise AssertionError('expected Kubernetes condition did not arrive')


def pod_ready(pod):
 return any(c['type'] == 'Ready' and c['status'] == 'True'
 for c in pod.get('status', {}).get('conditions', []))


def spec(script='import time; time.sleep(600)'):
 return {'automountServiceAccountToken': False, 'terminationGracePeriodSeconds': 1,
 'containers': [{'name': 'app', 'image': image, 'imagePullPolicy': 'IfNotPresent',
 'command': ['python3', '-c', script],
 'resources': {'requests': {'cpu': '10m', 'memory': '24Mi'},
 'limits': {'cpu': '200m', 'memory': '96Mi'}}}]}

from decimal import Decimal, ROUND_CEILING

def cpu_quantity(value):
 return Decimal(value[:-1]) / 1000 if value.endswith('m') else Decimal(value)

namespace = 'notes-requests-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 workers = [n for n in obj(namespace, 'nodes')['items'] if
 not n['spec'].get('unschedulable') and not n['spec'].get('taints')
 and any(c['type'] == 'Ready' and c['status'] == 'True' for c in n['status']['conditions'])]
 assert workers, 'a Ready worker without taints is required'
 worker = workers[0]
 allocatable = cpu_quantity(worker['status']['allocatable']['cpu'])
 too_large = str(int(allocatable.to_integral_value(rounding=ROUND_CEILING)) + 1)
 for name, request in [('burst', '10m'), ('oversized', too_large)]:
 podspec = spec()
 podspec['nodeSelector'] = {'kubernetes.io/hostname': worker['metadata']['labels']['kubernetes.io/hostname']}
 podspec['containers'][0]['resources'] = {
 'requests': {'cpu': request, 'memory': '24Mi'}, 'limits': {'cpu': too_large, 'memory': '96Mi'}}
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': name}, 'spec': podspec})
 burst = wait_for(lambda: obj(namespace, 'pod', 'burst'), pod_ready)
 assert burst['spec']['nodeName'] == worker['metadata']['name']
 def insufficient(p):
 return any(c['type'] == 'PodScheduled' and c['status'] == 'False'
 and c.get('reason') == 'Unschedulable' and 'Insufficient cpu' in c.get('message', '')
 for c in p.get('status', {}).get('conditions', []))
 pending = wait_for(lambda: obj(namespace, 'pod', 'oversized'), insufficient)
 assert pending['status']['phase'] == 'Pending' and not pending['spec'].get('nodeName')
 only_limit = spec()
 only_limit['containers'][0]['resources'] = {'limits': {'cpu': '200m', 'memory': '64Mi'}}
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'defaulted'}, 'spec': only_limit})
 defaulted = wait_for(lambda: obj(namespace, 'pod', 'defaulted'), pod_ready)
 resources = defaulted['spec']['containers'][0]['resources']
 assert resources['requests'] == resources['limits'] == {'cpu': '200m', 'memory': '64Mi'}
 assert defaulted['status']['qosClass'] == 'Guaranteed'
 invalid = spec()
 invalid['containers'][0]['resources'] = {'requests': {'cpu': '200m'}, 'limits': {'cpu': '100m'}}
 denied = k('create', '-n', namespace, '-f', '-', payload={
 'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'invalid'}, 'spec': invalid}, expected=None)
 assert denied.returncode != 0 and 'must be less than or equal to cpu limit' in denied.stderr
 print(json.dumps({'node_allocatable_cpu': str(allocatable), 'limit_cpu': too_large,
 'small_request_with_large_limit_scheduled': True,
 'larger_than_node_request_pending': True,
 'limit_only_defaulted_resources': resources,
 'defaulted_qos': defaulted['status']['qosClass'],
 'request_above_limit_rejected': True}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

程序用 nodeSelector 指向该工作节点，仍让调度器负责实际分配。两个对照 Pod 的 CPU limit 都是十一核。第一个只请求十毫核，最终在指定节点 Ready；第二个请求十一核，保持 Pending，没有 nodeName，PodScheduled 报告 Unschedulable，并包含 Insufficient cpu。两者的程序都只空闲等待，没有真的尝试消耗十一核。

第三个 Pod 只填写 200m CPU 与 64Mi 内存限制。存储对象中出现完全相同的请求，实际 QoS 类别为 Guaranteed。第四个尝试请求 200m，却限制为 100m，被 API 拒绝。全部断言通过，命名空间随后删除。这些真实对象分别展示了成功放置、调度拒绝、默认填充和结构校验，而不是只计算一张假想容量表。

实验没有测量真实峰值容量、资源管理器独占行为或所有调度插件。生产请求需要从工作负载证据出发，把实际准入需求与使用量共同审阅，不能将一张空闲曲线或熟悉的请求比例当成放置保证，也不能把 kind 节点报告的容量直接当作生产机器基准。

来源

Kubernetes: Resource Management，基于请求的放置、限制及准入默认值，已核验 2026-09-13。
Kubernetes: Pod Quality of Service Classes，Guaranteed 条件及服务质量保护的边界，已核验 2026-09-13。

Baggage 通过明确的边界传播上下文

Mon, 27 Mar 2028 00:00:00 +0000

OpenTelemetry 的 Baggage 是与上下文关联的一组字符串键值，可以让请求入口已经知道的信息继续到达下游，例如部署区域或发布分组。它与跨度属性不同，主要用途是传播；它也与链路上下文不同，承载的是应用选择的信息，而不是连接跨度的身份标识和标志。这些机制可以一起出现在一个请求里，但不能因此把它们理解为同一份数据，也不能假定它们具有相同的存储和信任语义。

跨进程传播必须落实到具体边界。发送客户端把上下文注入 HTTP 请求头等载体，接收端再从载体中提取成本地上下文。配置正确的插桩库可以自动执行这些动作，手工插桩时则要明确调用。仅在一个进程中创建行李字段，并不会把信息自动送到另一个进程、任意后台任务或外部服务。判断传播是否成功，应检查真实客户端与接收端，而不是只检查入口是否调用过设置函数。

决定哪些信息可以传播、哪些需要记录

行李字段不会自动成为跨度、日志或指标的属性。下游必须显式读取并复制，或者使用配置好的处理器执行这一映射策略。团队如果只打开传播，就期待在查询后台找到对应属性，通常会遇到数据看似消失的问题。反过来，把所有入站字段无差别复制进遥测，也可能造成语义不清、数据过大或指标基数增长。传播和记录是两个独立决定，应当分别明确目的与范围。

上下文操作返回新的上下文，不会把所有既有引用同时修改。调用者需要保留返回值，并在预期的位置传递或附加它。为某个出站请求删除不合适的行李字段时，也应保留该请求仍然需要的链路上下文。出站字段允许列表和遥测属性允许列表都应当是明确策略：某个接收者需要的值，不一定适合随后经过的全部目的地，更不一定适合永久写入所有观测记录。

坏掉的样子

行李上下文本身没有内置机制，能够证明某个值确实由可信组件签发。调用方完全可以提交请求头，自称属于昂贵账户等级或拥有特权角色。解析成功只能说明数据表示可被读取，不能说明其声明具有授权效力。认证与权限判断必须依赖各自可信的输入。即使字段很短、内容看起来合理，也不能跳过信任来源判断；本地解析器接受字符串，不等于业务系统应该接受其中的身份声明。

不受限制的行李字段会增加请求头大小，也可能把敏感信息传播给原本不该接收它的对象，包括自动插桩所覆盖的第三方接口。需要限制键名与值的范围，检查实际传播目的地，并由传播器负责线上编码。两个相同 SDK 实例之间往返成功，也不等于所有语言实现和代理组合都能够互操作。真正跨服务使用时，应验证实际途经的边界，而不是把一个进程内的演示扩大成对整个部署的保证。

快速验证

建立 Python 虚拟环境，安装 opentelemetry-sdk==1.35.0，把脚本保存为 baggage.py，并使用该环境的解释器运行。本次实际使用 Python 3.14.4。实验调用真实的 W3C 链路上下文传播器和行李传播器，并把跨度导出到内存；没有启动 HTTP 服务，字典代表客户端接下来将发送的请求头载体。因此结果直接证明编解码与上下文行为，不把尚未执行的跨服务通信写成已完成验证。

import json

from opentelemetry import baggage, trace
from opentelemetry.context import Context
from opentelemetry.baggage.propagation import W3CBaggagePropagator
from opentelemetry.propagators.composite import CompositePropagator
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import SimpleSpanProcessor
from opentelemetry.sdk.trace.export.in_memory_span_exporter import InMemorySpanExporter
from opentelemetry.trace.propagation.tracecontext import TraceContextTextMapPropagator

base = Context()
raw = baggage.set_baggage("region", "eu-west", context=base)
raw = baggage.set_baggage("release", "canary/2", context=raw)
raw = baggage.set_baggage("internal_note", "synthetic-only", context=raw)
assert not baggage.get_all(base)
propagator = CompositePropagator([TraceContextTextMapPropagator(), W3CBaggagePropagator()])
provider = TracerProvider()
exporter = InMemorySpanExporter()
provider.add_span_processor(SimpleSpanProcessor(exporter))
tracer = provider.get_tracer("baggage-lab")
with tracer.start_as_current_span("parent", context=Context()) as parent:
 outgoing = trace.set_span_in_context(parent, baggage.clear(context=raw))
 for key in ("region", "release"):
 outgoing = baggage.set_baggage(key, baggage.get_baggage(key, raw), context=outgoing)
 carrier = {}
 propagator.inject(carrier, context=outgoing)
 received = propagator.extract(carrier, context=Context())
 assert set(baggage.get_all(received)) == {"region", "release"}
 assert baggage.get_baggage("region", received) == "eu-west"
 assert baggage.get_baggage("internal_note", raw) == "synthetic-only"
 assert trace.get_current_span(received).get_span_context().trace_id == parent.get_span_context().trace_id
 with tracer.start_as_current_span("inherited", context=received):
 pass
 with tracer.start_as_current_span("copied", context=received) as span:
 span.set_attribute("deployment.region", baggage.get_baggage("region", received))
assert provider.force_flush()
spans = {span.name: span for span in exporter.get_finished_spans()}
assert not spans["inherited"].attributes
assert spans["copied"].attributes == {"deployment.region": "eu-west"}
independent = propagator.extract({"traceparent": "invalid", "baggage": "region=eu-west"},
 context=Context())
assert not trace.get_current_span(independent).get_span_context().is_valid
assert baggage.get_baggage("region", independent) == "eu-west"
untrusted = propagator.extract({"baggage": "tier=gold"}, context=Context())
assert baggage.get_baggage("tier", untrusted) == "gold"
print(json.dumps({"wire_fields": sorted(carrier),
 "wire_baggage": carrier["baggage"],
 "automatic_span_attributes": dict(spans["inherited"].attributes),
 "explicit_span_attributes": dict(spans["copied"].attributes),
 "baggage_survives_invalid_traceparent": True,
 "caller_supplied_tier_was_parsed": True}, indent=2))
provider.shutdown()

原始上下文包含区域、发布分组和一条完全虚构的内部备注。出站上下文只保留前两个字段，同时携带原父跨度。接收后区域应为 eu-west，发布值 canary/2 经过请求头编码后还原一致。断言还检查了筛选过程没有删除原上下文中的备注，也没有改变最初的空上下文。这说明清理出站载体与修改其他引用不是同一件事，后续代码必须使用正确的上下文对象。

两个子跨度进一步展示记录边界：inherited 收到行李上下文，但属性仍然为空；copied 只有显式设置的部署区域属性。另一个输入故意带有无效 traceparent，此时链路上下文无效，但独立编码的行李仍然可以解析。最后，调用方自称 tier=gold 的字符串也会被正常读取，过程中没有身份校验。把这套策略用于真实服务之前，还应检查客户端插桩、接收端提取、出站筛选和目标后台的属性映射，逐一确认实际行为与团队约定一致。

来源

OpenTelemetry baggage，行李上下文独立于遥测属性，且没有内置完整性保证，已核验 2026-09-13。
W3C Baggage，HTTP 表示、值编码与传播限制，已核验 2026-09-13。
W3C Trace Context，链路身份与应用行李上下文分别传播，已核验 2026-09-13。

TCP backlog 收纳还在握手中的连接

Fri, 24 Mar 2028 00:00:00 +0000

一个监听中的 TCP 套接字有两个队列，不是一个；而本文标题里那个 sysctl 管的，恰恰是几乎从不丢东西的那一个。传给 listen(2) 的 backlog 是 accept 队列，装的是已经完成握手、正等应用来取走的连接；SYN 队列装的才是半开请求。把两者混为一谈，就会开错药方。

这件事值得掰开，因为那句著名的建议——把 tcp_max_syn_backlog 调大——基本已经过时。tcp_syncookies 默认就是 1，而按 listen(2) 的说法，一旦启用 syncookies，SYN 队列就没有逻辑上的长度上限，这个设置会被忽略。真正会卡住你的是 accept 队列，以及应用调用 accept() 的速度。

backlog 参数管的是 accept 队列

listen(2) 明确写着，这个行为在 Linux 2.2 就变了：backlog 现在指的是「已完成建立、正等待被 accept 的套接字队列长度」，而不是半开请求的数量。半开队列由 /proc/sys/net/ipv4/tcp_max_syn_backlog 单独限制。而如果 backlog 参数超过 /proc/sys/net/core/somaxconn，它会被静默截断到那个值——Linux 5.4 之后是 4096，之前是 128。所以在默认配置的机器上写 listen(8192)，实际拿到的是 4096，而且不会有任何日志告诉你。

tcp(7) 把 tcp_max_syn_backlog 描述为「尚未收到对端确认的排队连接请求上限」：默认 256，内存达到 128 MB 及以上时升到 1024，低于 32 MB 时降到 128。ip-sysctl 补上了真正重要的限定：它是 per-listener 的限制，每个半开请求套接字大约占 304 字节，而 tcp_syncookies 默认为 1——队列溢出时发一个 cookie，而不是把请求丢掉。

syncookies 开着的时候，SYN 队列就不再是瓶颈

ip-sysctl 把 tcp_syncookies 记录为一种兜底手段，并明确说不能用它去帮一台高负载服务器扛合法的连接吞吐；它还指出 syncookies 严重违反 TCP 协议、无法使用 TCP 扩展，并可能让某些服务明显劣化。listen(2) 更进一步：启用 syncookies 时没有逻辑上的长度上限，tcp_max_syn_backlog 被忽略。而 tcp(7) 仍然把同一个旋钮描述为「超过就开始丢弃请求」——那是 syncookies 关掉时的行为。两页手册各自都说对了，只是说的是不同配置。另外 ip-sysctl 注明，syncookies 只在编译时启用了 CONFIG_SYN_COOKIES 的内核上有效，所以它并不是一个必然存在的兜底。

所以诚实的结论是：让 syncookies 保持 1，别再折腾 SYN 队列。代价是这条兜底路径救回来的连接会失去窗口缩放、SACK 这类 TCP 扩展，属于吞吐问题而不是连通性问题。如果你在合法流量下看到 SYN flood 告警，ip-sysctl 自己的建议是去调别的旋钮，而不是关掉 syncookies。

压力真正落在 accept 队列上

SYN 队列被中和之后，会满的是 accept 队列，它的容量是 min(listen(backlog), somaxconn)。溢出时的行为取决于 tcp_abort_on_overflow，默认是 FALSE：ip-sysctl 说默认值意味着「如果溢出只是突发造成的，连接会恢复」，并警告打开这个开关会伤害你的客户端。机制才是意外之处：默认情况下内核会静默丢弃最后一个 ACK，于是客户端的 connect() 成功返回，故障要等到第一个请求卡住或被重置时才浮现。之所以说默认值「能恢复」，是因为服务端随后还会按自己的节奏重传 SYN-ACK：只要在它放弃之前队列里腾出位置，这条连接就能被救回来。这也正是它无声的原因——客户端那边从头到尾都认为自己已经连上了。

更大的 backlog 是延迟线，不是容量。在模型里，listen(128) 和 listen(65535) 一秒内 accept 的连接数完全一样，都是 20,000；更大的队列只是把溢出的时刻往后推，因为 accept 速率由 worker 数量决定。

坏掉的样子

第一种故障是无声的那种，而且它就是默认行为。accept 循环太慢的服务会把 accept 队列挤满，内核丢掉最后的 ACK，客户端看到的是「连接建立了，然后就挂着」。没有任何东西被拒绝，于是客户端的连接池里堆满死套接字，报错最终出现在一个看起来无关的层面。盯住 TcpExtListenOverflows 和 TcpExtListenDrops：这两个计数器上涨而 accept 速率平稳，说明瓶颈在处理线程。

第二种故障是被丢弃的 SYN，只有在 syncookies 关掉时才会发生。SYN 队列满了就丢请求，客户端按重传时间表重试，文档给出的两个端点是「最后一次重传到 67 秒、最终超时到 131 秒」，所以用户看到的现象是一次挂了两分多钟才失败的连接。在这种配置下调大 tcp_max_syn_backlog 是真正的修法，而把 syncookies 重新打开是更好的修法——前提是你接受 TCP 扩展的损失。

快速验证

ss -lnt 'sport = :8443'
nstat -az TcpExtListenOverflows TcpExtListenDrops TcpExtTCPReqQFullDrop TcpExtTCPReqQFullDoCookies
sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog net.ipv4.tcp_syncookies net.ipv4.tcp_abort_on_overflow

在 ss -lnt 里，Send-Q 是这个套接字创建时的 backlog，Recv-Q 是已经建立但还没被 accept 的连接数；Recv-Q 顶到 Send-Q 就是队列满了。nstat 的几个计数器应该为零或接近零：TcpExtListenOverflows 和 TcpExtListenDrops 属于 accept 队列事件，TcpExtTCPReqQFullDrop 是被丢掉的 SYN，TcpExtTCPReqQFullDoCookies 则是兜底机制在正常工作。sysctl 那一行显示内核真正会认的数字——如果 somaxconn 比你的 listen() 参数小，那么那个更小的值才是你真实的 backlog。

来源

内核 ip-sysctl 文档，somaxconn、tcp_max_syn_backlog、tcp_abort_on_overflow 以及 syncookies 的警告，已核验 2026-09-16。
Linux listen(2)，Linux 2.2 起的 accept 队列、somaxconn 的静默截断，以及 syncookies 如何取消 SYN 队列上限，已核验 2026-09-16。
Linux tcp(7)，tcp_max_syn_backlog 按内存大小的默认值，以及 syncookies 的注意事项，已核验 2026-09-16。

ZFS 快照给文件系统一个回退键

Tue, 21 Mar 2028 00:00:00 +0000

ZFS 快照就是给某个数据集在某个 transaction group 上的块树起的一个名字。它不复制任何东西、不冻结任何东西，代价只是几个元数据块：zfs snapshot tank/data@before-upgrade 会在 shell 提示符重画完之前就返回。由于 ZFS 从不原地覆盖仍在使用的块，旧块树在磁盘上一直有效，直到最后一个引用消失——而快照就是这个引用。

正是这一点让“一墙的每日历史”变得可行，也正是本文标题最危险的地方。快照给你数据的许多个版本，却不给你“池不会丢”这件事的保障。tank/data 的每一份快照都住在 tank 里，所以带走池的那次故障，会在同一瞬间带走数据集和它的全部历史。多版本与多版本安全是两种不同的性质，后者只能由复制来提供。

为一个一致的树命名

快照建立在 transaction group 边界上，所以它捕获的树内部自洽——数据库的文件与元数据冻结在同一瞬间，而不是相差几微秒。-r 会连同所有后代数据集一起打快照，凡是有子数据集的地方都该这么用；否则一个递归布局会在不同层级留下时间不同的快照，层与层之间的增量复制就变得别扭。

名字由你决定，而它是保留策略唯一的抓手：tank/data@daily-2026-09-16 可以按模式清理，自动生成的名字则需要额外记账。zfs list -t snapshot -o name,used,refer,creation -s creation 列出整个快照集以及每一份钉住的空间。

空间在哪里：zfs list -o space

ZFS 用一组列来回答唯一重要的问题：这是谁的数据？zfs list -o space tank/data 会给出 USED、USEDSNAP、USEDDS、USEDREFRESERV、USEDCHILD、REFER 与 AVAIL。REFER 是数据集自身需要的量，USEDSNAP 是快照钉住的量，USED 是二者之和。USEDSNAP 持续上涨而 REFER 保持不变，说明吃掉池子的是快照，不是数据。具体到某一份快照，used 是它单独钉住的块，refer 是它能引用到的全部块，两者之差正是与其他版本共用的那部分。

fixture 在 64 MiB 的数据集上搭了一墙 30 份每日快照，每天翻动 2 MiB。每一次创建都花费 0 KiB——代价落在紧随其后的那次写入上，重写 2 MiB 就是 2048 KiB——整墙历史的代价是 60 MiB，而 30 份完整拷贝需要 1920 MiB。这个比例就是快照存在的全部理由，也解释了为什么池子直到快满才有人注意到。反过来，当池子告急时，该做的第一件事是按 zfs list -t snapshot -o name,used 倒序找出钉住空间最多的那一份。

hold、diff 与版本对比

hold 是一个具名引用，它让销毁以 EBUSY 失败：zfs hold keep tank/data@daily-2026-09-16 保护一份快照，zfs holds 列出持有者，zfs release keep 解除。备份软件会给正在发送的那份快照加 hold，免得保留脚本把它删掉；代价是保留任务会一直以“快照忙”失败，直到 hold 被释放，而一个卡住的 hold 能让一份快照被钉住好几个月。

zfs diff tank/data@daily-2026-09-15 tank/data@daily-2026-09-16 按路径报告变化——+ 新建、- 删除、M 修改、R 重命名——并且两份快照都必须仍然存在，所以对比昨天很容易，对比上个月未必。要看快照里的内容，走数据集下隐藏的 .zfs/snapshot/<名字> 目录；快照没有单独的挂载点，而 snapdir=visible 能让这个目录被列出来。

坏掉的样子

真正要紧的失败，恰恰是标题诱导你去相信的那种：池丢了。控制器故障、背板故障或者池级损坏，会原子地删掉数据集以及它的每一份快照，没有部分幸存这回事。唯一的防线是池外的那份拷贝：zfs send -i tank/data@yesterday tank/data@today | zfs receive backup/data 会把一条独立、带校验和的流写进第二个池，只有它能挺过第一个池的死亡。一墙快照却没有副本，是换了个好看界面的单点故障。池内的冗余（镜像、RAIDZ）与 scrub 解决的是另一类问题——坏盘与静默损坏——它们替代不了池外副本，因为控制器或背板故障会把同一个池里的冗余一起带走。

第二种是空间悄悄爬升、保留任务却跑不动。USEDSNAP 上涨而 REFER 不动，池越过 80%，随后 ZFS 开始以“空间不足”拒绝写入，尽管从数据集上看一切正常——池的 slop 与预留量在文件系统内部根本看不见。如果某份快照还被某个 clone 钉住，销毁会失败；而要回滚到 clone 的源之前，就必须连带递归销毁那个 clone。长寿命的 hold 会把保留策略变成一张依赖图，所以 hold 的存活时间要短、要可审计。

快速验证

看清快照的代价，以及它们能不能被删掉：

zfs list -t snapshot -o name,used,refer,creation -s creation tank/data
zfs list -o space tank/data
zfs holds tank/data@daily-2026-09-16
zfs diff tank/data@daily-2026-09-15 tank/data@daily-2026-09-16
zfs send -i tank/data@daily-2026-09-15 tank/data@daily-2026-09-16 | zfs receive backup/data

每份快照的 used 是它单独钉住的空间，刚创建的快照应接近零；space 那组列则给出数据集上的 USEDSNAP 与 REFER，USEDSNAP 上涨而 REFER 不变就是该清理的信号。若 zfs destroy 报快照忙，zfs holds 会告诉你要释放哪个 tag。最后一条是唯一能防住池丢失的操作，应该定时执行。

来源

zfs-snapshot(8)，快照创建语义与递归快照，已核验 2026-09-16。
zfs-list(8)，space 列集，含 USEDSNAP、USEDDS 与 REFER，已核验 2026-09-16。
zfs-hold(8)，hold、zfs holds 以及销毁返回的 EBUSY，已核验 2026-09-16。
zfs-send(8)，把数据送出本池的增量复制流，已核验 2026-09-16。

Hugo 发布选项决定哪些页面进入产物

Sat, 18 Mar 2028 00:00:00 +0000

Hugo 在构建运行时判断哪些页面应当渲染。文章元数据提供发布时间与草稿状态，项目配置和命令参数提供包含规则，构建时钟提供判断所用的时间。生成目录一旦部署，在下次产物替换之前不会自行变化。因此，日期走到午夜不等于触发发布；没有写 draft: true 的文件，也不会自动被当成草稿。这两个边界决定了排期内容能否按预期上线。

元数据和构建选项分别起作用

在默认规则下，标记为 draft: true 的页面不进入产物；发布时间在未来的页面也会被排除，已经过了失效时间的页面同样如此。Hugo 根据 front matter 配置解析各类日期，显式的 publishDate 可以不同于页面显示的 date。对必须精确到某个边界的排期，应使用包含时区的完整时间戳，避免本机和构建服务器把同一个日期解释为不同时间。

--buildDrafts 包含草稿，--buildFuture 包含未来内容，--buildExpired 包含已失效内容，短选项分别是 -D、-F 和 -E。这些开关处理不同条件：一篇发布时间尚未到达的草稿，需要同时允许草稿和未来内容才能提前进入产物。项目配置或环境配置也能启用相同行为，所以只看文章里的标记不足以判断实际发布结果，还必须检查本次构建的有效选项。

本站明确设置了 buildFuture: true，用于保留包含未来日期文章的既有公开目录。因此，本站这些文章的日期不是保密截止时间，也不能用 Hugo 的默认排期规则推断它们尚未公开。修改发布策略之前，需要把配置和预期 URL 清单一起比较，否则关闭一个看似普通的开关，就可能让大量已经存在的地址消失。介绍默认机制与解释本站事实，应当采用各自对应的证据。

预览产物仍然可以被公开

预览开关只改变输出包含什么，不会给产物增加禁止部署的属性。如果流水线上传了用 -D -F 生成的目录，草稿和未来页面一样可以被访问。因此，预览应使用独立输出位置，正式发布则根据计划中的选项重新构建。Git 发布标签只是标识源码历史，既不会改变 Hugo 的包含规则，也不能证明某个生成目录已经经过审阅。交付记录需要关联源码版本、构建选项和实际产物。

按时发布还需要在发布时间之后执行新的构建与部署。反过来，把已经公开的页面重新标记为草稿，也不会撤回服务器上的旧 HTML 或缓存副本。需要重建、替换被服务的产物，再检查公共地址。Hugo 通常不会自动删除输出目录里的所有遗留文件，因此独立的新目录或合适的清洁构建，是证明被排除页面确实不存在的必要步骤。导航里不显示链接，远不足以证明内容已经下线。

坏掉的样子

把预览目录覆盖到发布目录，可能让一篇后来恢复为草稿的文章仍能通过直接地址打开，而索引里已经看不到它。排查应检查生成文件、订阅源、站点地图以及真正对外的页面，区分索引隐藏和文件移除。另一个容易遗漏的规则是：章节页面标记为草稿，并不会自动把所有子页面也变成草稿。若整个子树需要排除，应设置具体子页元数据，或依照文档使用级联配置。

时区差异则可能让两台构建机器从同一个提交生成不同页面。边界测试应固定 Hugo 版本和构建时钟，并记录生效参数。不要在尚未弄清日期解析规则、环境时区和参数来源之前，为了让页面出现而随意改动发布日期。那样可能掩盖配置错误，还会改变订阅顺序和页面展示时间。首先使输入和时钟可重现，才能判断差异真正来自哪里。

快速验证

安装 Python 3 和 Hugo 0.165.0 后，可运行下面的隔离实验。它在临时项目中创建三篇页面，分别构建到五个独立目录，不修改当前仓库，也不执行部署。

from pathlib import Path
from tempfile import TemporaryDirectory
import subprocess

with TemporaryDirectory(prefix="hugo-publication-") as directory:
 root = Path(directory)
 (root / "content/posts").mkdir(parents=True)
 (root / "layouts/_default").mkdir(parents=True)
 (root / "hugo.yaml").write_text("baseURL: https://example.org/\n")
 (root / "layouts/index.html").write_text("<h1>Publication test</h1>")
 (root / "layouts/_default/list.html").write_text("{{ .Title }}")
 (root / "layouts/_default/single.html").write_text("{{ .Title }}")
 for name, extra in {
 "visible": "",
 "draft": "draft: true\n",
 "future": "publishDate: 2030-01-01T00:00:00Z\n",
 }.items():
 (root / f"content/posts/{name}.md").write_text(
 f"---\ntitle: {name}\ndate: 2025-01-01T00:00:00Z\n"
 + extra + "---\nPublication fixture.\n"
 )
 cases = [
 ("normal", "2026", [], {"visible"}),
 ("drafts", "2026", ["-D"], {"visible", "draft"}),
 ("future", "2026", ["-F"], {"visible", "future"}),
 ("preview", "2026", ["-D", "-F"], {"visible", "draft", "future"}),
 ("later", "2031", [], {"visible", "future"}),
 ]
 for name, year, flags, expected in cases:
 destination = root / f"output-{name}"
 subprocess.run(
 ["hugo", "--source", str(root), "--destination", str(destination),
 "--clock", year + "-01-01T00:00:00Z", *flags],
 check=True, capture_output=True, text=True,
 )
 actual = {p.parent.name for p in destination.glob("posts/*/index.html")}
 assert actual == expected, (name, actual, expected)
 print(name, sorted(actual))

断言依次检查默认排除、单独打开两个开关、组合预览，以及时间越过发布边界后的结果。最后一次普通构建仍然不包含草稿。这证明的是受控条件下 Hugo 的渲染选择，没有覆盖部署调度、CDN 缓存失效，也没有套用本站主动包含未来页面的配置。正式发布时，还需要从本次产物和公共路由分别取得证据，确认生成结果与线上实际一致。

如果站点使用失效日期，还应增加过期页面，并独立验证 -E 的效果。流程依赖多个排除条件同时生效时，也应加入一篇未来草稿，检查组合开关是否符合预期。

来源

Hugo：基本用法，草稿、未来和失效内容，以及输出目录行为，已核验 2026-09-06。
Hugo：Front matter，发布元数据和级联设置，已核验 2026-09-06。
Hugo 命令参考，内容包含开关和构建时钟，已核验 2026-09-06。

iotop 能看出是哪个进程在烧磁盘

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

磁盘突然飙升却找不到明显的写入者时，iotop 把吞吐直接指回那个在捣乱的进程。系统级工具只给症状——await 高、util 打满——不给嫌疑人：五十个进程共享磁盘，平均值平等地怪每一个。终结调查的永远是按进程的问题——谁、多少、何时开始——iotop 从内核计数器实时回答，应用藏都没处藏。

把它放在系统级视图旁边，而不是代替。iostat 或 vmstat 说磁盘是瓶颈，iotop 点名是谁造成的。两者合起来把存储悬案压成两条命令：确认资源，锁定消费者。

逐个进程的计数器

iotop 从内核读每个进程的 IO，于是实时读写速率能对应到一个 pid，而不是一个说不清来源的负载均值。加 -o 只显示真正在做 IO 的进程，一眼看清。默认视图读写分开，还带 swap-in 百分比，把真吃磁盘的和仅仅在场的分开——DISK READ 高、写零的是在扫，写高的在产； throttle、迁移还是杀，取决于这个区分。

注意计数器量的到底是什么：穿过 IO 层的按进程字节，含还没落盘的缓冲写。进程写速率巨大、磁盘看着却闲（页缓存吸收），或速率平平、磁盘打满（大量小同步写），都可能。iotop 跟设备 util 一起读：进程侧定罪加设备侧饱和才是完整画面，任一半单独都误导。

看到谁在扫盘

按带宽排序，那个罪魁就现形了，无论是日志囤积、索引器还是失控备份。跟住这个 pid，就能定位到确切的进程（往往还有文件），再动手不迟。惯犯名单：debug 级别没轮转的日志、排在高峰的重建索引、同盘读写备份、坏镜像上循环解包的容器层。修法各不同——轮转、改期、分开、清理——杀进程治标，病因明天定时再来。

动手前把 pid 解析到完整上下文：命令行、工作目录、lsof 看开文件、父进程。一个烧写的 java 进程背后可能是一个 PID 命名空间里的十个应用；修要修对那一个。先定罪后动手——每个以遗憾收场的存储 war story 都跳过了第一步。

先看再动

iotop 只观察、不改变任何东西，所以你可以在决定节制、迁移或停掉之前先把元凶查清楚。再配 strace 或 lsof 打到这个 pid，把文件和系统调用一并钉死。组合是决定性的：iotop 说 18412 进程写 400MB/s，lsof 说写进一个膨胀的日志文件，strace 显示 4KB 的 O_APPEND 写——诊断完毕；修法（日志级别、轮转、异步 appender）不言自明，不用开会争。

健康时录基线，故障时对比才有意义。平时某天 iotop -b -n 60 落文件五分钟，就是这台机器的"正常"数字：平时谁领跑、多少速率算寻常。没有它，每次 spike 都像史无前例；有了它，多数 incident 几秒归类：“又是 indexer，提前一小时”。把 iotop 批输出和系统监控同一时段的曲线放一起看，进程侧和设备侧互相印证，结论才站得住。单看任何一边，都可能把相关当因果。告警阈值按基线设，而不是拍脑袋，基线之外的 spike 才值得半夜起床。把 Top 写入者的变化趋势也画出来，渐变比突变更早暴露问题。

基线文件要标清楚采集条件：采集时段、业务负载水位、iotop 的采样间隔与累计方式，否则下次对比就是拿苹果比橙子。建议每周固定一个低峰窗口复采一次，覆盖掉业务自然增长带来的漂移；复采后把新旧两份排名并排 diff，只看名次变化超过三位的进程，逐个确认是业务上线还是异常冒头，再决定跟进还是放行。确认结论也要回写基线备注。

坏掉的样子

最经典的元故障是权限盲：没特权跑，iotop 进程细节全问号，别用户的进程直接不显示——而真凶恰跑在别用户下，隐形到底。一开始就带够特权（root 或对应 capabilities），不然工具开脱的恰是你看不见的进程。无特权 iotop “什么都没查到”，只代表你自己的进程没事。

第二种是突发 IO 的采样幻觉：一分钟暴力一秒的进程，5 秒平均看着无辜，1 秒平均看着有罪，反之亦然。数字和症状对不上就换 delay 档；“过去一小时谁伤的盘"问累计总量（-a）不问瞬时速率。聚合方式对，问题才对；默认聚合只答它自己假设的那个问题。

快速验证

非交互地抓谁在做 IO，带上下文：

iotop -b -n 5 -o -d 2 | head -n 30
pid=$(iotop -b -n 1 -o | awk 'NR>5 {print $1}' | head -n 1); ls -l /proc/$pid/exe; cat /proc/$pid/cmdline | tr '\0' ' '
iostat -x 1 3 | grep -E "Device|sd|nvme"

batch 抓排名不占终端，pid 解析点名头号写者的二进制，iostat 确认设备侧真打满。

来源

iotop 手册，iotop 官方参考，已核验 2026-06-01。
vmstat 手册，说明系统级 CPU 与 IO 等待报告，已核验 2026-09-05。

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

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-09-12。
nginx content caching guide，缓存键、状态观察与缓存行为，已核验 2026-09-12。
RFC 9111 HTTP Caching，新鲜与过期响应，以及 private、no-store 指令，已核验 2026-09-12。

etcd 通过选举单一领导让写入有序

Thu, 09 Mar 2028 00:00:00 +0000

etcd 是一份被复制的日志，Raft 就是让各副本保持一致的算法。每个任期里只有一名成员是领导者，也只有它可以提议新条目；当多数成员都拥有该条目时，它才算提交。领导者选举决定谁可以写，日志复制决定什么才算持久——这是两套机制，故障模式也各不相同。

两者都被同一个数字支配。仲裁数决定了每次写入要付多少确认、你能承受几台成员失效，以及发生网络分区时会怎样。成员数选错，你为同样的韧性付得更多；丢掉仲裁，集群就停止写入，却仍会回答一部分读请求。

每个任期只有一个领导者

成员在选举超时内没听到领导者的消息就会变成候选人，超时时间是随机的，以免所有人同时竞选。它递增任期、投自己一票，然后向其他成员拉票；一个成员在每个任期最多投一票，并且会拒绝任期更低的候选人。拿到多数票的候选人成为领导者。如果两个成员同时超时，票可能被瓜分——四成员集群里可能变成 2 比 2，够不到 3 这个仲裁数——这一轮就白费了，代价是再等一个选举超时。

选举期间集群无法处理写入：etcd 会把请求排队，等领导者产生后再处理。已经发给旧领导者但尚未提交的写入可能丢失，因为新领导者有权覆盖未提交的条目；已提交的写入永远不会丢。任期就是让这一切安全的时钟，也正是为什么一个任期偏高的孤立成员是隐患而不是趣闻。

仲裁数的算术，以及为什么奇数更好

仲裁数就是简单多数：floor(N/2) + 1，因此集群能承受的失效数是 N - quorum。三个成员承受一次失效、需要两个确认；四个成员同样只承受一次失效，却需要三个确认。五个成员承受两次失效、需要三个确认；六个成员同样承受两次，却需要四个。偶数成员数买不到额外韧性，只会让每次写入多付一个确认。

成员变更会立刻改变仲裁数，偶数集群的危险就在这里。文档里的例子是一个单成员集群：加一个成员会把仲裁数从 1 抬到 2，原来的领导者发现自己不再拥有活跃的仲裁，于是触发一次选举。把三成员扩到四成员会把仲裁数从 2 抬到 3，于是一次 2 对 2 的分区让两侧都选不出领导者——而三成员集群在这种情况下，多数一侧仍然完好。

learner 成员，以及两套机制的分工

learner 会接收领导者的日志但不投票，这正适合刚加入、还在追赶的节点：给三成员集群加一个 learner，仲裁数仍是 2，加入动作本身不会触发选举。learner 拒绝客户端的读写，领导者身份不能转移给它，它也永远不会自我提升。只有当它的日志追平之后，运维才能提升它；也只有到那时，它才开始计入仲裁数。

把选举与复制分开看，能解释大部分令人困惑的现象。领导者失效会让追加停止，直到选出新的领导者，哪怕每个成员本身都健康。一个健康的领导者如果联系不上跟随者，同样无法提交。而一个跟随者可以落后任意多，集群却照样提交，因为只需要多数拥有该条目——落后是复制问题，不是可用性问题，直到多数本身消失为止。

坏掉的样子

最经典的故障是丢掉仲裁。写入停止：多数成员失效的集群无法接受更多写入，只有多数重新可用它才能恢复，否则唯一的路是从备份做灾难恢复。陷阱在于读可能仍然能用。线性一致读是一次共识操作，会像写入一样失败；而串行化读由成员自己的状态直接提供，可能返回集群早已越过的数据——所以「它还能应答」并不是健康的证据。

第二种故障是被分区的少数派，它更安静。少数派选不出领导者，因此既没有仲裁也没有写入；由于成员变更同样需要多数，这里不会出现脑裂。在 Raft 层面，那些被隔离的成员会不断超时并抬高自己的任期，而多数一侧的任期原地不动；分区恢复时，更高的任期迫使领导者下台，于是重新跑一次选举。也就是说，分区恢复本身会带来一次短暂的写入中断。

快速验证

读出领导者、任期，以及各成员的日志落后量：

etcdctl --endpoints=https://10.0.1.11:2379 endpoint status --write-out=table
etcdctl --endpoints=https://10.0.1.11:2379,https://10.0.1.12:2379,https://10.0.1.13:2379 endpoint health --write-out=table
etcdctl --endpoints=https://10.0.1.11:2379 member list --write-out=table
etcdctl --endpoints=https://10.0.1.11:2379 --consistency=s get /registry/ --prefix --keys-only | head

status 表里 LEADER 列应当只有一个 true，而所有成员应共享同一个 RAFT TERM；任期明显更高的那个成员就是曾被分区隔离的。endpoint health 失败到足以打破多数时，写入就会被拒绝。member list 里标着 learner=true 的成员不投票，也不计入仲裁数。最后一条就是那个在失去仲裁后依然能成功的串行化读，这正是它不适合当健康检查的原因。

来源

etcd failures，领导者失效、多数失效、网络分区以及写入的后果，已核验 2026-09-16。
Runtime reconfiguration，多数派提交与改变集群规模的代价，已核验 2026-09-16。
etcd learner design，不投票的 learner 状态与提升流程，已核验 2026-09-16。
etcd API guarantees，线性一致读与串行化读的区别，已核验 2026-09-16。

BPF tracepoint 能窥探正在运行的内核

Mon, 06 Mar 2028 00:00:00 +0000

BPF 与内核 tracepoint 能在源头观察行为，且占用极小：不加 agent、不重启、不打断正在跑的工作负载。传统剖析意味着装东西、带 flag 重启、或暂停进程——每样都扰动被研究对象，或在生产根本不被允许。BPF 探针挂到跑着的内核上，收走答案就摘掉，工作负载原样归还。

BPF 给的是日志给不了的答案：哪些 syscall 烧时间，哪些文件卡磁盘，TCP 重传聚在哪，全从主机每个进程实时采样。“哪里慢"“现在发生什么”，对的一行命令一分钟，胜过日志考古一小时。

不断流地探测

一个很小的 eBPF 程序挂到某个既有 tracepoint 上，一边累计计数或直方图统计数据，工作负载照常跑。它运行在内核上下文，探针几乎不会成为瓶颈。程序加载前先过验证器——内核检查内存安全与可终止——有 bug 的探针被拒绝，而不是带崩机器。聚合发生在内核 map 里，几百万事件先坍成小直方图再出用户态；常见开销个位数百分比，往往比团队本来就跑着的日志还便宜。

从问题出发，不从工具出发。“哪个进程开文件最多"是一种 trace 形态，“按设备看 p99 磁盘延迟"是另一种，bpftrace 一行命令画廊两种都覆盖，不用写 C。优先高级前端——bpftrace、bcc 工具——真需要定制逻辑再碰 raw BPF；故障时写得出的一行，胜过下周才写完的完美程序。

tracepoint 是更稳定的名字

内核 tracepoint 标记 block I/O、调度、syscall 进出这类事件，名称比裸 kprobe 更不易碎，跨内核升级依旧健壮。kprobe 钉内核函数地址，版本一换就漂；tracepoint 命名内核承诺保持的语义事件，周二补丁重启后同一探针照跑。挂离行为最近的：磁盘问题挂 block，离 CPU 延迟挂调度，“谁调什么"挂 syscall。

猜名字前先列出现有什么——tracepoint 在内核 tracing 接口下枚举着，标准工具都能打印。真没有 tracepoint 覆盖的事件，刻意降级 kprobe 或 uprobe，注释里钉死内核版本，张着眼睛付维护成本。稳定性是光谱：tracepoint 优先，知名 kprobe 其次，裸地址永远别进想保留的东西。

读直方图，而不是开闸放水

把嘈杂的事件流聚合成延迟或计数直方图，最先暴露得分偏低的那一档异常，而不是把每个事件都打印出来。先看形状定位头号嫌疑，再往细分钻。一百万 syscall 的逐条 dump，人读不出任何东西；log 刻度延迟直方图一屏展示双峰——快路径对慢的 1%。直方图是诊断，单事件只是确认，直方图指了方向再采样。

聚合键保持紧：一按进程、一按文件、一按 syscall，一次一维。二维拆分爆炸基数、活埋信号，全参数 dump 把 firehose 从后门请回来。直方图点名嫌疑后，转对该进程或文件单独定向 trace，加时间 bound，拿到确认样本就停。生产用前先在 staging 把探针跑一遍，确认输出格式和开销都符合预期，再决定采样率。把验证过的 one-liner 收进团队 runbook，下次同类问题直接取用，不用临场现写。采样结论先在小范围复现一次再推广，避免单次采样的偶然当成规律。结论写进复盘时附上探针原文，保证别人能原样重跑。

上线前在预发环境对照业务指标测一轮开销：先记录不挂探针时的请求延迟与 CPU 占用，再挂上同样的聚合探针跑十分钟，对比两者差距。只有确认差距落在个位数百分比以内，才把采样率与过滤条件带到生产；若差距超标，就收紧过滤到单个进程或拉长聚合窗口，直到开销回到可接受范围，再把这组参数连同探针一起收进 runbook。

坏掉的样子

最经典的是挂不上的探针：tracepoint 名错、缺内核头、环境锁死禁 BPF 加载——工具悄悄退出或甩一句神秘 verifier 信息。先验环境（tracepoint 列得出、loader 权限有）再怀疑探针逻辑；BPF 失败多半是环境的，不是逻辑的。容器里记住探针一般要主机级特权，容器运行时默认不给。

第二种是大规模下的观察者效应：热路径上无过滤探针——10 万 rps 盒子上 trace 每个 syscall——烧掉整核，还扭曲它正在量的东西。永远内核内聚合、尽早过滤到嫌疑、生产探针限时。开销可疑就把采样砍半或收紧过滤，看答案形状稳不稳；便宜地看就变形的测量，从来不可信。

快速验证

确认工具链可用并取第一张直方图：

bpftrace -l "tracepoint:syscalls:*" | head -n 5
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @opens[comm] = count(); }' &
BPF_PID=$!; sleep 10; kill -INT $BPF_PID; wait

第一条证明 tracepoint 可见，十秒采样按文件打开数给进程排名——每次 BPF 调查的缩微形状。

来源

bpftrace 内核追踪文档，bpftrace 官方参考，已核验 2026-06-01。
eBPF 介绍，eBPF 官方文档，已核验 2026-09-05。

InnoDB 覆盖索引包含查询所需的列

Fri, 03 Mar 2028 00:00:00 +0000

覆盖索引包含某条查询求值和返回结果所需的列。在 InnoDB 中，二级索引记录还会携带主键列，因此即使二级索引定义没有再次列出主键，某条查询也可能已经被覆盖。覆盖描述的是一条具体查询与某个索引之间的关系，不是给索引贴上标签之后，整张表的所有查询都自动获得同样行为。

坏掉的样子

增加返回列可能使覆盖失效。原本能提供标识和时间戳的索引，不一定包含应用后来开始读取的大载荷。优化器仍然可能沿用这个索引定位匹配记录，再访问聚簇记录取得缺失字段。因此，“用到了索引”和“由索引覆盖查询”是两件不同的事，不能从计划中出现索引名字就直接推导后者。

覆盖也不保证访问范围足够小。一个扫描大量条目的查询，可以完全被索引覆盖，仍然花费很多工作。列顺序、过滤条件、排序要求和行数估计都很重要。不要把 Using index 覆盖标记当作查询很快的证明，也不要把它与 Using index condition 索引条件下推标记混淆；后者描述部分条件在索引层求值，并不证明整个返回投影都在索引里。

InnoDB 的可见性检查还会限制通常所说的“只读索引”解释。二级记录不包含与聚簇记录相同的隐藏事务元数据。遇到删除标记条目，或被更新事务修改过的二级索引页时，可能仍需访问聚簇记录才能获得正确可见版本。因此，在并发多版本活动下，一个覆盖计划并不普遍保证聚簇访问次数永远为零。

快速验证

准备一台新的 MySQL 8.4 实例，使用能够创建测试模式的客户端会话。本次实际运行版本是 MySQL 8.4.11。确认实验模式名尚未使用，遇到非预期 SQL 错误就停止，并保持同一个会话，以保留当前选中的数据库。下面建立一万行数据，其中一百笔已付款订单，并让载荷列明显比索引所需字段更宽：

CREATE DATABASE xbcatm_index_lab;
USE xbcatm_index_lab;
CREATE TABLE orders (
 id INT PRIMARY KEY,
 status VARCHAR(10) NOT NULL,
 created_at DATETIME NOT NULL,
 payload VARCHAR(1000) NOT NULL,
 INDEX by_status_created (status,created_at)
) ENGINE=InnoDB;
INSERT INTO orders
WITH digits(n) AS (
 SELECT 0 UNION ALL SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3
 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6
 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9
)
SELECT number+1,IF(MOD(number+1,100)=0,'paid','open'),
 TIMESTAMP '2026-01-01 00:00:00' + INTERVAL (number+1) SECOND,
 REPEAT('x',640)
FROM (SELECT a.n+10*b.n+100*c.n+1000*d.n AS number
 FROM digits a CROSS JOIN digits b CROSS JOIN digits c CROSS JOIN digits d) AS numbered;
ANALYZE TABLE orders;
SELECT COUNT(*),SUM(status='paid') FROM orders;

最后的两个计数应为一万与一百。二级索引明确包含状态与创建时间，InnoDB 隐式提供主键标识。先检查并运行只需要这些值的查询：

EXPLAIN SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
EXPLAIN ANALYZE SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;

本次表格计划给出所建索引及覆盖访问标记，实际分析计划显示覆盖索引查找并返回二十行。结果标识依次为一百、二百，直到两千，按照时间戳与标识排序。这是在已经填充数据的表上核对过的实际结果，不是从一个空模式推测查询会采用什么访问路径。

接着，把载荷也加入返回列：

EXPLAIN SELECT id,created_at,payload FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
EXPLAIN ANALYZE SELECT id,created_at,payload FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;

本次计划仍使用同一个索引，却不再具有覆盖标记；实际分析也变成没有覆盖限定的索引查找。这保持了过滤、排序和索引不变，只改变所需返回列，因而能够明确观察投影变化的影响。实际分析命令会真正执行查询，对真实的大查询使用它时，应把这次诊断本身的执行代价算进去。

最后删除本次实验自己创建的模式：

DROP DATABASE xbcatm_index_lab;

这个小型热缓存实验的时间不能当成吞吐量或延迟基准。调度、缓存和测量本身的开销，可能超过两次二十行查询之间的差别。这里验证的是访问形态与结果内容，而不是承诺物理输入输出减少某个固定比例，更不能据此保证生产请求的高分位延迟必然下降一半。

有意识地承担覆盖成本

给二级索引追加字段会占用存储与缓冲池容量，并在相关索引值变化时增加维护工作。较长的主键也会扩大二级索引条目。应覆盖重要而窄的查询，不要默认把大载荷复制到每个索引里。明确列出返回字段，也有助于后续应用变更在审阅时暴露新的数据访问要求，避免一个查询投影变化悄悄改变成本。

保留新增索引之前，应比较代表性的计划、检查行数、前台延迟以及写入代价。使用真实选择率和并发活动进行验证；安静夹具并没有测量可见性检查需要聚簇访问的频率，也没有测量副本维护这些索引的成本。索引应当通过它实际服务的工作负载证明价值，而不是仅因为一次解释输出里出现了期望的标签。

来源

MySQL 8.4 聚簇索引与二级索引，二级记录携带主键列的机制，已核验 2026-09-12。
MySQL 8.4 EXPLAIN 输出，索引使用与覆盖计划标记，已核验 2026-09-12。
MySQL 8.4 InnoDB 多版本机制，二级索引可见性检查需要聚簇访问的条件，已核验 2026-09-12。

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。

bash history 是可以搜索的命令日志

Mon, 28 Feb 2028 00:00:00 +0000

命令历史能减少重复输入，却不是所有已执行操作的完整记录。Bash 通常在交互 Shell 中启用历史功能，配置还可以过滤条目或限制保留数量。运行中 Shell 的可搜索列表，与磁盘上的历史文件，是两个独立状态。理解这个区别，才能解释为什么某条命令在一个终端能找到，在另一个终端却没有，以及为什么意外结束会话可能丢掉尚未保存的记录。

会话内存与历史文件不同

HISTSIZE 限制内存中的历史条目数量，HISTFILESIZE 限制保存文件的行数。多行命令与时间戳记录会让行数不等于命令数，不能用简单的文件行数判断究竟保留了多少次操作。HISTFILE 决定保存位置，通常指向用户的 Bash 历史文件。变量未设置或为空时不会正常保存；目标不可写时，当前会话仍可能查到记录，却没有对应的持久化副本。

Bash 在参数展开之前、历史展开之后记录命令文本，并受到 HISTCONTROL 与 HISTIGNORE 的影响。因此，保存下来的变量引用并不一定显示原来执行时的变量值。当前目录、别名、函数、环境及外部文件，也都可能在下次复用命令之前发生变化。历史保存的是有用的输入，不是完整的可复现运行环境，更不是可以直接信任的操作审计证据。

追加保存不会自动刷新其他终端

Bash 正常退出时保存历史，histappend 决定追加到文件还是覆盖文件。如果此前没有主动保存，异常终止可能丢掉全部未写入的条目，不只是最后一条。history -a 追加当前会话新输入、且尚未追加过的历史行。提前保存可以缩小丢失窗口，但不等于承诺任何系统故障之后都能完整恢复，更不能把一次文件写入等同于业务日志的可靠持久化。

另一个仍在运行的 Shell 持有自己的列表，需要通过 history -n 等操作读取新追加的行。仅仅启用追加选项，不会让另一个终端的搜索结果实时更新。history -r 把整个文件内容追加到现有列表，重复运行可能制造重复条目；history -w 则用当前列表替换文件，可能丢掉其他会话留下的记录。这些命令的方向和覆盖语义不同，不能当作几种等价的同步写法。

如果把追加和导入接入 PROMPT_COMMAND，还要保留已有提示符钩子，以及它们对上一条命令退出状态的使用。直接覆盖已有钩子可能破坏其他 Shell 行为。多个会话共享一个文件，也不会因此形成可信的全局执行顺序。需要顺序、退出码或责任归属时，应使用独立的操作日志，而不是从交错的历史文本中反推完整事实。

搜索后先检查，再执行

在常见的 Emacs 风格 Readline 绑定中，Ctrl-R 向后增量搜索，再按一次查找更早的匹配。应使用编辑按键退出搜索，先检查所选命令，再决定是否执行；Ctrl-G 可以取消搜索。回车会接受命令，Ctrl-J 也是换行，不能把它说成不会执行的预览键。其他编辑模式或自定义终端的绑定可能不同，应以当前配置为准。

复用旧命令时，检查主机名、目录、选项和目标。上个月正确的命令，今天可能已经指向另一套环境。用辨识度高的片段搜索可以减少翻找，但找到之后仍应查看整行，不能把第一条匹配结果直接当成当前想做的操作。历史搜索解决的是找回输入的问题，不负责重新判断操作意图。

坏掉的样子

命令消失可能来自过滤规则、保留上限、不同的历史文件、保存失败，或者当前会话没有导入新记录。应分别核对这些原因。ignoredups 只排除连续重复，不会对整个历史全局去重；ignoreboth 只是把它与忽略行首空格的规则组合，也不会得到一份全局唯一的命令档案。判断条目是否丢失之前，先明确当前启用了什么过滤条件。

行首空格只有在相应配置生效时才会排除条目。它不会移除终端录制、进程参数或其他位置的日志，因此不能把凭据直接放进命令行，再依赖历史过滤保证保密。诊断示例也应使用合成条目和临时历史文件，避免为了证明历史功能可用，就把真实用户最近执行过的命令打印出来。

快速验证

使用 Python 3、Bash 和常见 Unix 工具运行下面的完整示例。环境在 Bash 启动之前就把历史文件指向临时目录，整个过程只查看合成文本。花括号分组让控制命令先被整体读取，避免启用历史之后又把实验自身的控制步骤逐行写进列表。退出前解除自动保存目标，随后由临时目录管理器清理测试文件。

import os
import subprocess
import tempfile
from pathlib import Path

script = r'''{
set -eu
set -o history
history -c
history -s 'demo original'
history -w "$HISTFILE"
printf 'first-file:\n'
cat "$HISTFILE"
history -c
history -s 'demo replacement'
history -w "$HISTFILE"
printf 'replacement-file:\n'
cat "$HISTFILE"
history -r "$HISTFILE"
printf 'memory-after-reread:\n'
history | sed 's/^[[:space:]]*[0-9][0-9]*[[:space:]]*//'
unset HISTFILE
}'''
with tempfile.TemporaryDirectory(prefix="bash-history-demo-") as directory:
 history_path = Path(directory) / "history"
 env = dict(os.environ, BASH_ENV="", HISTFILE=str(history_path), HISTSIZE="100",
 HISTFILESIZE="100", HISTCONTROL="", HISTIGNORE="",
 HISTTIMEFORMAT="")
 subprocess.run(["bash", "--noprofile", "--norc", "-c", script],
 env=env, check=True)

第一次写入后，文件只包含 demo original；替换后只包含 demo replacement。内存已经有替换条目，再读取文件，会看到两条相同内容。这组结果直接区分覆盖文件与向内存追加，并且不会执行保存的那些字符串。它没有把文件操作试验冒充键盘绑定验证或崩溃持久性测试；后两者需要在对应环境中单独观察。

来源

Bash 历史设施，会话列表与历史文件的保存规则，已核验 2026-09-07。
Bash 历史内建命令，追加、替换及导入条目的差异，已核验 2026-09-07。
Readline 历史命令，搜索及接受命令的按键绑定，已核验 2026-09-07。

Protobuf 让新旧服务仍能沟通

Sat, 26 Feb 2028 00:00:00 +0000

gRPC 的服务端和客户端各自按自己的节奏发布，所以 schema 必须在新旧二进制同时运行时继续演进。Protobuf 正是为此设计的：兼容契约落在字段编号与 wire type 上，而不是字段名上；读方遇到不认识的字段就跳过，而不是失败。

张力在于这份安全既窄又不受强制。能安全做的修改只有一小撮，其余会无声地污染数据，而编译器只拒绝你明确告诉它要拒绝的那些。分清哪次修改属于哪一类，就是全部功夫。

线上说的是编号，不是名字

线上每个字段都是一个 tag——字段编号左移三位再或上 wire type——后面跟着载荷。对 id=7、name=“alpha”、code=1234 这条消息，字节是 08 07 12 05 61 6c 70 68 61 18 d2 09，其中 0x18 标明字段 3 是 varint，d2 09 就是 1234。protoc --encode 产出完全相同的字节，所以这是格式本身，而不是对格式的描述。

因为名字根本不出现在线上，改名是免费的：同一批字节用一份把字段 1 叫 event_id、字段 3 叫 status 的 schema 解出来，值完全一样，只是标签变了。用新编号新增字段同样是安全的——旧读方会把它当作未知编号呈现出来并保留其字节，重新编码能精确复现新消息。正是这份保留，让旧代理可以转发它看不懂的消息。

绝不复用字段编号

真正会污染的修改，是删掉一个字段又复用它的编号。有两种变体，都很糟。如果 wire type 变了——int32 的 varint 变成 string——新读方会看到旧值以「不认识的编号」形式滞留，而声明的 string 是空的：无声丢失，什么都没记。如果 wire type 恰好兼容，反而更糟，因为值会干净地解成另一种含义：同一批字节按 int32 读是 -1，按 uint32 读是 4294967295，而按 bool 读 1 就是 true。

对付它的工具是 reserved。写下 reserved 3; reserved "code";，编译器就会拒绝任何使用编号 3 或名字 code 的字段，并提示下一个可用编号。没有这句声明，同一份 schema 编译得毫无怨言，一次污染性变更就这样进了生产。

编号一旦被用出去，就永远属于那个含义。字段可以删除，编号不能回收——删除只让新代码不再写它，而线上可能仍有旧二进制在写、在缓存、在重放。reserved 把这条规则从口头约定变成编译期约束。

存在性是另一个决定

proto3 字段是隐式存在性：字段缺席与字段置零编码出的字节完全相同，读方分不清「客户端没发」和「客户端发了零」。加上 optional 就会改变这一点——零也会发出自己的 tag——生成的访问器读的就是这一位。凡是零本身有含义、而不是「缺失」同义词的地方，都该用它。

与之相关的失败是假定某字段必需。线上根本没有 required，新字段在旧生产方那里就是缺席，所以把缺席当成错误，会拒掉每一个还没升级的客户端。删除编号时就 reserved，需要新语义就加 optional 字段而不是改类型，并让缺席就表示它字面上的意思。

需要区分「没设置」和「设为零」的地方不止是可选标量：枚举、字符串、嵌套消息各有自己的默认值与存在性规则，混用会让「空字符串」和「未提供」塌成同一个状态。

坏掉的样子

最经典的是复用了 tag 编号导致静默误解码。生产方按新 schema 写，旧消费方把同一批字节读进一个含义已经改变的字段，而且什么都不会记，因为什么都没失败：值就是错的。它表现为某一个服务从正确的输入里算出胡说，而其他服务全都一致；诊断办法是把线上字节 dump 出来，手工走一遍 tag。这类问题在灰度期间往往不出现，因为灰度只覆盖一部分流量，也常常只覆盖一部分字段。

第二种是「必需字段」式假设打断了旧客户端。把缺失字段当成协议错误的消费方，会拒绝每一个比它更早的生产方；把缺失字段当成零的消费方，会走错分支。两者是同一个错误——从「缺席」里读出语义——都可以靠 reserved 退役编号、靠 optional 新增字段来避免。

快速验证

先看线上真正的编号，再让编译器强制退役：

protoc --decode_raw < captured.bin
protoc -I. --descriptor_set_out=/dev/null api.proto
grep -rn 'reserved' proto/

--decode_raw 只打印字段编号和值，一个名字都没有，这正是对端实际收到的东西。编译必须成功；如果它报 reserved 编号错误，说明有人想复用已退役的 tag。grep 必须为你删掉的每个编号都列出一条 reserved。错误的结果是：你以为已经退役的编号仍带着值，或者 schema 之所以能编译，只是因为那个编号从来没被 reserved。

来源

Protobuf：编码，tag 布局、varint，以及 int32/uint32/bool 背后的 wire type，已核验 2026-09-16。
Protobuf：proto3 语言指南，字段编号、reserved、optional 与存在性语义，已核验 2026-09-16。
Protobuf：该做与不该做，退役与复用字段编号的规则，已核验 2026-09-16。

Kubernetes CronJob 需要历史清理策略

Fri, 25 Feb 2028 00:00:00 +0000

CronJob 本身不跑你的任务：它创建一个 Job，Job 再创建 Pod。Pod 跑完之后，Job 和 Pod 都不会自动消失。Pod 是故意留着的，好让你事后还能读到它的日志；Job 留着，是为了让你还能看到这次运行的状态。

这份默认对一次运行是对的，对一万次运行就是错的。每一个已完成的 Job 都是 etcd 里的一个对象、每次列表响应里的一行，以及所有关心 Job 的控制器都会收到的一次 watch 事件。给这堆东西设边界的有两套彼此独立的机制：CronJob 控制器按数量裁的历史上限，和 TTL 控制器按时间裁的 TTL。

已完成的 Job 并不免费

已完成的 Job 会留住它的 Pod，而 Pod 只要还在，容器日志就还在。于是保留策略成了你和“命名空间堆满墓碑”之间唯一的东西。按小时调度跑三十天就是 720 次运行：720 个 Job 加 720 个 Pod，每个都有自己的名字、状态、owner reference，以及你每次 kubectl get jobs 输出里的一行。已完成的 Job 也不是完全静止的：它的 status conditions 一直留在 API 里，被每个 watcher 反复读取。单个对象的开销微不足道，但它是随时间线性增长的，所以它长期保持隐形，直到某天突然变成问题。

可观测性上的代价比资源代价来得更早。命名空间里一旦有几百个已完成的 Job，kubectl get jobs 一屏就放不下，真正的失败混在一堆成功里看不出来。API server 的内存压力确实存在，但它是渐进的；你排查问题的能力下降却是立刻发生的，也正是这一点逼着人去配清理策略。这笔账是悄悄复利的：按小时的任务一年下来堆满墓碑，而每分钟一次的任务一周就追平。

两套机制，两个控制器

CronJob 控制器按数量裁。successfulJobsHistoryLimit 默认是 3，failedJobsHistoryLimit 默认是 1，把任意一个设成 0 就表示这一类一个都不留。裁剪按类别分别进行，并且从最旧的开始，所以一个长期失败的 Job 只会留下最近一次失败。这两个上限 API 都不强制；不设策略本身也是一种策略，只不过是一种会持续泄漏的策略。

TTL 控制器按时间裁。ttlSecondsAfterFinished 写在 Job 上，控制器会在 Job 完成之后的那个秒数把它删掉，并级联删掉它的 Pod。设成 0 表示完成即刻可删；不设则 TTL 控制器永远不会碰它。这个特性从 v1.23 起稳定，而且它读的是 Job 而不是 CronJob——这一点下面会用到。两套机制之间没有任何协调：谁先触发谁生效，所以一个比历史窗口更短的 TTL 会悄无声息地盖掉你配的数量。

owner reference 决定谁来清理

由 CronJob 创建的 Job 带着指向该 CronJob 的 owner reference，所以删除 CronJob 会级联到它的 Job 以及这些 Job 的 Pod。级联删除正是删掉一个 CronJob 看起来就万事大吉的原因：Job 和 Pod 一起消失，历史上限根本没参与进来。但按数量裁剪这件事是 CronJob 控制器做的，而它必须知道 CronJob 存在，才知道上限是多少。因此 kubectl delete cronjob --cascade=orphan 会留下 owner reference 悬空的 Job，且没有任何东西再来裁它们；而 TTL 依然生效，因为它是逐个 Job 单独判定的。

对于你直接创建、而非经由 CronJob 创建的 Job，官方文档写明的默认删除策略是 orphanDependents：删掉 Job 可能把它的 Pod 留在原地。控制面最终会在这些 Pod 失败或完成后把它们回收，但文档明确警告残留的 Pod 可能拖慢甚至拖垮集群，并因此建议把 ttlSecondsAfterFinished 设上。清理策略是一道保留决策，不是洁癖偏好。

坏掉的样子

为了“保持命名空间干净”把两个历史上限都设成 0，会让每个 Job 在完成的那一刻被删掉，Pod 和它的日志随之消失。你真正需要看的那次失败就此不见，而且无法恢复。留几条成功记录，再留足够覆盖一个周末的失败记录；读不到的证据不叫证据，被删掉的日志也不叫日志。

TTL 只从“完成”那一刻起算，所以一个永远跑不完的 Job 永远不会过期。卡在 ImagePullBackOff 的 Pod 会让它的 Job 一直停在 active 状态：既不是成功，也不是失败，于是两类历史上限都不统计它。给 job template 加上 activeDeadlineSeconds，让卡死的运行最终失败，再交给 TTL 去回收。

快速验证

把配置和实际堆积量对照着看：

kubectl get cronjob hourly-rollup -o jsonpath='{.spec.successfulJobsHistoryLimit} {.spec.failedJobsHistoryLimit} {.spec.jobTemplate.spec.ttlSecondsAfterFinished}{"\n"}'
kubectl get jobs --sort-by=.metadata.creationTimestamp --no-headers | wc -l
kubectl get pods --field-selector=status.phase=Succeeded --no-headers | wc -l
kubectl get jobs -o jsonpath='{range .items[*]}{.metadata.name} ttl={.spec.ttlSecondsAfterFinished} owner={.metadata.ownerReferences[0].name}{"\n"}{end}'

第一行两个值都为空，说明没有任何东西在限制保留量。Job 数量稳定在两个上限之和附近，说明 CronJob 控制器正在裁剪；数量随时间持续上涨，说明它没有。最后一条命令里，ttl 为空且 owner 也为空的 Job 就是孤儿，两个控制器都不会再去删它。

来源

Kubernetes Job，“Clean up finished jobs automatically” 与已完成 Job 的 TTL 机制，已核验 2026-09-16。
Kubernetes CronJob，默认历史上限与 job template，已核验 2026-09-16。
Kubernetes 垃圾回收，owner reference 与级联删除，已核验 2026-09-16。

Redis hash 用一个键装多个字段

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

Redis hash 是一个键下面可按字段访问的记录，不是自动校验模式的对象，也不是天然支持嵌套路径的文档。当调用方只需要部分属性、又不想替换整条记录时，它很有用。但是否划算取决于访问模式、字段大小和返回值语义，而不是只要选择 hash 类型，就自动得到廉价读写或完整业务一致性。

只读取调用方真正需要的字段

HGET 获取一个字段，HMGET 按请求顺序获取选定字段，HGETALL 则返回整个映射。在 redis-py 的二进制响应模式下，缺失字段表示为 None，存在但为空的值表示为空字节串。直接判断真假会把这两种情况错误地合并；对不存在的键执行 HMGET，同样得到对应位置的缺失值，并不会自动创建 hash。

字段名和字段值本质上都是字节。名字中含点号仍是字面名称，Redis 不会把 name.first 解释为进入嵌套对象再找 first。同样，包含 JSON 文本的字符串键还是字符串，HGET 不会替你解析 JSON。序列化和内容校验属于应用职责，“没有提供属性”和“明确写入空值”也应保留区别。

更新操作有精确的返回语义

HSET 只修改指定字段，未指定的字段保持不变。一次多字段 HSET 是一个命令，但其整数回复统计新增字段数量，而不是成功修改的总数。替换已有 name 完全可能成功返回零；如果把零视为失败，就会制造多余重试、错误告警，甚至触发不必要的补偿动作。

HINCRBY 在一个命令内完成整数递增，字段不存在时从零开始，拒绝非整数值以及超出有符号六十四位范围的结果。它避免的是这一项递增的读改写竞争，并不把外围的业务检查也变为原子操作。分别执行 HGET、在客户端计算、再执行 HSET，仍可能覆盖其他客户端已完成的修改。

HDEL 的返回值统计实际删除的字段，删除最后一个字段会让整个键消失。因此，不能靠空 hash 长期占位，表示某条实体存在。键级过期同样会删除其字段；当前 Redis 还支持字段级截止时间，不能沿用“hash 字段绝对不能单独过期”的旧结论。下面的实验没有设置任何过期时间，也不把结果作为生命周期验证。

紧凑编码是实现选择

小 hash 可以用 listpack 表示，而不是普通哈希表。Redis 8.10.1 的标准阈值是五百一十二个字段，以及每个字段名或值六十四字节；实际部署可能改过这些设置。触发适用限制后，内部表示会改变，但公开的 hash 操作和已经存储的内容不会因此变成另一种数据类型。

紧凑存储用内部扫描工作换取更少的管理开销及较好的局部性。大幅提高阈值前需要测量，不能把命令说明中的复杂度理解为“任意长字段、任意配置下都没有额外成本”。排查时可用 OBJECT ENCODING 观察编码，但应用正确性不应依赖这个内部标签，也不能预设每个对象都必定节省相同倍数的内存。

坏掉的样子

HGETALL 的工作量随整个 hash 增长，响应还要携带字段名和值。调用方只需要两项，却每次读取数千项，即使它们都在同一个键里，也是在浪费传输和处理资源。HMGET 的工作量随请求字段数增长，同样不是免费操作；返回映射的迭代顺序更不应成为应用的排序约定。

WRONGTYPE 表示该键存放了另一种 Redis 类型，并不是普通的字段缺失。非整数计数器也需要明确的数据处理决定，而不是不断重试。一个巨大的 hash 仍只是一个键，不会自动把字段分散到多个集群节点。应围绕真实的访问边界和归属划分记录，不要为了减少键名数量而把无关数据都塞到一起。

快速验证

准备 POSIX 环境、C 编译器、make、curl、tar，以及 Python 3.10 以上版本。实验已在 macOS、Redis 8.10.1、redis-py 8.1.0、Python 3.14.4 上运行。安装步骤仅用 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

在同一个 shell 中，用 "$redis_lab/venv/bin/python" 执行下面代码。它创建私有 Unix socket，不开放 TCP，关闭持久化。为了用小数据触发转换，只对这个测试进程设置四个字段、八字节的低阈值。实验结束后关闭客户端、终止自己创建的进程并清理临时目录，不会连接默认的本机 Redis。

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():
 with TemporaryDirectory(prefix="redis-hash-", 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,
 "--hash-max-listpack-entries", "4", "--hash-max-listpack-value", "8",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 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()


with instance() as client:
 assert client.hset("profile", mapping={"name": "Ada", "visits": "0", "empty": b""}) == 3
 assert client.hset("profile", "name", "Ada L") == 0
 assert client.hmget("profile", ["visits", "name", "missing", "empty"]) == [
 b"0", b"Ada L", None, b"",
 ]
 assert client.hmget("absent", ["a", "b"]) == [None, None]
 assert client.hgetall("profile") == {b"name": b"Ada L", b"visits": b"0", b"empty": b""}
 assert client.hincrby("profile", "visits", 1) == 1
 assert client.hget("profile", "name") == b"Ada L"
 print("HSET counts new fields; HMGET preserves order and distinguishes missing from empty")

 client.set("json", '{"name":"Ada"}')
 try:
 client.hget("json", "name")
 except redis.ResponseError as error:
 assert "WRONGTYPE" in str(error)
 else:
 raise AssertionError("a JSON string is not a hash")
 client.hset("literal", "name.first", b"Ada")
 assert client.hget("literal", "name") is None
 assert client.hget("literal", "name.first") == b"Ada"
 client.hset("invalid", "counter", "3.5")
 try:
 client.hincrby("invalid", "counter", 1)
 except redis.ResponseError as error:
 assert "integer" in str(error)
 else:
 raise AssertionError("an integer counter cannot contain 3.5")
 assert client.hget("invalid", "counter") == b"3.5"
 client.hset("overflow", "counter", 2**63 - 1)
 try:
 client.hincrby("overflow", "counter", 1)
 except redis.ResponseError as error:
 assert "overflow" in str(error)
 else:
 raise AssertionError("signed 64-bit integer overflow must fail")
 assert client.hget("overflow", "counter") == str(2**63 - 1).encode()
 print("wrong types and invalid or overflowing counters fail; dotted fields are literal")

 assert client.object("ENCODING", "profile") == b"listpack"
 assert client.hset("profile", "fourth", "ok") == 1
 assert client.object("ENCODING", "profile") == b"listpack"
 assert client.hset("profile", "fifth", "ok") == 1
 assert client.object("ENCODING", "profile") == b"hashtable"
 client.hset("value-limit", "field", b"abcdefgh")
 assert client.object("ENCODING", "value-limit") == b"listpack"
 client.hset("value-limit", "field", b"abcdefghi")
 assert client.object("ENCODING", "value-limit") == b"hashtable"
 assert client.hget("profile", "visits") == b"1"
 assert client.hget("value-limit", "field") == b"abcdefghi"
 print("private 4-field and 8-byte thresholds each trigger listpack to hashtable conversion")

 assert client.hdel("value-limit", "absent") == 0
 assert client.hdel("value-limit", "field") == 1
 assert client.exists("value-limit") == 0
 print("deleting the last field removes the hash key")

断言区分了新增字段与替换字段，确认 HMGET 保留请求顺序，也保留缺失与空值的区别，并检查未修改的相邻字段。JSON 字符串触发 WRONGTYPE，点号字段名仍按字面查找；非整数和溢出递增都被拒绝，原来的计数器内容没有改变。

profile 有四个短字段时仍为 listpack，加入第五个后变为 hashtable；另一个 hash 在值从八字节增长到九字节时也发生转换。转换后的读取结果依旧正确，最后一个字段被删除后，其键不再存在。这些结果展示的是受控配置下的编码转换和命令语义，不是生产内存节约比例、延迟、并发负载或集群分布的测试。

来源

Redis hash，字段操作与当前版本的过期能力，已核验 2026-09-08。
Redis HSET，局部更新和新增字段计数，已核验 2026-09-08。
Redis HMGET，请求顺序与缺失字段响应，已核验 2026-09-08。
Redis HGETALL，完整 hash 读取及其复杂度，已核验 2026-09-08。
Redis HINCRBY，整数递增与支持范围，已核验 2026-09-08。
Redis HDEL，删除计数和最后一个字段的处理，已核验 2026-09-08。
Redis OBJECT ENCODING，内部表示及其转换，已核验 2026-09-08。
Redis 内存优化，紧凑编码阈值和测量建议，已核验 2026-09-08。
Redis 8.10.1 配置，hash 默认阈值，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅构建核心与选择分配器，已核验 2026-09-08。

Grafana 变量必须与查询语言的语义一致

Wed, 23 Feb 2028 00:00:00 +0000

Grafana 仪表盘变量让同一组面板能够切换环境、服务或实例，而不必复制多份仪表盘。查询变量从数据源获得选项，自定义变量则可以维护一份有意固定的列表。这两种方式没有绝对优劣：当选项应跟随数据源发现结果变化时，可以使用查询变量；当选择范围就是一份较小且稳定的约定时，维护静态列表同样合理。变量是否合适，取决于它如何表达实际使用需求。

数据源执行查询之前，变量会先被代入查询表达式，所以变量格式本身属于查询正确性的一部分。Prometheus 多选场景应使用正则标签匹配，例如 environment=~"$environment"。Grafana 的 Prometheus 插值逻辑会把选中值处理为正则候选项，并执行所需转义。如果改用精确等号匹配，组合后的文本只会被当成一个标签值，并不会自动变成希望表达的多个环境选择。变量编辑器里的 label_values 是发现选项的辅助语法，不是可以直接复制到面板表达式中使用的 PromQL 函数。

检查最终送出的表达式

这里存在两层语法：正则表达式，以及包裹它的 PromQL 字符串。production.eu 中的点号应表示字面字符，不能成为同时匹配 productionXeu 的通配符。应让数据源按其约定完成插值；使用显式格式覆盖时，要检查真正发送出去的查询。raw 格式会绕过数据源格式化，并不是解决复杂变量值的通用办法。表面上省掉反斜线，可能只是把错误隐藏在返回的数字中。

全部选项也有明确语义。本例没有设置自定义的全部值，因此会展开经过筛选的可用选项。菜单只包含 production.eu 和 staging，全部选择就应覆盖这两个环境。如果把全部值改成点星号等自定义表达式，范围则可能扩大到后台正则允许匹配的其他标签。需要先决定这里的全部究竟指当前菜单中的值，还是更广的查询范围，再用刻意排除的数据验证这种决定。

坏掉的样子

查询变量不会保证永远新鲜，刷新设置决定了 Grafana 何时重新执行选项查询。选项依赖时间范围时，通常还需要随时间范围变化刷新。存在链式变量，也不保证每组上游选择都能找到下游组合；数据本来不存在时，结果完全可能为空。应当区分真实的空集合、已经陈旧的选择和查询错误，不能看到无数据提示，就直接把它解释为服务故障。

变量筛选不是权限控制。菜单里隐藏一个环境，并不会从数据源删除它，也不会阻止其他获准查询请求这些数据。访问边界需要在对应的 Grafana 配置与后台数据服务中落实。分享链接携带的同样只是选中状态，不是权限声明。多个环境通过重复的 var-environment 参数传递，不能随意发明一个逗号拼接的权限列表，再期望后台自动按访问规则理解它。

快速验证

保存代码为 grafana-variables.py，在准备好 Python 和 Docker 后，运行 python3 grafana-variables.py –serve。脚本在专用桥接网络中创建可删除的 Grafana 12.1.0 与 Prometheus 3.5.1 容器，仅通过本机回环地址暴露 Grafana，不挂载宿主机目录。打开输出的仪表盘地址，结束后按控制键加 C，脚本会删除两个容器及本次网络。不带服务参数运行时，只执行后台检查并立即清理。

import json
import secrets
import subprocess
import sys
import time
import uuid
from http.client import HTTPException
from threading import Event
from urllib.error import HTTPError, URLError
from urllib.parse import quote
from urllib.request import urlopen

prefix = "xbcatm-variable-" + uuid.uuid4().hex[:10]
network, prom, grafana = [prefix + suffix for suffix in ("-net", "-prom", "-grafana")]


def command(*args):
 try:
 result = subprocess.run(["docker", *args], capture_output=True, text=True, timeout=30)
 except subprocess.TimeoutExpired:
 raise RuntimeError("Docker " + args[0] + " timed out") from None
 if result.returncode:
 raise RuntimeError(result.stderr.strip())
 return result.stdout.strip()


def get(path):
 with urlopen(origin + path, timeout=5) as response:
 return json.load(response)


def eventually(check):
 for attempt in range(200):
 try:
 value = check()
 if value:
 return value
 except (HTTPError, URLError, TimeoutError, ConnectionError, HTTPException):
 pass
 time.sleep(0.1)
 raise AssertionError("Local lab did not become ready")


source = {"type": "prometheus", "uid": "lab_prom"}
dashboard = {
 "uid": "variable-lab", "title": "Variable escaping lab", "schemaVersion": 41,
 "version": 1, "timezone": "utc", "refresh": "", "time": {"from": "now-5m", "to": "now"},
 "templating": {"list": [{
 "name": "environment", "label": "Environment", "type": "query", "datasource": source,
 "query": {"query": "label_values(lab_active_workers, environment)", "refId": "VariableQuery"},
 "definition": "label_values(lab_active_workers, environment)",
 "regex": "/^(production[.]eu|staging)$/", "refresh": 1, "sort": 1,
 "multi": True, "includeAll": True, "allValue": "", "options": [],
 "current": {"text": ["production.eu"], "value": ["production.eu"], "selected": True},
 }]},
 "panels": [{
 "id": number, "title": title, "type": "stat", "datasource": source,
 "gridPos": {"h": 7, "w": 12, "x": (number - 1) * 12, "y": 0},
 "targets": [{"refId": "A", "expr": expression, "instant": True, "range": False}],
 "options": {"reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": False}},
 "fieldConfig": {"defaults": {"decimals": 0}, "overrides": []},
 } for number, title, expression in (
 (1, "Selected workers", 'sum(lab_active_workers{environment=~"$environment"})'),
 (2, "Unescaped control", 'sum(lab_active_workers{environment=~"${environment:raw}"})'),
 )],
}
prom_script = """set -eu
mkdir -p /tmp/www
cat > /tmp/www/metrics.txt <<'METRICS'
# HELP lab_active_workers Synthetic active worker count.
# TYPE lab_active_workers gauge
lab_active_workers{environment="production.eu"} 10
lab_active_workers{environment="staging"} 2
lab_active_workers{environment="productionXeu"} 100
METRICS
cat > /tmp/prom.yml <<'CONFIG'
global:
 scrape_interval: 1s
scrape_configs:
 - job_name: lab
 metrics_path: /metrics.txt
 static_configs:
 - targets: ['127.0.0.1:8080']
CONFIG
/bin/httpd -f -p 127.0.0.1:8080 -h /tmp/www &
exec /bin/prometheus --config.file=/tmp/prom.yml --storage.tsdb.path=/tmp/data
"""
grafana_script = """set -eu
mkdir -p /tmp/data /tmp/provisioning/datasources /tmp/provisioning/dashboards /tmp/dashboards
mkdir -p /tmp/provisioning/plugins /tmp/provisioning/alerting
cat > /tmp/provisioning/datasources/lab.yml <<'DATASOURCE'
apiVersion: 1
datasources:
 - name: Lab Prometheus
 type: prometheus
 uid: lab_prom
 access: proxy
 url: http://metrics:9090
 isDefault: true
 jsonData:
 timeInterval: 1s
DATASOURCE
cat > /tmp/provisioning/dashboards/lab.yml <<'PROVIDER'
apiVersion: 1
providers:
 - name: lab
 type: file
 options:
 path: /tmp/dashboards
PROVIDER
cat > /tmp/dashboards/lab.json <<'DASHBOARD'
""" + json.dumps(dashboard) + """
DASHBOARD
exec /run.sh
"""
try:
 command("network", "create", network)
 command("run", "-d", "--rm", "--name", prom, "--network", network, "--network-alias", "metrics",
 "--entrypoint", "/bin/sh", "prom/prometheus:v3.5.1", "-c", prom_script)
 command("run", "-d", "--rm", "--name", grafana, "--network", network,
 "-p", "127.0.0.1::3000", "-e", "GF_PATHS_DATA=/tmp/data",
 "-e", "GF_PATHS_PROVISIONING=/tmp/provisioning",
 "-e", "GF_AUTH_ANONYMOUS_ENABLED=true", "-e", "GF_AUTH_ANONYMOUS_ORG_ROLE=Viewer",
 "-e", "GF_AUTH_DISABLE_LOGIN_FORM=true", "-e", "GF_AUTH_BASIC_ENABLED=false",
 "-e", "GF_SECURITY_ADMIN_PASSWORD=" + secrets.token_urlsafe(24),
 "-e", "GF_ANALYTICS_REPORTING_ENABLED=false", "-e", "GF_ANALYTICS_CHECK_FOR_UPDATES=false",
 "-e", "GF_ANALYTICS_CHECK_FOR_PLUGIN_UPDATES=false", "-e", "GF_PLUGINS_PREINSTALL_DISABLED=true",
 "--entrypoint", "/bin/sh", "grafana/grafana:12.1.0", "-c", grafana_script)
 origin = "http://" + command("port", grafana, "3000/tcp").splitlines()[0]
 health = eventually(lambda: get("/api/health"))
 assert health["version"] == "12.1.0" and health["database"] == "ok"
 loaded = eventually(lambda: get("/api/dashboards/uid/variable-lab"))
 assert loaded["dashboard"]["templating"]["list"][0]["multi"] is True
 checks = {}
 for pattern, expected in ((r"production\\.eu", 10), (r"(production\\.eu|staging)", 12), ("production.eu", 110)):
 expression = 'sum(lab_active_workers{environment=~"' + pattern + '"})'
 result = eventually(lambda: get("/api/datasources/proxy/uid/lab_prom/api/v1/query?query=" +
 quote(expression, safe=""))["data"]["result"])
 value = float(result[0]["value"][1])
 assert value == expected, (expression, result)
 checks[expression] = value
 print(json.dumps({"app_url": origin + "/d/variable-lab/variable-escaping-lab",
 "grafana_version": health["version"], "query_checks": checks}), flush=True)
 if "--serve" in sys.argv:
 Event().wait()
except KeyboardInterrupt:
 pass
finally:
 for name in (grafana, prom):
 subprocess.run(["docker", "rm", "-f", name], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
 subprocess.run(["docker", "network", "rm", network], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

合成数据中，production.eu 有十个工作实例，staging 有两个，productionXeu 有一百个。只选择 production.eu 时，正确面板应显示十，刻意不转义的对照面板则显示一百一十。选择两个可用环境后，再选择全部选项，正确面板都应显示十二。此时对照面板会为空，因为原样格式生成的是逗号连接文本，不能匹配预期的两个正则候选项。这两类失败都有真实数据作对照，而不是只检查表达式看起来是否合理。

本次使用 Chrome 152 操作实际 Grafana 页面，核对了这三种选择送出的查询及返回值，重复的 URL 参数也产生了同样的多选结果。这证明的是所配置变量对合成数据的插值行为，没有验证租户隔离，也没有测量动态发现下选项的新鲜度。修改仪表盘时，可以保留被排除的环境作为回归数据；当变量类型、格式覆盖、刷新策略或数据源改变，都应重新检查最终表达式，而不只检查下拉框还能否打开。

来源

Grafana variables，变量类型与仪表盘复用，已核验 2026-09-13。
Grafana Prometheus template variables，多选正则匹配与选项刷新行为，已核验 2026-09-13。
Grafana variable syntax，数据源插值与显式格式覆盖，已核验 2026-09-13。
Grafana dashboard URL variables，以重复 URL 参数表达多个选中值，已核验 2026-09-13。

文章 · XB 现场笔记

InnoDB 死锁会回滚整个受害事务

坏掉的样子

快速验证

减少等待环，但不假定它们消失

来源

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

坏掉的样子

快速验证

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

延伸阅读

来源

LVM 快照在时间上定格一块块设备

异常存储，不是副本

耗尽即失效

合并回滚，以及 thin 如何改变失败形态

坏掉的样子

快速验证

来源

Consul 维护一份存活的健康服务清单

注册，以及两个层级的检查

调用方实际拿到什么

坏掉的样子

快速验证

来源

调度器计算资源请求，而不是瞬时使用率

以准入后的真实配置为依据

坏掉的样子

快速验证

来源

Baggage 通过明确的边界传播上下文

决定哪些信息可以传播、哪些需要记录

坏掉的样子

快速验证

来源

TCP backlog 收纳还在握手中的连接

backlog 参数管的是 accept 队列

syncookies 开着的时候，SYN 队列就不再是瓶颈

压力真正落在 accept 队列上

坏掉的样子

快速验证

来源

ZFS 快照给文件系统一个回退键

为一个一致的树命名

空间在哪里：zfs list -o space

hold、diff 与版本对比

坏掉的样子

快速验证

来源

Hugo 发布选项决定哪些页面进入产物

元数据和构建选项分别起作用

预览产物仍然可以被公开

坏掉的样子

快速验证

延伸阅读

来源

iotop 能看出是哪个进程在烧磁盘

逐个进程的计数器

看到谁在扫盘

先看再动

坏掉的样子

快速验证

延伸阅读

来源

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

坏掉的样子

快速验证

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

延伸阅读

来源

etcd 通过选举单一领导让写入有序

每个任期只有一个领导者

仲裁数的算术，以及为什么奇数更好

learner 成员，以及两套机制的分工

坏掉的样子

快速验证

来源

BPF tracepoint 能窥探正在运行的内核

不断流地探测

tracepoint 是更稳定的名字