文章

范围分区把边界定义变成写入路由规则。PostgreSQL 按键值把行放到能够接受它的分区，无论这条数据准时到达，还是晚了几个月。任何查询获得裁剪收益之前，都需要先定义正确边界、使用匹配的时间类型，并安排缺失范围的处理流程。分区建表成功，只是这些条件中的一部分。 使用相邻的左闭右开范围 范围分区包含下界，不包含上界。九月可以从九月一日开始，一直到十月一日之前；十月正好从同一边界开始，双方不会重叠。不要靠猜测一个月最后可表示的时间戳来定义范围。相邻的左闭右开区间，不依赖时间字段究竟保留多少位小数，也能避免边界遗漏。 查询同样需要准确表达区间。大于等于下界、小于上界的条件，适合描述一个月的数据。BETWEEN 包含两个端点，因此，把下月第一瞬间写成其上界，可能把下个月的数据也查进来。分区路由只能执行数据布局规则，不能替一个请求了错误区间的条件修正业务含义。 分区键类型与时区也是定义的一部分。timestamptz 代表瞬间，不带时区的 timestamp 则代表没有对应时区解释的本地日期时间。示例为每个边界显式写出 UTC 偏移。如果业务月份按另一个时区划分，应根据那个时区的规则推导边界，而不是假定所有本地日期都对应相同的实际时长。 缺失范围是一种运维状态 没有分区接受新键值时，插入会报错，除非 DEFAULT 分区能够接住它。日历进入新月份，并不会让 PostgreSQL 自动创建下一张月表。应在写入需要之前创建范围，同时考虑迟到数据和旧日期修正。输入键不必单调增长，路由照样能够工作；关键是相应目标范围仍然存在。 DEFAULT 可以接收显式范围之外的值，减少立即发生的插入失败，但如果不检查默认表，也会掩盖分区管理遗漏。持续增长的默认分区可能混入多个互不相关的时间范围，让后续整理更困难。应让“有意保留的例外数据”与“忘记创建分区的日常数据”保持可辨认，不能把插入暂时不报错当成管理正常。 新增显式分区，会改变默认分区能够接受的值。如果新范围对应的行还留在 DEFAULT 中，PostgreSQL 会拒绝变更，而不会允许两处同时拥有这批数据。应先把这些行迁移到合适的暂存表或按规则处理，再挂载新分区。边界是被执行的数据规则，不是可以随意标错的说明标签。 坏掉的样子 下一月分区未创建时，部署可能恰好在跨月瞬间出现写入失败。补建分区又可能因为 DEFAULT 已经积累对应行而失败。这两种问题都属于路由和数据位置，不是规划器统计陈旧。应先检查被拒绝的键和当前边界，再决定操作，不能直接运行 ANALYZE 或改索引，希望它们修复缺失范围。 ATTACH 可能扫描候选表以验证边界，也可能检查默认分区中是否存在冲突数据。合适且已验证的约束能省去部分扫描，但操作仍需要锁，并要求表结构兼容。PostgreSQL 十八的 ATTACH 在父表上取得 SHARE UPDATE EXCLUSIVE，在候选表和存在的 DEFAULT 表上取得 ACCESS EXCLUSIVE。省掉验证扫描，并不等于省掉这些取锁要求。活跃表上迁移数据时，需要协调写入者和锁获取；一个隔离环境中的事务示例，不是完整的在线迁移操作方案。 ...

agent 转发并不等于 agent 本身。本地 agent 可以替客户端完成认证操作，而不把私钥交给服务器；转发则进一步在远端开放一个套接字，让那边的程序也能请求这项服务。因此，「私钥材料留在本地」和「身份认证能力只留在本地」是两个不同的承诺。 选择堡垒机访问方式时，这个区别尤其重要。如果只是要登录内网机器，通常用 ProxyJump 并关闭 agent 转发就够了。只有程序确实需要在远端发起认证，例如一条经过明确授权的后续 SSH 连接，才需要考虑把 agent 的使用能力交过去。不要把网络可达性和身份委托混成一个开关。 远端拿到的是能力 转发出来的套接字通常通过远端的 SSH_AUTH_SOCK 暴露。能访问它的进程，包括拥有足够权限的本机攻击者，都可以向原始 agent 请求操作。这不意味着服务器上的任何普通账户都有权限，更不意味着私钥文件已经被复制过去；风险来自可以调用身份，而不是必须先偷到密钥。 一把没有额外约束的已加载密钥，在转发通道仍然可用时，可能被拿去完成你没有打算批准的登录。密钥的存活期、逐次确认、目标限制，以及目标服务器是否接受这个身份，都会改变请求能否成功。把它说成「完整拥有私钥」不够准确，把它说成「只是一只无害套接字」同样会误导操作判断。 旧版本曾把一枚没有解释来源的八十八字节签名当作证据。单看长度，既不能证明实验实现了 OpenSSH agent 协议，也不能证明一次经过转发的认证成功。下面改用真正的 SSH 客户端，验证一个范围明确、读者可以复现的性质：最终生效的转发选项。这个检查不冒充真实网络集成测试。 转发由生效配置决定 命令里没有 -A，并不代表关闭了转发。匹配的 Host 段、被包含的配置文件，或者系统配置，都可能已经把它打开。反过来，即使文件写着 ForwardAgent no，命令行上的 -A 仍会显式启用转发。需要关闭时，应当使用 -a，或者没有相互矛盾选项的 -o ForwardAgent=no。 ProxyJump 提供到目标的 TCP 路径，并不会顺便重置目标连接的转发选项。目标 SSH 连接及其认证仍从本地发起，所以单纯借道跳板机不需要把 agent 暴露过去。目标和跳板机的配置也不一定一样，应分别检查相应别名，不要把某一条 ssh -G 的输出理解成整条路径的所有设置。 ...

排名函数为分区内的每一条输入行附加位置，不会把整个团队、部门或客户的数据压缩成一行聚合结果。真正需要选择的是并列的含义：每行占一个独立位置、允许并列且保留空位的竞赛名次，还是按不同分数组连续计数的名次。三种规则解决的问题不同，应先确定业务规则再写窗口。 三个问题对应三种排名 row_number() 从一开始给每行分配连续整数。如果两行的排序值完全相同，而窗口没有其他区分条件，它们的相对序号没有保证。需要恰好选出两位获胜者时，可以按分数降序，再按稳定且唯一的标识排序。这意味着同分时由标识决定谁占据剩余名额，不能把这个结果当成不影响业务的技术细节。 rank() 给同组并列行分配该组第一行的位置。分数为一百、九十、九十、八十时，名次依次为一、二、二、四。两位第二名占用了两个位置，因此下一档分数前面会留下空位。dense_rank() 则计算同分组的数量，对同一批数据给出一、二、二、三，不会因并列人数增加而跳号。 并列组由窗口 ORDER BY 中的全部表达式决定。如果把唯一标识也加入 rank 的窗口，即使本意只是稳定展示顺序，也会让原来的同分行不再并列。row_number 需要标识裁决、rank 需要保留同分时，应使用不同窗口定义。最终结果的展示顺序可以由外层 ORDER BY 控制，不必因此改掉排名所依据的并列关系。 明确分区与过滤时机 PARTITION BY 让每个组从头编号。不写分区条件时，窗口看到的所有输入行属于同一个分区。这和窗口帧是不同概念：排名依据分区顺序和并列组，不是对某段移动聚合帧计数。添加 ROWS 边界，不会把 rank 变成“这个边界内有多少行”的函数。 窗口看到的是 FROM、WHERE、分组和 HAVING 处理后剩余的行。因此，在同层查询中过滤，可能先删掉部分竞争者，再计算名次。如果需要先给所有人排名，再挑前几个位置，应在子查询或 CTE 中生成窗口值，然后到外层过滤。PostgreSQL 不允许直接把窗口函数放进 WHERE，这也提醒读者区分排名输入与排名输出。 “前两名”必须有明确含义。位置不大于二，每个分区最多返回两行；竞赛名次不大于二，会保留全部并列第二名，结果可能超过两行；密集名次不大于二，则选择前两个不同分数组。当第一档分数本身就有多人并列时，密集排名与竞赛排名的筛选结果也可能不同。这些是不同的结果集合，不是可以随意互换的性能写法。 排名保留的是当前查询提供的行，不保证原始实体恰好一行。一对多连接可能在编号之前复制参赛者，导致同一实体占据多个位置。应先说明输入粒度并解决非预期的连接膨胀，再筛选前若干名。事后添加 DISTINCT 即使删掉重复输出，也不一定修复已经计算的名次；连接产生的行数本身就是排名语义的一部分。 坏掉的样子 row_number 缺少确定的并列裁决条件时，同分选手可能在重复查询中交换位置。反过来，在所有窗口都添加标识，又可能悄悄消除 rank 本来要保留的并列。测试时必须放入恰好卡在截止名次上的同分数据，不能只测每个分数都不同的情况。如果分数允许 NULL，还应明确空值顺序；PostgreSQL 降序默认把空值放前面，需要时应显式指定 NULLS LAST。 ...

Server Name Indication（简称 SNI）在 TLS 握手中把目标主机名发给服务器，于是同一个 IP 地址能同时承载多张证书、多个站点。在它之前算法很残酷：一张证书占一个地址，一个站点占一个地址，地址像水一样花出去。基于名字的虚拟主机对明文超文本管用，对加密流量却不行——服务器必须在加密请求暴露目标站点之前先选好证书。SNI 把悖论解开了：主机名提前一步，进握手本身，跑在加密前面。 现实成果就是今天的共享边缘：内容分发、平台路由、单机多租户，全靠它把几千张证书复用到几个地址上。但机制有三处利齿值得认识——隐私外泄、老客户端、缺省证书陷阱——每一处都在新租户上线或老客户端投诉时准时咬人。 名字最先报出 在交换密钥之前，客户端就在握手里发出想要的主机名，服务器据此选对虚拟主机和证书。因为名字先于加密到达，nginx 才能在一条连接里同时完成路由与选证书。扩展住在第一条握手报文里，不多花一次往返——选证书和本来就要做的握手在同一趟车里完成。 这个顺序也解释了它为什么不能只靠服务端单方面升级。客户端必须发这个扩展；没学过的客户端拿到缺省证书，拿它去校验自己想要的名字。老旧嵌入库、十年前的支付终端、工业控制器，真实机群里至今还有不带它的——认定全员支持之前，先看清自己的客户端构成。 用 server_name 匹配 主机名是路由元数据，而不是秘密：它以明文往返，负载均衡器或中间设备都能读到。nginx 拿它去和 server_name 匹配，决定走哪个 server 块、用哪张证书。每个站点块自带证书与私钥，共享一个监听套接字的各块按规则比对：精确名先行，再通配头尾，最后正则，和超文本主机头的匹配同一套路。 证书选对还不等于请求一定到对的应用。客户端会先验证证书的 SAN 是否覆盖它发送的名字，握手成功后才发送加密的 HTTP Host；反向代理若在第二层使用了另一套名字，证书看似正确，响应仍可能来自错误租户。把每个租户的 SNI 名、证书 SAN、server_name 和上游路由放在同一份清单里，新增或续期时逐项核对。SNI 解决的是证书选择，不是主机名保密，也不是应用授权。 传输层的站点表和应用层的主机预期必须一致，否则重定向和规范化会和证书打架。典型错配是证书对了、应用错了：握手命中甲块，主机头却进了乙块的逻辑，吐出签名正确、内容错误的响应。两边名字照镜子，两层都测，有分歧就当缺陷修，别当灵活用。 把缺省回退控制好 当虚拟主机一个都没命中时，nginx 会抛出第一个配置的证书作为缺省。因此 listen 443 ssl 块的顺序决定未知名字回退到哪个站点，别人直接敲 IP 也会命中这块。缺省块要招待三种客人：扫地址的扫描器、不带扩展的老客户端、域名过期或打错字误指过来的名字。每种都值得一个刻意的回答——中性落地页、直接断开、静默丢弃——而不是谁先配置谁待客。 ...

Redis 发布订阅与流解决的是不同的投递问题。发布订阅面向当前生效的订阅广播，不保留供以后回放的消息；流保存条目，读者可以在它们仍被保留时重新访问。选择哪种机制，首先要回答谁必须收到事件，以及消费者缺席期间应该发生什么。 先确定每个事件交给谁 对于后续状态可以替代的实时看板更新，只向在线用户广播也许已经足够。但在假设新听众已经到场之前，应等待订阅确认。重连恢复的是未来投递，不是错过的发布。PUBLISH 返回正数，表示按 Redis 命令语义统计到了接收者，不等于应用确认业务处理已经完成。 流有两种不同的消费方式。普通 XREAD 让独立读者分别指定自己的起始 ID，双方可以收到同一份保留历史。它既不自动分担工作，也不替每个连接保管检查点。同一个消费组中的 XREADGROUP 则在具名消费者之间分配新投递，并在未启用 NOACK 时记录待处理条目。 不同消费组允许账单、分析等独立工作流在同一条流上分别推进。组内增加成员是在分担工作，新建一组则是增加一套投递历史。消费者名字不同、工作进程变多，都不承诺负载均分或业务按序完成。应先确定需要的是广播、独立回放还是竞争处理，再选择对应的读取命令，不能把三种模式混为一谈。 保留窗口不是持久化设置 XADD 把数据保存在 Redis 里，并不自动保证每个已接受的写入都能熬过崩溃或故障切换。RDB/AOF 设置、复制行为、键淘汰及恢复操作共同决定持久性。发布订阅也不会因为启用了持久化，就突然拥有可回放的日志。因此，把两者概括成时效性与持久性的取舍，会掩盖各自的真实契约。 MAXLEN 删除的是最旧的条目，不是裁掉最新队尾、同时让早期历史一直保留。近似裁剪可能留下额外记录，精确裁剪则遵循指定数量；两者都不提供无限回放。默认裁剪还可能删除待处理引用对应的载荷，因此应围绕允许的最长停机时间与恢复后的追赶过程设计保留策略和容量。 保留积压也有运行成本。需要控制增长，分别观察未读滞后和待处理任务，并定义无法正常处理的消息如何处置。发布订阅虽然不保存历史，却仍使用连接输出缓冲；慢听众触达相应限制后可能被断开。两种机制都不能让内存规划消失，只是占用与丢失发生的位置不同。 坏掉的样子 用发布订阅派发必须执行的任务，订阅者缺席时就会失去投递机会。能够重新加载权威状态的看板可能接受这点，必须执行的财务操作通常不能接受。合适的替代品可以是保留消息的流，也可以是其他持久队列，但恢复语义必须围绕业务操作设计，不能从产品名字直接推导出来。 流若没有恢复循环，会出现另一种失败：已经投递但未确认的条目停留在待处理列表，普通 > 读取却继续处理新消息。处理前确认可能丢工作，处理后确认则允许重试时重复副作用。如果重复执行不可接受，稳定的事件标识和幂等处理仍是必需的，不能仅靠建组和追加消息解决。 把同一事件分别 PUBLISH 和 XADD，也不是原子双写协议。执行若在两次操作之间中断，可能只有一边成功。下面的实验在隔离进程中有意比较两种机制，不是在推荐用这一串命令构成生产送达保证。比较实验里的执行顺序，不应被直接提升为跨系统一致性方案。 快速验证 原有实验记录使用 macOS、Python 3.14.4、Redis 8.10.1 和 redis-py 8.1.0；本轮审阅没有重新执行服务实验，下面的结果说明保留原有观察范围。准备 POSIX 环境、C 编译器、make、curl、tar 与 Python 3.10 或更新版本。安装步骤仅用 libc 构建 Redis 核心，并把客户端装入临时虚拟环境。 ...

Redis Streams 消费组把新条目分配给具名消费者，并记录尚未确认的投递。它不保证业务副作用恰好发生一次，不会阻止保留策略删除数据，也不会自行恢复被遗弃的任务。将其用作工作队列前，应区分组的读取位置、待处理条目与流里实际保留的数据。 读取位置与待处理任务不同 XGROUP CREATE jobs workers 0-0 从现有历史之前起步；使用 $ 则从当前末端之后开始。同组成员分担新投递，不同消费组拥有各自独立的投递状态。并发工作进程应使用不同的消费者名字。最后投递位置属于整个组，并不是每个消费者分别提交一个偏移。 未使用 CLAIM 或 NOACK 的普通 XREADGROUP 以 > 请求新条目，投递后将它们记入待处理列表 PEL。组的位置在新条目投递时就推进，发生在 XACK 之前。XPENDING 统计的是已经投递但尚未确认的条目，不是从来没有投递过的积压。因此，待处理计数为零时，组里仍可能有大量未读工作。 XACK 把指定 ID 从该组 PEL 移除，不删除流里的记录，也不推进最后投递位置。确认可以乱序完成，其他组依然可以读取保留下来的条目。XREADGROUP 使用 0-0 时读取的是这个具名消费者自己的待处理历史，不是在请求新工作，也不会把另一位消费者名下的待处理消息交给它。 恢复需要显式决策 反复执行普通 > 读取，不会重试被遗弃的 PEL 条目。XAUTOCLAIM 能把满足条件的待处理条目转给请求方，参数必须包含流、组、消费者、最小空闲毫秒数和起始 ID。之后应使用返回游标继续扫描，直到返回 0-0。某一批认领结果为空，并不代表扫描已经完成；过一段时间再次扫描，原来尚未达到空闲阈值的条目也可能变得可认领。 ...

繁忙表持续产生旧行版本，维护速度需要与这种产生速度匹配。降低自动回收门槛，可以让表更早具备被处理的资格，但“符合条件”并不等于“已经完成”。工作者仍需轮到这张表、获得所需锁，并在积压继续增长之前完成足够的有效清理。调优应观察这个完整循环，不能把一个参数值当成后台吞吐的保证。 坏掉的样子 普通更新和删除的触发条件，由固定门槛加上表行数估计乘比例因子构成；PostgreSQL 18 在启用上限时，还会应用最大触发门槛。插入触发清理、由事务年龄驱动的冻结，又有各自的运行原因。因此，只看一个死元组比例，会漏掉其他维护需求；每看见一次清理就断言更新删除门槛被触发，也可能误判真正原因。 把门槛调低，不能释放仍被旧快照需要的版本，也不能创造额外的磁盘吞吐。增加工作者或降低成本延迟，还可能加剧与前台查询的资源竞争。让死元组估计在每个瞬间都接近零，既不是通用的现实目标，也不能充分说明业务性能良好。真正需要维持的是可持续的清理能力、可接受的文件增长、请求延迟和维护成本。 快速验证 本轮没有重跑原样保留的后台工作者集成。先前的自动清理观察属于历史记录，手动或单用户清理不能代替它。 使用 PostgreSQL 18 可丢弃实例，确认自动回收与统计收集已启用、有可用工作者，并使用正常的一分钟数据库检查间隔。通过一个全新的 psql -X -v ON_ERROR_STOP=1 连接执行下面的脚本。它最多等待一百三十秒，核对真实自动执行；如果超时，应把这次观察记为失败，不能手动清理一次就冒充自动任务已经运行。 CREATE SCHEMA churn_demo; CREATE TABLE churn_demo.jobs (id integer PRIMARY KEY,n integer) WITH (autovacuum_enabled=false, autovacuum_vacuum_threshold=50, autovacuum_vacuum_scale_factor=0.2); INSERT INTO churn_demo.jobs SELECT g,0 FROM generate_series(1,10000) AS g; SELECT pg_stat_force_next_flush(); VACUUM (ANALYZE) churn_demo.jobs; UPDATE churn_demo.jobs SET n=1 WHERE id<=1000; SELECT pg_stat_force_next_flush(); SELECT n_live_tup,n_dead_tup,vacuum_count,autovacuum_count FROM pg_stat_user_tables WHERE relid='churn_demo.jobs'::regclass; SELECT 50+0.2*reltuples AS old_threshold,50+0.01*reltuples AS new_threshold FROM pg_class WHERE oid='churn_demo.jobs'::regclass; ALTER TABLE churn_demo.jobs SET (autovacuum_enabled=true,autovacuum_vacuum_scale_factor=0.01); DO $$ DECLARE deadline timestamptz := clock_timestamp()+interval '130 seconds'; BEGIN LOOP PERFORM pg_stat_clear_snapshot(); EXIT WHEN (SELECT autovacuum_count>0 FROM pg_stat_user_tables WHERE relid='churn_demo.jobs'::regclass); IF clock_timestamp()>deadline THEN RAISE EXCEPTION 'no automatic vacuum observed within the experiment budget'; END IF; PERFORM pg_sleep(0.25); END LOOP; END $$; SELECT pg_stat_clear_snapshot(); SELECT n_dead_tup,last_autovacuum IS NOT NULL AS ran,autovacuum_count>0 AS counted FROM pg_stat_user_tables WHERE relid='churn_demo.jobs'::regclass; SELECT count(*),count(*) FILTER (WHERE n=1) FROM churn_demo.jobs; DO $$ BEGIN IF (SELECT count(*) FROM churn_demo.jobs)<>10000 OR (SELECT count(*) FROM churn_demo.jobs WHERE n=1)<>1000 THEN RAISE EXCEPTION 'maintenance changed application data'; END IF; END $$; DROP SCHEMA churn_demo CASCADE; 测试表最初只关闭自己的常规自动回收，让初始化与受控更新先完成。手动清理并分析建立统计，同时清掉初始化插入积压，然后再更新一千行。显式统计刷新调用用于同步这个短实验，避免待发布的写入增量落在手动维护更新估计值之后；它不是建议在线业务频繁调用的调优开关。 ...

Cordon 改变调度资格，drain 协调驱逐并等待 Pod 终止。两条命令都不保证维护期间工作一定保留；应用关闭逻辑、替代容量、存储和中断预算共同决定结果。应把排空视为需要观察的状态，并记录明确例外，而不是从命令名称推导节点已经可以安全关机。 Cordon 改变未来放置 Cordon 设置节点的不可调度字段，已有 Pod 继续运行，普通的新调度会避开它。Drain 自己也会执行 cordon，因此单独先做一次可以留下观察窗口，但不是必需步骤。Uncordon 重新允许调度，不保证立即出现新副本，也不会修好不健康的 kubelet；恢复前仍应核对节点状态与应用准备情况。 这项调度限制存在例外。DaemonSet Pod 容忍不可调度条件，直接填写 nodeName 的 Pod 则绕过普通调度选择。具有相应容忍度的其他 Pod 也可能符合放置条件。因此，需要检查真实剩余负载，不能把 cordon 说成阻止所有 Pod 到来的防火墙，更不能只凭不可调度字段就判断节点已经清空。 Drain 具有过滤检查和独立操作 Kubectl 先列出 Pod 并检查删除条件。独立 Pod 或管理控制器已经不存在的 Pod 可能需要 force；emptyDir 需要确认丢弃内容；DaemonSet 需要 ignore 选项。镜像 Pod 会被跳过，因为删除 API 表示不能停止 kubelet 根据静态清单管理的底层工作负载，静态程序需要单独规划维护。 ...