文章

查询超时限制的是数据库工作中的某个阶段，不会自动覆盖连接池排队，也不保证远端已经取消执行或事务清理已经结束。要保护共享容量，必须说清由哪个组件计时、它到点会中断什么，以及错误返回之后还剩下什么状态。只有一个名字叫 timeout 的配置，不能构成完整的成本边界。 说清这只钟从何时开始，管哪段工作 PostgreSQL 的 statement_timeout 从命令到达服务器开始计时，直到服务器完成处理。它不是调用方整个请求的期限：此前获取连接池借用的等待，以及服务器完成之后客户端本地处理结果的时间，不在同一计时范围内。锁等待也可能消耗语句时间，因此“还没有真正开始做有用的查询工作”，不代表语句预算尚未开始使用。 lock_timeout 的含义更窄，分别约束每次尝试获取锁的等待，而语句超时也可以中断不在等锁的执行工作。事务中空闲会话的超时又是另一条边界：它针对已经打开事务、却正在等待客户端下一条查询的会话，并不是当前仍在执行的语句。把这些数值设成一样，并不会让它们获得相同作用；应先理解它们观察的是哪一种状态。 PostgreSQL 18 还提供 transaction_timeout，在显式或隐式事务超过预算时终止会话，可以约束由许多短语句组成的长事务。预备事务不受这个超时限制。它仍然是服务端的一条边界，不能代替调用方完整期限；增加一个配置项，也不能省略连接恢复与事务结果检查。 驱动参数也需要同样认真地阅读。Python 的 sqlite3.connect(timeout=...) 设置的是遇到数据库锁时最多等多久，不是所有 SQL 的执行总期限。不同驱动里都叫“超时”的参数，可能分别针对建连、锁等待或读取；只复制名称和数值，可能让真正昂贵的查询仍然完全没有执行时间限制。 坏掉的样子 调用方停止等待时，数据库仍可能继续执行。即便 PostgreSQL 的取消请求已经成功发出，也不能保证它实际改变了什么，因为原命令可能早已处理完成。需要观察命令结果与事务结果，不能把“捕获到超时异常”或“发出了 cancel”直接当成所有远端工作均已停止的证明，更不能据此断定是否可以安全重放有副作用的操作。 语句时间限制也不会退还已经花掉的资源。清理、事务恢复仍可能耗时，先前的操作也可能已有各自结果。连接归还池中之前，应完成所需恢复并核对状态，而不是在异常被捕获后立刻当作干净连接继续借出。如果报表契约要求完整结果，半份结果就不能因为“总比没有好”而自动变成成功，除非产品本来就明确允许这种部分结果。 阈值应从工作负载和请求预算出发，同时给连接获取、响应传输与恢复留下空间。把 p99 简单乘固定倍数，不是普遍成立的安全规则：百分位描述的是已经观察到的时长，并不能定义哪些业务请求本来就合理。PostgreSQL 文档也提醒，不应不加区分地在全局配置语句超时，因为那会影响所有会话；交互查询与明确安排的长时分析任务可能需要不同策略。 快速验证 把代码保存为 query_probe.py，运行 python3 query_probe.py。示例只使用标准库中的 SQLite，本次环境是 Python 3.12.14 和 SQLite 3.53.1。两条连接共享脚本自己的临时数据库文件，不连接 PostgreSQL，也不使用生产凭据。短时长与回调频率用于快速展示边界，不是推荐直接上线的默认参数。 ...

时间守护进程只有在实际状态满足应用要求时才真正有用。进程正在运行，仍可能没有可用来源；已经选择某个来源，也可能尚未充分测量，或者来源本身就不正确。时间服务健康应当是一条可观察的链路：来源配置、成功采样、选择状态、不确定性以及实际允许的时钟控制。进程显示绿色，只能覆盖链路最前面的一部分。 读取守护进程实际报告的内容 Chrony 的 tracking 输出分别给出参考来源、层级、最近更新时间、尚未消除的系统时间修正量、估计频率、频率偏斜不确定性、根延迟和根离散度。它们回答不同问题：offset 关注时间差，frequency 关注时钟走速，skew 反映频率估计的不确定性。根延迟与离散度则参与描述参考路径带来的时间不确定性。只挑一个很小的偏移数值，不能概括整个时钟质量。 sources 输出用于观察候选来源及实际选择。常见显示中的 ^* 表示选中的 NTP 服务器。Reach 是八进制历史位图，377 表示最近八次轮询机会都有成功响应，并不是百分比，也不保证下一次仍然可达。LastRx 有助于查看最近收到的样本已经过去多久。应把来源状态与 tracking 一起读，而不是把进程持续运行时长误认为同步证据。 上游短暂中断后，守护进程可能继续依据已有模型估计时间，但不确定性会随条件变化而扩大。需要根据应用容忍度监控更新时间和误差估计，区分短期维持与无限期可信。多个服务器名称也不必然意味着独立参考，如果它们共享上游或基础设施，仍然可能一起出错。来源选择降低部分故障风险，却不能证明所有上游声明都正确。 今天能够使用的来源，不能证明长时间断联之后启动服务仍然安全。应事先决定业务能否在维持估计期间启动，以及哪项实际测量超过边界就必须阻止启动。还要把这道检查与耗时测量分开：民用时间可能被校正，而超时逻辑需要合适的单调时钟，不能只因同步状态正常就混用两者。 坏掉的样子 容器通常共享宿主的内核时钟，在容器内运行时间服务并不会自然得到一块独立可调的民用时钟。Chronyd 的 -x 模式明确关闭系统时钟控制，但仍保留估计和提供时间服务的能力。因此，客户端可以报告已经同步，系统时钟却并没有被这个进程修正。排查时必须确认实际运行模式，以及哪一层负责宿主时间。 local 指令也容易制造错误信心。它允许 chronyd 在没有外部参考的情况下表现为已同步，可以用于有明确设计的隔离网络安排。但如果只是为了消除告警而启用，就会把缺失参考这一问题隐藏起来。解释 Normal 之前，要核对参考标识以及预期来源政策，不能把某种协议状态直接解释成 UTC 已经准确。 运行检查还需要有意义的限制。Chronyc 的 waitsync 可以等待同步，并可选地限制剩余时间修正量和频率估计偏斜；相应限制为零时，额外约束会被关闭。两个限制都关闭的成功结果，比执行应用专属容忍边界的检查弱得多。即使配置了边界，它也不能替任意上游时钟证明真实性，来源信任仍是另一项要求。 快速验证 使用新的临时 Debian 12 Docker 容器，运行 apt-get update 和 apt-get install -y python3 chrony 安装依赖，将下面代码保存为 chrony-status.py，以 root 执行 python3 chrony-status.py。创建容器时保持独立网络，不使用宿主网络，并移除 SYS_TIME 能力。实测版本为 chrony 4.3 与 Python 3.11.2，代码只在回环地址通信。 ...

经典的三二一备份规则要求三份数据，分布在两类存储介质上，其中一份位于异地。正在使用的数据本身算一份，因此还需要两份备份。规则的作用是开始拆分共同故障影响，并不保证任意三个文件名都能抵抗硬件故障、误删、管理凭据被盗，或者被同步传播到所有副本的错误。 坏掉的样子 副本之间共享的可能不仅是内容。两个目录可能在同一块盘上，两个虚拟卷可能依赖同一个存储阵列，若干远端备份也可能都能被已经失陷的生产管理员删除。因此，设备、地理位置和访问权限边界需要分别检查。异地降低了本地灾害的共同影响，却不会自动使数据变成离线或不可修改状态。 硬链接是“只数名字”的直接反例。它给同一个底层文件增加目录入口，原地修改文件时，两个名字所看到的内容都会变化。单独复制出来的文件可以抵抗这一种修改，保留较早字节，但仍然可能与原文件共享设备和管理权限风险。因此，“不是同一个文件”和“具备独立灾难恢复能力”之间还有很大距离。 同步也可能造成误判。一个迅速传播删除的镜像，会把恢复所需的旧版本一起移除。保留时间与版本选择，和目标数量一样重要。校验和可以发现内容与可信预期值不符，但若攻击者可以同时替换文件和校验值，同一权限范围内保存的校验和本身并不能证明没有发生恶意替换。 快速验证 把以下内容保存为 copies_lab.py，在支持硬链接的文件系统上用普通 Python 运行，并保持断言开启。脚本只使用标准库和临时文件。两个目录名模拟位置，实际上仍在同一个本地文件系统中。这是一次修改隔离与恢复演练，不是这台机器已经拥有真正异地备份介质的证明。 import hashlib import json import os import shutil import tempfile from pathlib import Path def digest(path): return hashlib.sha256(path.read_bytes()).hexdigest() with tempfile.TemporaryDirectory(prefix="xbcatm-copies-") as directory: root = Path(directory) primary_site = root / "site-a" other_site = root / "site-b-simulation" primary_site.mkdir() other_site.mkdir() primary = primary_site / "account.json" primary.write_text('{"account":"example","balance_cents":2500}\n') expected = digest(primary) alias = primary_site / "hardlink.json" os.link(primary, alias) independent = other_site / "snapshot.json" shutil.copy2(primary, independent) assert os.path.samefile(primary, alias) assert not os.path.samefile(primary, independent) primary.write_text('{"account":"example","balance_cents":0}\n') assert digest(alias) != expected assert digest(independent) == expected print("hardlink_changed_with_primary") print("independent_copy_kept_original_bytes") primary_site.rename(root / "site-a-unavailable") assert not primary.exists() restored = root / "restored.json" shutil.copy2(independent, restored) assert digest(restored) == expected assert json.loads(restored.read_text()) == {"account": "example", "balance_cents": 2500} print("restored_without_original_path", 2500) assert independent.stat().st_dev == restored.stat().st_dev print("same_filesystem_lab_not_real_offsite_protection") 夹具最初保存一个余额为两千五百分的账户。随后创建硬链接名字和单独复制的快照，并在修改源文件之前记录预期摘要。文件身份检查明确哪一个路径仍指向同一文件。一次原地写入把源文件改为零，硬链接看到的值也随之变化；独立复制的文件则继续保持预期字节。 ...

HTTP 幂等关注的是重复同一个请求时，服务器上预期发生的效果，而不是每次响应是否一模一样。服务器可能已经执行修改，却在客户端收到答案之前断开连接；这时重复请求可能合理，但前提是操作的真实语义允许重复，并且客户端仍遵守有界重试政策。不能把“可以重复”扩大成所有失败都应该立即重试。 相同效果，不代表相同响应 RFC 9110 用多次相同请求与单次请求的预期服务端效果来定义幂等。PUT、DELETE 和安全方法都属于幂等方法。第一次成功 PUT 可能创建资源并返回 201，再次发送则可能替换已有资源并返回 204；先删除存在的资源，再删除已经不存在的资源，也可以返回不同状态码，但最终都让目标保持不存在。 “安全”是另一种性质：客户端没有请求改变状态。GET、HEAD、OPTIONS、TRACE 被定义为安全方法，但允许附带访问日志等行为，因此不是说服务器任何地方都绝对不能写入。PUT 和 DELETE 可以符合幂等语义，却不是安全方法；把两个概念混用，会影响自动抓取与重试策略。 方法名称需要实现来兑现 把一个每次递增的接口命名为 PUT，不会让重复递增自动变成幂等。服务器需要真正兑现公开的方法语义。同样，用 GET 删除指定对象违反安全方法的约定，预取器或爬虫可能在没有删除意图时触发它。不能因为请求行上写着某个词，就跳过对业务状态变化的检查。 POST 通常不保证幂等，但某个具体 POST 操作可以通过应用层契约去重；它的用途也不局限于创建资源。自动重放之前需要理解实际契约，不能断言所有 POST 都不能重试，也不能反过来认定所有使用幂等方法名称的接口都已经正确实现。 天然可重复的写入与记住操作键，解决的是相关但不同的问题。用指定表示替换资源，是表达希望得到的状态；凭借幂等键重放订单创建，则是在识别某次特定行动。两者都不意味着每一个内部函数、访问日志或辅助步骤只会执行一次。 前置条件处理的是竞争修改 幂等本身不能阻止覆盖另一个客户端在两次请求之间写入的新内容。重复无条件替换，可能把自己的旧值重新盖到别人的新值之上。通过强实体标签与 If-Match，可以要求目标仍然是之前观察到的表示，才允许执行这次修改，而不是只比较方法名称。 条件重试也可能在原修改已经成功后失败：第一次写入完成却丢了响应，原先的标签已经不匹配。实验在这种情况下返回 412。RFC 9110 也允许服务器在判断所要求的修改已经应用时返回成功，因此不能把实验的一个选择当成所有服务必须采用的行为。 遇到结果不明确，应重新核对当前资源，或查询相应操作记录。一个状态码不足以还原多个写入者的全部先后历史；读到期望值，也不自动证明它只可能由自己那次请求产生。 坏掉的样子 盲目重试会放大负载、耗尽截止期限、重复不受保护的计费副作用，或覆盖中间写入。需要限制尝试次数和总耗时，保留原来的目标与请求意图，并遵守适用的服务端等待提示。幂等既不是并发控制方案，也不是无限重试的许可。 还应区分预期资源修改与附带日志、版本历史。出现两条诊断记录，本身不能证明业务效果发生了两次；反过来，两份看起来相同的成功响应，也不能证明只执行了一次业务行动。判断重复效果，需要读取有权威性的业务状态，而不是仅比对响应文本。 快速验证 保存为 methods_check.py，用 Python 3.10 以上版本执行 python3 methods_check.py。实验已在 Python 3.14.4 上运行，只使用标准库。代码会向自己创建的回环 HTTP 服务发送真实请求，端口由系统分配，完成后停止服务；所有业务状态都留在测试进程内存中，不访问线上系统。 ...

选择隔离级别，应从操作必须维持的不变量出发。一致快照很有用，但两个事务可能分别作出看似合理的决定，却在一起提交后得到错误结果。PostgreSQL 的可重复读保持事务读取快照稳定，仍允许部分序列化异常。可串行化则增加依赖检测，拒绝无法解释为任何串行执行顺序的并发组合，同时要求应用处理相应重试。关键是知道业务依赖哪项保证，而不是单纯选择一个听起来更强的名称。 可重复读能保持双方快照稳定，却仍破坏跨行规则。受控可串行化顺序拒绝 B；完整重试重新读到一人，不再更新。此图不增加运行验证证据。 稳定视图与正确决策分开判断 假设有两名值班医生，要求至少一名留岗。每名医生只有在看到可用人数大于一时才允许离开。两个可重复读事务可以都看到两人，然后分别把不同医生标记为离岗。它们没有覆盖彼此的同一行，因此都可能提交，最后值班人数变成零，即使每个事务都使用了内部稳定的快照。 这叫写偏差，不是对同一行发生丢失更新。分别检查每个医生布尔字段是否合法，并没有表达“总人数至少为一”的全局规则。只保护自己正在修改的那一行，也会漏掉两个决定之间的联系。适用的序列化协议需要覆盖整个不变量，而不只是其中某个局部字段。 具体数据库实现也很重要。PostgreSQL 把读未提交映射为读已提交；它的可重复读会阻止幻读，尽管 SQL 标准允许这一等级存在幻读。这些特性仍不会消除写偏差。因此，应根据引擎文档解释隔离名称，不能假定所有数据库同名级别的实现完全一样，更不能把某一种异常被排除当成所有并发问题都解决。 坏掉的样子 把可串行化理解为数据库实际每次只执行一个事务，会误导性能判断。PostgreSQL 仍并发运行事务并跟踪依赖，某个事务可能在执行途中或提交时收到 40001。应用需要用新的读取重做完整决定，不能只重新提交，也不能继续使用被拒绝快照中计算出来的值。否则虽然换了一次事务，决策前提仍然是旧的。 可串行化也不能修复一个独自运行时就违反业务规则的事务。所有相关写入路径都必须遵守既定契约；如果另外一条不受限制的更新允许最后一名医生离岗，不变量仍会被破坏。更高隔离提供并发保证，不会自动实现尚未编写的业务逻辑。实验中的条件判断与隔离级别必须一起成立。 快速验证 在同一个可丢弃的 PostgreSQL 18 数据库中，打开甲、乙两个新的 psql -X -v ON_ERROR_STOP=1 会话，使用相同角色，显式事务外保留正常自动提交，并选用尚未使用的模式名称。严格遵守下面顺序；先让两边读取重叠，才能建立要观察的竞争决策。 在甲中创建初始值班表。 CREATE SCHEMA isolation_demo; CREATE TABLE isolation_demo.doctors (id integer PRIMARY KEY,on_call boolean NOT NULL); INSERT INTO isolation_demo.doctors VALUES (1,true),(2,true); 先在甲中开始事务并读取，再在乙中执行对应操作。两边人数都应为二。 BEGIN ISOLATION LEVEL REPEATABLE READ; SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call; BEGIN ISOLATION LEVEL REPEATABLE READ; SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call; 在甲中更新第一名医生，再在乙中更新第二名。每条更新也会在自己的快照中检查人数规则。 UPDATE isolation_demo.doctors SET on_call=false WHERE id=1 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id; UPDATE isolation_demo.doctors SET on_call=false WHERE id=2 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id; 先提交甲，再提交乙。两边结束后，在甲中查看已经失效的不变量并重置值班表。 COMMIT; \set ON_ERROR_STOP off COMMIT; \echo commit_state :SQLSTATE \set ON_ERROR_STOP on SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call; UPDATE isolation_demo.doctors SET on_call=true; 使用可串行化重复这组重叠决策：开始甲、开始乙、更新甲、更新乙、提交甲，最后尝试提交乙。 BEGIN ISOLATION LEVEL SERIALIZABLE; SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call; BEGIN ISOLATION LEVEL SERIALIZABLE; SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call; UPDATE isolation_demo.doctors SET on_call=false WHERE id=1 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id; UPDATE isolation_demo.doctors SET on_call=false WHERE id=2 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id; COMMIT; \set ON_ERROR_STOP off COMMIT; \echo commit_state :SQLSTATE \set ON_ERROR_STOP on 在甲中检查人数，在乙中以新事务重做完整决定，最后在甲中核对并清理。 SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call; BEGIN ISOLATION LEVEL SERIALIZABLE; SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call; UPDATE isolation_demo.doctors SET on_call=false WHERE id=2 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id; COMMIT; SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call; DROP SCHEMA isolation_demo CASCADE; PostgreSQL 18.6 实测中，可重复读的两个提交都成功，可用人数变成零。在受控的可串行化顺序下，甲提交成功，乙提交返回 40001，仍有一名医生留岗。代码只在需要观察的提交周围关闭遇错停止，让 psql 能打印 SQLSTATE；如果出现其他错误，不能把它当成预期的序列化拒绝。 ...

限流是一份关于获准工作量的预算，需要明确单位、身份、作用范围和时间规则。只说“五次请求”还不够：要说明是谁的请求、覆盖哪些入口与工作进程、按什么区间计数，以及耗尽后如何处理。即使用了共享计数器，也只有所有相关请求都经过同一个权威准入决定，才能落实共享预算。 每个调用方分别对同一预算键调用一次原子脚本。五次获准、十一次拒绝，是十六次调用的实验合计断言。实际内容审计仍将并发 Unix socket 运行标为受阻；本次没有运行 Redis，也不增加竞争或过期验证证据。原子执行不证明故障转移持久性，或与后续业务副作用构成事务。 先定义政策，再开始计数 一次请求可以消耗一个单位，也可以按预计工作量或字节数加权。按准入尝试、成功执行或退还额度分别记账，必须由契约明确规定，不能在实现中悄悄混用。获得预算只意味着允许继续执行，不保证后续业务操作一定成功，也不等于为成功结果预留了全部资源。 窗口算法并不相同。固定窗口可能在边界附近允许突发，滚动窗口衡量的是另一段区间；令牌桶允许迅速花掉已经积累的额度，并不会自动把请求均匀发出。这些算法本身也不限制仍未结束的慢操作数量，准入速率不能替代执行并发上限。 账号、路由、地域和整个服务的预算分别回答不同问题。剩余额度只是某个时刻的快照，并不是为调用方预留的位置：其他工作进程可能先把它用掉。各进程各自维护同样大小的本地计数器，会放大实际额度，除非存在明确的分配规则，将总预算拆给不同参与者。 把准入决定做成原子操作 把数据放进同一个 Redis 键，不会让客户端的一串命令自动变成原子操作。两个调用方可能都读到尚有额度，各自决定继续，再分别递增。每个 INCR 都是原子的，但之前的比较发生在它外面，所以最后总量仍可能超过承诺，不能只检查单条命令的原子性。 下面的示例将比较、首次创建计数器并附加过期时间、后续递增放进一个很短的 Lua 执行。窗口从首次获准请求开始；拒绝既不增加计数，也不延长截止时间。所有调用方传入同一个键和固定的正参数，实验独占这个数值计数器，不与其他业务共享它的写入权限。 这是从首次到达开始计时的窗口，不是持续滑动的配额。脚本执行不被其他命令交错，也不等于自动回滚、持久预留，或与应用业务操作构成同一个事务。Redis 执行脚本时会阻塞其他服务活动，因此应保持脚本简短；连接丢失应视为结果未知，不能直接断言额度从未被扣除。 准确解释拒绝结果 RFC 6585 用 HTTP 429 表示请求速率过高，但把身份选择和计数政策留给服务器决定。响应应解释条件，可以附带 Retry-After；429 响应不得被缓存保存。整个服务暂时不可用，与某个调用方超过自身额度，是两种不同情况，不应仅为了统一返回格式就抹掉区别。 ...

健康检查端点是运维决策的一项输入，不是证明服务一切正常的通用证书。一个只返回 200 的小端点并非天然没有价值；如果消费者只需要确认这条处理路径能够回答，它就能提供有限但明确的证据。问题出在把“这个处理器回答了”扩大解释为“每一类用户请求都一定成功”。 写清问题，也写清消费者 存活检查关注应用是否进入了适合通过重启恢复的状态；就绪检查关注当前实例是否应该接收其契约覆盖的流量。诊断面板可以汇总更广泛的问题，但显示一项异常，不等于应该授权调度器立即重启实例。这些信号可以相关，却不应该默认触发同一种动作。 消费者决定信号是否真正生效。一个从不访问该端点的路由器，不会因为它开始返回 503 就自动摘除实例；就绪变更也不会撤销已经到达的请求。应写明谁来轮询、什么结果算失败、哪些流量受影响，以及判断传播需要多久，避免只有端点而没有行动链路。 必需依赖不等于所有依赖 严格必需的依赖可以合理地影响就绪：如果缺少必需输入，实例确实可能只能返回错误。但是，一份允许省略附加说明的报表，不应仅因可选注释服务暂时失效就完全退出服务。判断依据应是产品仍然支持什么结果，而不是依赖清单上列了多少组件。 同一个共享依赖故障，可能让全部副本同时不就绪。摘除所有副本不会修复这个依赖，还可能一并停止本来仍可工作的其他路由。把每个后端检查串到同一个流量闸口之前，应确认服务边界和降级响应契约，而不是认为“检查越深就一定越安全”。 远程依赖故障通常不应直接进入存活判断，除非有证据表明重启本进程能修复当前状态。数据库不可用时连续重启所有应用实例，往往只是增加初始化开销，并不能让数据库恢复。存活失败对应的恢复措施，也需要作为检查设计的一部分接受验证。 信号既要廉价，也要有时效 频繁执行的存活与就绪检查，不应反复运行昂贵的业务工作。反复生成报表、扫描数据表或占用紧张的连接，可能把检查对象进一步压垮，也会让探针自身制造的负载混入观察结果。检查耗时和并发开销应有边界，不能无限借用正常请求的资源。 端点可以暴露最近观察到的依赖状态，而不必每轮都同步访问所有后端，但这会改变契约：观察结果能保存多久、过期后如何判断，都必须明确。永久缓存的绿色标记可能掩盖故障，过于激进的过期策略又可能错误地移除健康容量，二者都需要现实证据来校准。 响应应小而明确，不向外暴露凭据、内部拓扑或完整异常栈。Cache-Control: no-store 告诉遵守 HTTP 缓存规则的中间层不要保存响应，但它既不是认证机制，也不能证明端点内部使用的健康观察足够新。响应缓存时效与观测数据时效是两个不同的问题。 坏掉的样子 独立的轻量 HTTP 处理器可能继续回答，而业务工作线程早已死锁；反过来，过深的存活检查也可能把一次外部波动变成重启风暴。无论路径叫 health、live 还是 ready，名字和绿色状态都不能证明所测条件与预期恢复动作真正对应。 路径写错、认证重定向、中间层缓存和探针网络不可达，都可能产生误导结果。因此，应测试消费者实际访问的路径，而不只是在进程内部调用一次函数。过紧的超时和失败阈值，也会让只是暂时繁忙的健康实例反复被摘除，进一步增加剩余实例压力。 Google SRE 区分内部观测与面向用户行为的黑盒检查。可以合理组合两者：从外部请求一份报表，能够发现内部就绪标记遗漏的用户路径故障，但这个外部失败仍不应不经判断就变成重启命令。发现症状、判断原因和决定动作，需要保持清楚的联系。 快速验证 保存为 health_check.py，用 Python 3.10 以上版本执行 python3 health_check.py。实验已在 Python 3.14.4 上运行，只使用标准库。真实 HTTP 服务绑定系统分配的回环端口；依赖只是注入的状态标记，并非真实数据库。实验明确约定：报表可以在缺少可选注释时继续返回基础内容。 ...

键集分页从客户端上一页实际收到的最后一个排序键继续。它不再从当前结果开头数过多少行，而是把候选行与一个具体边界比较。因此，信息流顶部新插入一条记录时，后面的页不会仅因位置整体后移就跟着错开一行。但这种方法不会冻结整个数据集，也不承诺后续每次请求都读取同一份记录。 坏掉的样子 单独使用时间戳，通常无法给出唯一边界。即使时间精度很细，多行也可能拥有相同创建时间。严格比较会跳过尚未返回的并列记录，包含等号的比较又可能重复已经展示的行。正确做法是增加一个唯一的决胜字段，并在排序与继续查询的谓词中始终使用完整键，不能一边按两个字段排序，另一边只保存其中一个。 排序字段可修改时，会产生另一类问题。已经展示过的行可能移到游标后面，于是再次出现；尚未展示的行可能移到游标前面，于是后续翻页一直看不到它。删除记录、改变过滤条件的匹配状态，也会改变下一次请求能够返回的内容。比较边界保持不变，并不能让持续变化的数据具有不可变快照的性质。 偏移分页也有明确用途：它表达当前查询结果中的编号位置，适合需要页码的界面。但在下一次偏移位置之前插入记录，可能造成重复；删除记录则可能造成遗漏。无论哪一种分页，只因为接口返回字段叫作“一页”，都不会自动获得跨请求的一致快照。需要先把产品希望保证的事情说清楚。 快速验证 把 SQL 保存为 cursor.sql，连接可丢弃的 PostgreSQL 数据库，运行 psql -X -v ON_ERROR_STOP=1 -f cursor.sql。确认实验模式 article_cursor 没被使用，并保持自动提交。遇错即停，避免建模式失败后继续操作已有对象，甚至执行最后的清理。记录中的运行版本为 PostgreSQL 18.6。实验特意让每个时间戳对应两行，先保存实际返回的第一页，再向顶部插入新行，最后修改两个已有排序键： CREATE SCHEMA article_cursor; SET search_path=article_cursor,public; SET TIME ZONE 'UTC'; CREATE TABLE feed (id bigint PRIMARY KEY,published_at timestamptz NOT NULL); INSERT INTO feed VALUES (1,'2026-01-01 10:00:00+00'),(2,'2026-01-01 10:00:00+00'), (3,'2026-01-01 11:00:00+00'),(4,'2026-01-01 11:00:00+00'), (5,'2026-01-01 12:00:00+00'),(6,'2026-01-01 12:00:00+00'); CREATE INDEX feed_order ON feed (published_at DESC,id DESC); CREATE TEMP TABLE first_page AS SELECT id,published_at FROM feed ORDER BY published_at DESC,id DESC LIMIT 3; SELECT array_agg(id ORDER BY published_at DESC,id DESC) FROM first_page; SELECT published_at AS cursor_time,id AS cursor_id FROM first_page ORDER BY published_at,id LIMIT 1 \gset SELECT array_agg(id ORDER BY published_at DESC,id DESC) FROM feed WHERE published_at<:'cursor_time'::timestamptz; PREPARE after_cursor(timestamptz,bigint) AS SELECT array_agg(id ORDER BY published_at DESC,id DESC) FROM ( SELECT id,published_at FROM feed WHERE (published_at,id)<($1,$2) ORDER BY published_at DESC,id DESC LIMIT 3 ) AS page; INSERT INTO feed VALUES (7,'2026-01-01 13:00:00+00'); SELECT array_agg(id ORDER BY published_at DESC,id DESC) FROM ( SELECT id,published_at FROM feed ORDER BY published_at DESC,id DESC LIMIT 3 OFFSET 3 ) AS page; EXECUTE after_cursor(:'cursor_time'::timestamptz,:cursor_id); UPDATE feed SET published_at='2026-01-01 09:00:00+00' WHERE id=6; UPDATE feed SET published_at='2026-01-01 14:00:00+00' WHERE id=3; EXECUTE after_cursor(:'cursor_time'::timestamptz,:cursor_id); DEALLOCATE after_cursor; DROP TABLE first_page; DROP SCHEMA article_cursor CASCADE; 第一个数组是 {6,5,4}，因此游标来自编号四的时间戳与编号。代码先把真正返回的第一页保存到临时表，再从它取得边界，而不是另外查询一次正在变化的原表来猜测客户端看到了什么。在读写交错时，这个区别直接决定后续边界是否对应上一份响应。 ...