当今软件受惠于青铜时代的水钟
内容提要
文章介绍漏桶机制的历史与软件应用：从古代水钟到网络限流，漏桶通过容量和排水速率控制任务准入。Shopify等用它做API限流。开源数据库Postgres缺乏此功能，PlanetScale推出Database Traffic Control，在查询执行前按资源预算准入或拦截，保护数据库。
延伸解读
漏桶机制：从古代计时到现代限流
漏桶机制的核心在于通过容量和排水速率控制任务准入，这一思想可追溯至古代水钟。文章指出，巴比伦、埃及和波斯人利用漏水容器计时，希腊人则将其发展为精确时钟，并用于雅典法庭限制发言时间。在软件领域，漏桶被用于网络限流和API速率控制，如Shopify的GraphQL Admin API。这种历史延续性表明，简单的资源管理模型具有持久的价值。
数据库准入控制的缺失与补位
开源数据库如Postgres和MySQL缺乏内置的准入控制功能，导致生产环境中常见故障模式：数据库无法主动拒绝超出其处理能力的查询，只能被动尝试执行，最终因硬件或连接限制而失败。相比之下，Oracle和SQL Server等 proprietary 数据库提供了资源管理功能，但主要侧重于节流而非拒绝。PlanetScale的Database Traffic Control填补了这一空白，在查询执行前根据资源预算进行准入或拦截，从而保护数据库。
资源预算的配置与预期失败状态
Database Traffic Control通过资源预算管理查询，配置包括服务器份额、突发限制、每查询限制和最大并发工作线程。服务器份额决定令牌补充速率，突发限制设定桶的最大容量。由于数据库无法预知查询成本，系统基于查询计划和历史行为进行估算，执行后调整差异。文章建议先以警告模式创建预算，监控影响并准备应用处理被阻止的查询，再切换模式。这强调了准入控制需要预先定义失败状态。
Q&A
漏桶机制在软件中是如何工作的？
在软件中，漏桶有两种实现：作为计量器或队列。每个工作单元被赋予一个值，与桶的当前容量比较。如果桶容量不足，工作被拒绝；否则允许，其值加入桶的当前容量。桶以基于时间的速率排水，因此新工作不能比排水速率更快地被允许。排水速率基于经过的时间，而不是工作的完成。
Shopify的GraphQL Admin API如何利用漏桶进行限流？
Shopify的GraphQL Admin API使用文档化的漏桶进行限流。每个商店的每个应用获得一个固定大小和恢复速率的桶。每个请求根据查询内容消耗不同成本，而不是请求数量。查询运行前，桶必须有足够空间容纳预估成本。完成后，桶根据预估和实际成本的差异退款或扣费。应用可以突发请求直到桶满，然后被限流。响应包含桶的当前状态，以便应用提前减速。
为什么开源数据库如Postgres缺乏内置的准入控制？
开源数据库如Postgres和MySQL没有内置的准入控制功能。生产环境中数据库最常见的故障模式之一是无法故意拒绝无法完成的工作。向典型的关系数据库发送大量查询，它会尽力执行，但可能因硬件、配置或连接限制而意外阻塞工作，导致不希望的后果。Postgres有一些配置选项如statement_timeout来控制已消耗资源的昂贵查询，但无法在昂贵工作发生前阻止它。
PlanetScale的Database Traffic Control是什么？它如何保护Postgres数据库？
Database Traffic Control是PlanetScale为Postgres提供的准入控制功能。它通过资源预算决定一个或多个查询可以消耗多少资源或并发。每个预算允许或阻止匹配特定标签的查询，标签可以是查询中的注释或指发送查询的用户或应用。如果资源预算确定查询不应继续，会根据配置记录警告或阻止查询。这保护Postgres数据库免受应用（有时是自身）的过度请求。
在Database Traffic Control中，资源预算的三个主要设置是什么？
资源预算的三个主要设置是：1. 服务器份额和突发限制（令牌桶）：服务器份额决定桶补充令牌的速度，以服务器资源的百分比表示；突发限制设置桶的最大容量，以整服务器秒为单位。2. 每查询限制：设置单个查询可消耗的最大容量上限，直接对单个查询做出准入控制决策。3. 最大并发工作线程：通过可用工作线程而不是执行时间来控制单个查询可消耗的资源。
为什么Database Traffic Control的补充速率以服务器容量而不是秒来衡量？
因为并非所有执行查询的时间都是相等的。一个查询使用8个核心1秒与使用1个核心1秒是不同的。同时考虑不同的服务器大小：25%的服务器份额意味着无论服务器有2核还是64核，每秒都有四分之一的服务器容量被补充回来。以服务器容量衡量可以更准确地反映资源消耗。
