亚马逊DynamoDB有两种读/写能力模式，用于处理对你的表的读和写。

1.随需应变
2.供给（默认，符合自由层条件）

读/写容量模式控制你如何对读和写的吞吐量收费，以及如何管理容量。你可以在创建表的时候设置读/写容量模式，也可以在以后改变它。

二级索引继承了基础表的读/写容量模式。

按需模式

亚马逊DynamoDB按需服务是一种灵活的计费方式，能够为每秒数以千计的请求提供服务，无需进行容量规划。DynamoDB按需服务为读和写请求提供按请求付费的定价，因此您只需为您使用的内容付费。

当你选择按需模式时，DynamoDB会在你的工作负载上升或下降到之前达到的任何流量水平时立即适应你的工作负载。如果一个工作负载的流量水平达到一个新的峰值，DynamoDB会迅速适应以适应工作负载。使用按需模式的表提供与DynamoDB已经提供的相同的个位数毫秒的延迟、服务级别协议（SLA）承诺和安全性。你可以为新的和现有的表选择按需模式，你可以继续使用现有的DynamoDB API，而无需改变代码。

如果有以下情况，按需模式是一个不错的选择。

1.你创建的新表有未知的工作负载。
2.你有不可预知的应用流量。
3.你喜欢只为你使用的东西付费的便利。

请求率只受DynamoDB吞吐量默认表配额的限制，但它可以根据请求提高。欲了解更多信息，请参阅吞吐量默认配额。

要开始使用按需模式，你可以创建或更新一个表来使用按需模式。

读取请求单元和写入请求单元

对于按需模式的表，你不需要指定你期望你的应用程序执行多少读和写的吞吐量。DynamoDB以读请求单位和写请求单位的形式对你的应用程序在你的表上执行的读和写进行收费。

一个读请求单位代表一个强一致的读请求，或者两个最终一致的读请求，对于一个大小不超过4KB的项目。两个读请求单元代表一个事务性的读，用于4KB以下的项目。如果你需要读取一个大于4KB的项目，DynamoDB需要额外的读取请求单元。所需的读取请求单元的总数取决于项目的大小，以及你想要一个最终一致的或强一致的读取。例如，如果你的项目大小是8KB，你需要2个读取请求单元来维持一个强一致的读取，如果你选择最终一致的读取，则需要1个读取请求单元，或者4个读取请求单元用于交易性读取请求。
一个写请求单元代表一个大小不超过1KB的项目的写。如果你需要写一个大于1KB的项目，DynamoDB需要消耗额外的写请求单元。事务性的写请求需要2个写请求单元来对1KB以下的项目进行一次写。所需的写请求单元的总数取决于项目的大小。例如，如果你的项目大小是2 KB，你需要2个写请求单元来维持一个写请求，或者4个写请求单元来维持一个事务性的写请求。

峰值流量和扩展属性

使用按需容量模式的DynamoDB表自动适应你的应用程序的流量。按需容量模式可以立即容纳一个表上先前峰值流量的两倍。例如，如果你的应用程序的流量模式在每秒25,000到50,000次强烈一致的读取之间变化，其中每秒50,000次读取是以前的流量高峰，按需容量模式立即容纳每秒高达100,000次的持续流量。如果你的应用维持每秒100,000个读数的流量，这个峰值就会成为你以前的新峰值，使后续流量达到每秒200,000个读数。

如果你需要在表上超过以前峰值的两倍，DynamoDB会在你的流量增加时自动分配更多的容量，以帮助确保你的工作负载不会出现节流现象。然而，如果你在30分钟内超过以前峰值的两倍，就会发生节流。例如，如果你的应用程序的流量模式在每秒25,000到50,000次强烈一致的读取之间变化，其中每秒50,000次读取是以前达到的流量峰值，DynamoDB建议在驱动超过每秒100,000次读取之前，将流量增长间隔在至少30分钟。

按需产能模式的初始吞吐量

如果你最近第一次将一个现有的表切换到按需容量模式，或者你在启用按需容量模式的情况下创建了一个新的表，那么该表具有以下以前的峰值设置，即使该表以前没有使用按需容量模式提供流量。

新创建的表，采用按需容量模式。以前的峰值是2,000个写请求单位或6,000个读请求单位。你可以立即开到之前峰值的两倍，这使得新创建的按需表可以提供多达4000个写请求单位和12000个读请求单位的服务。

现有的表切换到按需容量模式。以前的峰值是自表创建以来提供的最大写能力单位和读能力单位的一半，或者是新创建的表按需能力模式的设置，以较高者为准。换句话说，你的表将提供至少与切换到按需容量模式之前一样多的吞吐量。

表中切换读/写容量模式时的行为

当你把一个表从供应容量模式切换到按需容量模式时，DynamoDB会对你的表和分区的结构做一些改变。这个过程可能需要数分钟。在切换期间，你的表提供的吞吐量与之前提供的写容量单位和读容量单位数量一致。当从按需容量模式切换回按需容量模式时，你的表提供的吞吐量与之前表被设置为按需容量模式时达到的峰值一致。

供应模式

如果你选择配置模式，你指定你的应用需要的每秒读写次数。你可以使用自动扩展来响应流量变化，自动调整你的表的配置容量。这可以帮助你管理DynamoDB的使用，使其保持在或低于定义的请求率，以获得成本可预测性。

如果以下情况属实，配置模式是一个不错的选择。

1.你有可预测的应用流量。
2.你运行的应用程序的流量是一致的或逐渐上升的。
3.你可以预测容量需求以控制成本。

读取容量单位和写入容量单位

对于配置模式的表，你以读容量单位（RCU）和写容量单位（WCU）来指定吞吐量。

一个读容量单位代表每秒一次强一致的读取，或每秒两次最终一致的读取，对于大小不超过4KB的项目。事务性读取请求需要两个读取容量单位，对于大小为4KB的项目，每秒执行一次读取。如果你需要读取一个大于4KB的项目，DynamoDB必须消耗额外的读取容量单位。所需的读取容量单位的总数取决于项目的大小，以及你是否想要最终一致或强一致的读取。例如，如果你的项目大小是8KB，你需要2个读取容量单位来维持每秒一次的强一致性读取，如果你选择最终一致的读取，则需要1个读取容量单位，或者4个读取容量单位用于交易性读取请求。

一个写能力单位代表每秒写一个大小不超过1KB的项目。如果你需要写一个大于1KB的项目，DynamoDB必须消耗额外的写能力单位。交易性的写请求需要2个写能力单元，对1KB以下的项目每秒执行一次写。所需的写能力单元的总数取决于项目的大小。例如，如果你的项目大小是2KB，你需要2个写能力单元来维持每秒一次的写请求，或者4个写能力单元来维持交易性写请求。

如果你的应用程序读取或写入更大的项目（达到DynamoDB的最大项目大小400KB），它将消耗更多的容量单位。

例如，假设你创建了一个有6个读取容量单位和6个写入容量单位的供应表。通过这些设置，你的应用程序可以做以下事情。

1.执行每秒高达24KB的强一致性读取（4KB×6个读取容量单元）。
2.执行每秒48KB的最终一致读取（两倍的读取吞吐量）。
3.执行每秒12KB的事务性读取请求。
4.写入每秒6KB（1KB×6个写能力单位）。
5.执行每秒高达3KB的交易性写请求。

规定的吞吐量是一个应用程序可以从表或索引中消耗的最大容量。如果你的应用程序超过了表或索引的规定吞吐量，它将受到请求节流的影响。

节流可以防止你的应用程序消耗太多的容量单位。当一个请求被节制时，它会以HTTP 400代码（坏请求）和ProvisionedThroughputExceededException的形式失败。AWS SDK内置支持重试节流请求（见错误重试和指数退避），所以你不需要自己编写这个逻辑。

你可以使用AWS管理控制台来监控你配置的和实际的吞吐量，并在必要时修改你的吞吐量设置。

DynamoDB自动扩展

DynamoDB自动扩展积极管理表和全局二级索引的吞吐能力。通过自动扩展，你为读和写能力单位定义一个范围（上限和下限）。你也可以在这个范围内定义一个目标利用率百分比。DynamoDB自动扩展寻求维持你的目标利用率，即使你的应用程序工作量增加或减少。

通过DynamoDB自动扩展，表或全局二级索引可以增加其配置的读和写容量，以处理流量的突然增加，而不需要请求节流。当工作负载减少时，DynamoDB自动扩展可以减少吞吐量，这样你就不会为未使用的配置容量付费。

保留容量

作为DynamoDB客户，你可以为使用DynamoDB标准表类的表提前购买保留容量，如Amazon DynamoDB定价所述。使用预留容量，您需要一次性支付预付费用，并承诺在一段时间内达到最低配置的使用水平。您保留的容量按每小时保留容量的费率计费。通过提前保留你的读写容量单位，你可以在你的配置容量成本上实现显著的成本节约。您提供的任何容量超过您的保留容量时，将按照标准的供应容量费率计费。

预留容量的折扣首先适用于购买预留容量的账户。任何未使用的保留容量折扣，然后应用于与购买账户相同的AWS组织中的其他账户。