DynamoDB 的云原生之路 —— 流控策略的演进

概述：流控为啥重要

上云的好处在于池化资源，让多租户共享，然后按需分配，从而降低成本。但进行：

1. 多租户隔离：用户要求可以使用其买到的流量，并且不会被其他租户影响。

2. 资源共享：资源只能逻辑隔开，不能物理隔开，否则无法充分动态分配（超发）。

是一对相对矛盾的事情，我认为，也是云原生数据库最要解决的问题。不把这个问题解决好，则数据库：

1. 要么平台不赚钱：比如资源静态预留，虽然可以让用户满意，总能随时用到卖给他的资源配额，但会存在巨大资源浪费，要么价格贵，要么用户不买单。

2. 要么用户不满意：多用户共享物理资源，但非常容易进行互相影响，造成用户不能用到平台声称的配额。

DynamoDB 从静态分配开始，逐步演化出一套全局和局部组合的准入控制机制，从而实现了物理上资源共享，但又在逻辑上给用户以配额隔离，从而实现了数据库真正的云原生。下面，我依据 Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service[1] 这篇论文披露的细节，对其流控机制的演进过程做一个梳理，以飨诸君。

水平所限，谬误之处，欢迎在评论区指出。

开始：静态预留

这里面对的其实是一个常见的调度问题，如何将表的分片副本（table-partition-replication）调度到集群（一组物理机）上，并兼顾以下特性：

1. 可用性：将物理机划分 AZ（Availability Zones，可用域），将不同副本调度到不同 AZ。

2. 数据容量：其实是针对存储资源，每个物理机有容量总额，每个副本也有容量预期（能随着容量自动分裂，所以刚开始可能都比较小），表的分区副本创建时，需要为其寻找物理机资源余量大于其需求量的目标机器。比如，一个很简单的撮合策略是每次找集群中最空闲的那个机器。

3. 流量：文中称 performance，其实包括计算资源和网络带宽。分配方式和 2 类似。

本文关注重点主要在 3 上，并且引入了流量单位：读容量单位