文章

nginx 跳转与内部重写改变请求流程的不同部分。跳转返回状态和 Location，由客户端决定是否发起新请求；内部重写则在处理现有请求时改变 nginx 当前 URI。两者的选择决定客户端是否看到新地址、location 是否重新搜索，以及最终处理器收到怎样的路径和查询。不能因为都能让某个 URL 得到内容，就把它们当成同一种操作。 坏掉的样子 本来需要内部映射，却改成跳转，会增加客户端往返并暴露新 URL；本来需要公开永久迁移，却只做内部重写，客户端仍会继续使用旧地址。return 和 rewrite 也不能被当成总是默认相同跳转行为的通用缩写。明确状态码与重写标志，才能让预期转换可审阅，避免一行看似简单的配置隐藏行为差异。 状态选择影响方法语义和缓存。307、308 在自动跳转时保留请求方法，301、302 则允许历史上的 POST 改为 GET。永久不意味着每个客户端立刻更新所有已保存链接，临时也不意味着响应绝对不能缓存。缓存指令、请求上下文和客户端行为仍然重要，不能用状态名称替代明确的复用策略。 内部重写还可能选择错误处理器，或反复匹配自己。last 会为改变后的 URI 开始新 location 搜索；break 结束当前重写序列后，继续在现有 location 处理。查询参数可以按替换语法追加或丢弃。把这些区别视为可以互换，可能导致读取错误文件、重复参数，或进入返回 HTTP 500 的循环。 客户端新请求，或内部转换。 依据原文与明确限制静态绘制；未为本图重跑原文夹具。 快速验证 下文集成实验的结果保留自历史运行记录；本次修订没有重新执行该实验，不能将这些记录当成本次环境的新实测。 ...

流水线减少的是发送 Redis 命令之间的等待，实际收益必须放到具体负载里测量。远程同步循环可能主要等待网络延迟，本地循环也可能主要消耗在客户端处理、进程调度和套接字读写。两种情形都不能直接推出“任何环境都会快几倍”的结论，更不能用一次本机数字替线上系统承诺容量。 比较等价的工作 对于 N 条命令、每批 B 条，简单同步模型把约 N 次请求响应等待减少为向上取整的 N/B 次批次等待。但命令执行、响应字节、编码和解析并没有消失；一批数据仍可能跨越多次套接字写入和多个网络包。因此模型中的等待次数，不是抓包数量，也不是对真实链路 RTT 的测量。 改变 B 时，要固定命令、键分布、负载大小、连接数、客户端版本和持久化设置。否则看起来更快，可能只是做了更少工作、关掉了持久性，或者增加了并发客户端。若要测普通流水线，应显式使用 transaction=False，因为 redis-py 默认流水线还会加入 MULTI/EXEC。 下面批量一使用普通同步客户端循环，不是每次只装一条命令的流水线包装器。这样比较回答的是“应用当前请求响应循环能否从批处理受益”，而不是测出 Redis 的最大可持续吞吐，更不是剥离客户端后得到服务器的固有命令成本。 计入应用实际支付的成本 计时应覆盖命令准备，直到最后一个结果收齐。忽略构建请求或解析响应，会低估大批次给应用带来的成本。示例把缓冲、执行和结果收集都放进计时区间，而把重置数据与正确性断言放在外面；两种路径遵守相同的计时边界，才方便比较。 每个配置先预热，再变换测试顺序并重复测量，同时报告波动。这里的三次正式运行只是一个容易复现的小型比较，不是严谨的容量研究。笔记本上的调度和其它工作仍会影响结果，单次中位数不能直接升级成服务等级目标。 吞吐量也不是单条请求延迟。总耗时除以命令数，得到的是平均完成成本，不是百分之九十五或九十九请求的延迟分布。等待凑满一批，可能让最早到达的请求在执行前就排队；本例立即构造批次，没有测量真实到达节奏带来的积攒延迟。 坏掉的样子 巨型批次可能提高每秒命令数，却同时带来难以接受的停顿和内存增长。应限制条数、请求与响应字节，以及等待成批的时间；这些上限应来自代表性负载，而不是不分命令类型就照搬几百或几千条。 如果继续增大批量已经没收益，要检查客户端 CPU、响应解码、服务端命令成本、带宽和竞争负载。流水线能够通过分摊读写开销提高实际服务吞吐，但并不消除所有瓶颈。分片是可能的架构选择之一，不是曲线变平之后唯一合理的答案。 计速度也必须检查失败。丢掉回复或把错误当成功，可以轻易制造漂亮但无意义的速率。下方关闭网络自动重试，并核对每一个递增结果的完整序列。真实断连可能留下不确定的执行范围；从最后一条已知回应之后重发，对递增也不是天然安全的恢复方式。 测试负载只应留在它自己的实例中。代码会反复重置并递增一个计数器，若把目标改成共享生产库，操作风险就发生了变化。这里使用本地 Unix 套接字，也有意排除了 TCP、TLS 和远程网络路径，所以读数不能冒充跨机房链路测量。 假想梯形图解释逻辑等待。夹具批次计数是算术，不是实测 RTT、延迟或容量；历史速度测量仍未核实。 快速验证 原文报告的环境是 macOS、Python 3.14.4、Redis 8.10.1 和 redis-py 8.1.0；本轮查阅的证据中未找到匹配的执行日志，也没有重新运行。需要 POSIX、C 编译器、make、curl、tar 和 Python 3.10 或更新版本。必须启用断言，不能使用 -O 或 PYTHONOPTIMIZE，否则检查及其中必需的调用都会被跳过。 ...

LATERAL 允许 FROM 中的一个项目引用它前面项目提供的列。每个父记录需要一个带自身参数的小结果集时，它很实用，例如每位客户最近的两笔订单。整个查询仍是一条 SQL、一次数据库往返，横向子查询明确表达哪些外层值决定当前结果。但这种逻辑关系不承诺唯一的物理执行策略，规划器仍可进行保持语义的优化。 把关联条件写清楚 普通 FROM 子查询不能随意引用旁边表的列，LATERAL 允许在合适的连接位置使用这些引用。o.customer_id = c.id 才是当前客户与订单之间的关联；只写关键词不会自动产生这个条件。如果删除关联，每位客户可能都拿到同一份全局结果。语法通过只能证明语句合法，不能证明取到的是这个客户自己的订单。 实现每组前几名时，把父记录过滤条件、ORDER BY 和 LIMIT 都放进横向子查询。放在整个连接外面的 LIMIT 限制的是最终组合结果，不是每位客户最多几笔订单。排序还需要唯一的决胜字段：两笔订单完全可能具有相同时间戳，只按时间排序时，边界位置选择哪一行没有保证，换一个计划就可能换一个答案。 子查询里的 ORDER BY 决定入选哪些行，并不保证最终结果的展示顺序。客户端要求稳定的客户与订单顺序时，还需要外层 ORDER BY。导出报表和自动化检查尤其依赖这一点；不能因为当前执行计划碰巧按某个顺序返回，就把这种偶然表现当成接口契约，否则升级或统计信息刷新后会出现难以解释的行顺序变化。 决定没有匹配时保留什么 CROSS JOIN LATERAL 在子查询没有返回行时会丢掉对应父记录。LEFT JOIN LATERAL 配合 ON true 则保留父记录，并把右侧列补成 null。对尚未下单的客户，后者往往才符合页面或报表需求。如果把右侧条件移到外层 WHERE，补出来的 null 行可能被过滤掉，原本想保留空客户的行为就被破坏了。 聚合还有一层区别。COUNT(r.id) 只统计非空订单标识，COUNT(*) 连左连接补出的那一行也会计算。没有 GROUP BY 的相关聚合，即使输入为空也可能返回一行，COUNT 是零，SUM 则是 null。因此不能把所有 LATERAL 表达式都理解成同一种列表查询，必须看它实际返回零行、一行还是多行，以及每一列的空值含义。 ...

merge 与 rebase 都能整合工作，却对提交身份和祖先关系产生不同影响。合并通常保留既有提交并连接历史，变基则把选定变化移到另一基线。选择不只是图形看起来是否整齐，还影响评审引用、冲突处理、签名，以及已经依赖旧提交的协作者。应依据仓库流程与真实分支关系决定，而不是把“线性一定更好”或“有合并提交就一定安全”当成通用判断。 图示已分叉历史上的普通变基；快进与保留合并结构的变基有所不同。箭头表达父级关系，不代表墙上时钟顺序。 合并记录什么 两个末端已经分叉时，普通双分支合并创建以这两个末端为父级的新提交，并记录结果目录树；既有提交保持原身份。图保留的是祖先关系，不是所有活动的完整时间排序。提交日期与界面展示顺序也不能替代父级关系，否则可能把并行工作误读成严格前后发生的一串事件，进而错误判断某项修改究竟基于什么版本。 如果当前末端是传入末端的祖先，合并可以直接快进分支，不创建额外合并提交。要求始终创建合并提交，是通过相应选项表达的另一项流程规则。反过来，即便结果保留两个父级，也不能证明双方预期行为都正确保留。仍需审阅内容并运行集成测试，不能用提交拓扑替应用接口、数据规则或发布依赖完成验收。 变基改变什么 普通变基识别选定提交，再把它们的变化重新应用到新基线。重新创建的提交只要父级不同，对象标识就不同，即便补丁看起来相同。原作者信息通常保留，但新对象仍需自己的验证，以及流程要求的签名。指向旧对象的评审链接，也不会自动变成指向新对象的链接；后续说明需要让读者能够找到实际接受审阅的结果。 并不是每次变基都会重写所有提交：分支已经更新时可能无需重放；上游等价变化或应用后的空结果，也会影响哪些提交留下。普通变基从重放序列中省略合并提交，让选定工作趋于线性；明确启用重建合并的模式，则会尝试恢复分支结构。因此，“变基永远得到直线”同样过度概括，具体结果取决于参数和输入历史。 合并协调的是分支末端，变基通常逐个处理提交，所以冲突出现的位置与次数可能不同，同一种取舍还可能需要多次执行。完成后应比较最终目录树及重放变化，并重新运行相关测试。补丁相似，不证明新基线上行为完全相同；依赖、接口和上下文已经改变时，文本能够落地只是审查的开始。 坏掉的样子 重写其他工作已经依赖的提交，会产生协调成本。私人且未发布的分支，通常比共享集成分支更适合变基。明确协商过的共享历史重写并非不可能，但必须识别受影响引用及消费者。偏好线性历史，不等于获得替换别人已发布工作的权限；是否应该执行，需要独立于工具是否支持来判断。 变基本身并不必然要求强制推送。新的远端分支可以普通创建；远端末端仍是本地结果祖先时，也可以正常快进。需要替换已被重写的远端提交，才属于非快进情况。即便使用租约，它也只是根据预期远端值作并发检查，不代表已经批准替换，也不能证明所有协作者都已被考虑。发布前应先确定真实引用关系，而不是机械套用强推命令。 变基冲突中，合并后端所称的本方，是目前已构建的变基历史，包含上游基线；对方则是正在重放的提交。这可能与开发者按原功能分支理解的“我的版本”相反。应检查实际文件版本和目标契约，再决定如何解决；暂存具体文件后继续。跳过会丢弃当前补丁，并不是自动修好这次冲突，不能为了让过程继续就忽略它的业务含义。 决定放弃操作时，中止变基会恢复起初的分支状态。--quit 则只停止管理变基，保留当前 HEAD、索引与工作文件，并不是等价的撤销命令。需要恢复起点时，不能因为两者都会结束流程就随意替换。从干净工作区开始，有助于明确恢复结果。不要把中止当成在过程中保存任意无关编辑的通用备份，也不要用强制清理作为常规冲突处理方式。应先理解当前序列、索引与文件中有哪些有效成果，再选择与操作意图匹配的恢复路径。 快速验证 在 POSIX 系统上使用 Python 3 与 Git 2.28 或更新版本运行下面实验。它在临时仓库中使用示例身份，关闭钩子与签名，没有远端，并排除继承的 Git 路由及个人配置。两个分支从同一个主题提交起步，以不同方式整合一项独立上游变化；第三个分支有意制造新增同名文件的冲突，检查中止恢复，而不碰当前项目的实际历史。 ...

nginx location 在已选中的 server 内为请求选择配置。对于这里验证的平面前缀与正则结构，精确匹配会结束搜索；否则 nginx 先记住最长匹配前缀，再可能选择第一个匹配的正则。如果没有适用正则胜出，就使用先前记住的前缀。这是一个完整选择过程，不是简单执行配置文件里最先遇到的块，也不是只比较路径看起来有多具体。 坏掉的样子 前缀是字符串前缀，不会自动要求完整路径段。location /api 也能匹配 /apix。如果真正需要的是端点 /api 和 /api/ 下的后代，应明确表达这两个边界。依赖未声明的路径段边界，可能让只是共享开头字母的路径，进入错误处理器、缓存策略或访问规则。配置应反映真实 URL 集合，而不是依靠读者自行补充含义。 最长普通前缀不一定是最终选择。匹配 .php 的正则，可以接管一个也匹配了更详细 API 前缀的请求。把前缀移到正则之前，不会改变基本优先规则。竞争正则之间的声明顺序有意义，普通前缀则主要比较匹配长度，而不是出现位置。因此，单纯整理文本顺序不一定修复实际路由问题。 ^~ 在该前缀成为相关层级的最长匹配前缀时，抑制正则搜索。它不是正则运算符，也不是对所有以某个较短标记前缀开头的路径提供无条件保护。嵌套 location 和内部跳转需要额外推理；下面故意使用平面 server 结构，让每次选择都能明确对应一个规则，不把复杂嵌套情况隐藏在简化结论里。 前缀仍可能被正则接管。 依据原文与明确限制静态绘制；未为本图重跑原文夹具。 快速验证 下文集成实验的结果保留自历史运行记录；本次修订没有重新执行该实验，不能将这些记录当成本次环境的新实测。 ...

pg_dump 使用事务数据的一致视图导出一个 PostgreSQL 数据库，同时允许其他会话继续提交变化。它避免了普通逐表复制的问题：前一张表和后一张表不会因为读取时间不同，就混入彼此不一致的已提交状态。但快照只是备份契约的一部分；归档还必须覆盖需要的数据范围，能被兼容工具读取，并且实际恢复成可使用的数据库。 理解快照覆盖什么 导出期间，快照可见的行构成稳定视图。后续提交不会因为某张表读得晚，就逐渐混进同一次导出。并行导出让各 worker 使用同步快照，而不是各自随时读取。并行 dump 要求 directory 格式；custom 格式支持并行恢复，但不支持并行导出。格式选择应根据导出与恢复两边的需求分别判断，不能把两个方向混为一谈。 数据库快照不会自动让整个业务流程原子化。如果应用分两个事务提交批次头和明细，一致快照完全可能合法地落在这两次提交之间。序列状态也不是普通的 MVCC 行数据，外部文件和其他服务更不在数据库快照范围内。恢复需要满足什么业务不变量，必须结合真实事务边界和所需数据源定义，不能只凭“同一快照”推断所有业务状态都完整。 计算负载和依赖 普通读取和写入通常可以在导出期间继续，但 pg_dump 仍获取 ACCESS SHARE 锁，也消耗 CPU、I/O、连接和快照存活时间。冲突的 DDL 可能等待，也可能使导出失败；长快照会阻止某些旧行版本被清理。增加并行 worker 只是用更多并发资源换时间，不会让备份开销消失。应记录事务年龄和线上负载，避免把备份的影响误认为无关故障。 使用备库可以分担读取，但要考虑恢复冲突与复制延迟，而且从备库导出会排除非日志表内容。一次 pg_dump 也不包含集群级角色和表空间。扩展、所有者、权限、排序规则行为及目标配置，都需要通过合适机制纳入恢复计划。把整个库拆成互不协调的单表 dump，可能丢失共同快照，也可能遗漏这些表依赖的对象，不能当成免费的优化。 坏掉的样子 归档目录能够列出，不代表恢复一定成功。目标缺少角色或扩展时，表数据可能只恢复了一部分。应把归档加载到隔离空库，明确处理错误，再验证业务不变量和代表性查询。pg_restore 默认遇到 SQL 错误仍会继续，最后汇总错误数量；只看到最后一条查询有输出是不够的。小型演练可使用单事务恢复获得原子性，但这个模式不能与并行 job 同用。 工具版本是另一条边界。pg_dump 客户端会拒绝比自身主版本更新的服务器，输出主要面向相同或更新的目标版本，不能保证可以加载到更旧的主版本。应核对客户端、源库、目标库、扩展和恢复选项的实际组合，而不是只说“都是 PostgreSQL 所以可以恢复”。即使语法兼容，排序规则或权限差异也可能改变应用行为。 ...

PostgreSQL 提供多种“当前时间”。事务时间标记事务开始，语句时间标记客户端命令到达，墙钟读数则在表达式求值时读取当前时钟。选择不同函数，会改变审计字段、过期检查和长任务中间观测的含义。应先明确要记录哪个事件，再决定函数，不能因为名称都有时间含义就随意互换。 一个事务只有一个开始时刻 now()、transaction_timestamp() 与不带精度参数的 CURRENT_TIMESTAMP，返回同一个事务开始瞬间。在显式事务里，它们始终固定，即使后续语句已经晚了几秒或几分钟。CURRENT_TIMESTAMP 可以指定精度来舍入结果；小数位数的处理与采样时刻是两回事，不能因为显示精度不同就推断时钟来源改变。 这种稳定性适合让相关行共享同一个逻辑事务时间。它不记录每行真正插入的时刻，也不是最终提交时间。事务可能先等待锁或执行大量计算，随后才插入数据，最后还有可能回滚。把列命名为 created_at，并不能自动说明默认值到底代表哪个事件，需要在数据契约里写清楚。 普通自动提交模式下，连续语句通常各自处于不同事务，因此 now 看起来会随每条语句前进。但这种观察没有改变函数契约。后来为了原子性加上显式事务时，原本被误认为实时变化的时间，就可能暴露出早已固定的问题；验证时应覆盖真实事务边界，而不只在交互终端连续敲两条查询。 语句标记与实时读数 statement_timestamp() 返回服务器收到最近一条客户端命令消息的时间，在该命令执行期间保持稳定。事务中后续命令的语句时间可能与事务时间不同。同一协议消息里发送的多条 SQL 命令，也可能共享这个标记，所以它不一定代表等待结束后，每个内部操作真正开始的那一刻。 clock_timestamp() 在求值时读取当前墙钟，即使同一条语句内部也可能变化。由于时钟精度有限，两次调用并不保证得到不同值。它也不是单调计时器，时钟校正可能影响前后读数的差值。需要保证耗时测量不受墙钟调整影响时，应使用合适的单调时钟，而不是把数据库墙钟当成无条件递增的计数器。 这些值单独使用，都不能证明并发事务的提交顺序，也不能提供唯一事件身份。相关字段需要一致逻辑时间时选事务标记，观测命令到达时选语句标记，需要读取当前墙钟时才选实时观测。身份与顺序要求应另外明确，不能让时间戳自动承担它未承诺的语义。 坏掉的样子 长事务中的过期检查如果使用 now，就会持续与事务开始时刻比较。一个在事务开始时成立的条件，即使真实墙钟已经越过截止时间，也可能继续成立。即便使用 clock_timestamp，也只检查求值瞬间，不能保证稍后的提交仍在截止时间之前。要求提交时有效的业务规则，需要另外设计并发与时间边界。反过来，把全部默认值换成 clock_timestamp，又可能让本该共享逻辑创建时间的相关行各不相同。修改函数前，应先确定列代表的是业务批次、命令到达还是实际观测。 列默认值中的特殊字面量 TIMESTAMPTZ 'now' 也是一个陷阱。PostgreSQL 在解析常量时就把它转换成时间，所以后续插入可能一直拿到建表时刻。DEFAULT now() 是函数调用，会在真正使用默认值时求值。两种写法看起来相似，并不代表求值生命周期相同；只检查默认表达式包含 now 这个词，会漏掉这个差别。 这些函数返回 timestamptz。切换会话时区会改变瞬间的显示形式，而不是改变已存储的瞬间本身。timestamptz 不保留最初传入的时区名称；应用需要记住原始时区时，应单独建模，不能从后来显示的偏移量反推原始地区。相同偏移量也不足以唯一确定某个时区名称。 三类时间，三个取样时点。 依据文章示例与明确限制静态绘制；未为本图执行 SQL。 快速验证 把下面内容保存为 timestamps.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f timestamps.sql。显式事务之外，应保持 psql 默认的自动提交行为；第二段需要让两次插入分别处在不同事务里。所有表都是临时表。 ...

Cron 可以从不止一种任务表读取计划。用户任务表属于某个账号，而系统任务表能够为每一条记录指定运行账号。把一行原样复制到另一种表中，如果没有调整字段，cron 对命令起点的理解就会变化。排查看似正确的五字段日历表达式之前，应先确认正在编辑的到底是哪种任务表，而不是只检查分钟和小时。 Debian 用户表在五个字段后开始命令，系统表则先增加用户名。未转义百分号先于 shell 引号处理，并分离标准输入。本图为示意图；没有执行需要特权的示例。 账号列改变了解析边界 传统用户记录依次填写分钟、小时、月内日期、月份、星期，再接命令正文，由 crontab 命令安装给选定用户。Debian 的 /etc/crontab 和 /etc/cron.d 下文件，则在五个日历字段之后额外增加用户名。这个用户名属于系统表格式，并不是可以随意放进用户任务表的说明性字段；多写或少写都会改变后续解释。 月份限制仍然必须满足。当月内日期与星期都受到限制时，Debian/Vixie 的日期规则允许满足其中之一，但月份与星期并不是二选一。把表达式迁移到带秒字段或采用其他日期组合方式的调度产品前，应核对具体方言。表面上相似的空格布局，不能证明两个调度器提供相同语义。 系统任务文件还受所有权、权限、名称及末尾换行要求约束。Debian 中应采用 root 所有、组和其他用户不可写且名称被接受的文件，不要把任意备份后缀当成有效任务名。/etc/cron.daily 等周期目录通常通过发行版安排和 run-parts 被调用，不是每份脚本都独立当作 crontab 解析。实际运行时间需要查看本机已安装的调度安排。 坏掉的样子 在 root 用户自己的任务表中，五字段后再写 root，意味着让 shell 执行一个名为 root 的命令。任务表安装成功，不证明这个命令存在。反过来，系统表漏掉账号列，就会把命令文字当成用户名。审阅时需要同时检查解析边界与最终身份，尤其是任务会写文件或读取受保护数据时，不能仅凭“都是 root 配置的”推断执行账号。 任务环境同样是一份契约。不要默认交互别名、shell 启动文件或启动 cron 的父进程环境都会传给任务。需要的值应明确配置，同时选择合适的 PATH 和解释器。cron.d 文件中的环境也不应被认为自动继承 /etc/crontab 中的设置。验证时要采用真正的运行账号检查权限与输出，避免管理员手工执行成功掩盖低权限任务失败。 ...