我正在考虑在我的应用程序中使用Amazon DynamoDB，但我对其atomic counters 的可靠性有疑问。
我正在构建一个分布式应用程序，该应用程序需要同时和一致递增/递减存储在 Dynamo 属性中的计数器。 我想知道 Dynamo 的原子计数器在重并发环境中的可靠性如何，其中并发级别非常高（假设，例如，平均 20k 并发命中率 - 明白这一点，这将是近 520 亿的增量/每月递减）。
计数器应该是超级可靠的，并且永远不会错过任何命中。有人在如此关键的环境中测试过 DynamoDB 吗？
谢谢
【问题讨论】：
标签： concurrency counter atomic increment amazon-dynamodb
DynamoDB 通过在多个服务器之间拆分密钥来获得它的扩展属性。这类似于 Cassandra 和 HBase 等其他分布式数据库的扩展方式。虽然您可以增加 DynamoDB 上的吞吐量，只需将您的数据移动到多个服务器，现在每个服务器都可以处理总并发连接数/服务器数量。查看at their FAQ 了解如何实现最大吞吐量：
问：我是否总是能够达到我的预置吞吐量水平？
Amazon DynamoDB 假定所有主键的访问模式相对随机。您应该设置您的数据模型，以便您的请求导致跨主键的流量分布相当均匀。如果您的访问模式非常不均匀或有偏差，您可能无法达到您的预置吞吐量水平。
在存储数据时，Amazon DynamoDB 将一个表划分为多个分区，并根据主键的哈希键元素分布数据。与表关联的预置吞吐量也在分区之间分配；每个分区的吞吐量根据分配给它的配额独立管理。没有跨分区共享预配置吞吐量。因此，如果工作负载相当均匀地分布在散列键值上，Amazon DynamoDB 中的表最能满足预置的吞吐量水平。跨哈希键值分布请求会跨分区分布请求，这有助于实现完全预置的吞吐量水平。
如果您的主键工作负载模式不均衡，并且无法达到预置吞吐量水平，您可以通过进一步提高预置吞吐量水平来满足吞吐量需求，这将为每个分区提供更多吞吐量。但是，建议您考虑修改请求模式或数据模型，以实现跨主键的相对随机访问模式。
这意味着拥有一个直接递增的密钥将无法扩展，因为该密钥必须位于一台服务器上。还有其他方法可以处理此问题，例如在内存聚合中使用 DynamoDB 的刷新增量（尽管这可能存在可靠性问题）或分片计数器，其中增量分布在多个键上并通过拉取分片中的所有键来读取计数器 (http://whynosql.com/scaling-distributed-counters/)。
【讨论】：
除了 gigq 关于可扩展性的回答之外，DynamoDBs 原子增量不是幂等的，因此不可靠：如果在发出UpdateItemADD 请求后连接断开，您无法知道添加是否已提交或不，所以你不知道是否应该重试。
DynamoDB 条件更新解决了这个问题，但代价是系统的可扩展性更低，因为每次同时尝试对属性进行两次更改时，您都必须重试，即使没有出现错误。
【讨论】：
ReturnValues 会怎样？这样一来，您就可以在更新完成后获得价值。返回值是强一致的。然后你不需要阅读，然后更新。如果您的网络中断，请重试。最坏的情况是你跳过序列中的一个数字。 docs.aws.amazon.com/amazondynamodb/latest/APIReference/…
如果您要编写单个 dynamo db 密钥，您将遇到 热分区 问题。热分区问题从每个索引大约 300 TPS 开始。因此，如果表中有 5 个索引，您可能会看到 300/5 ~ 60 TPS 左右的热分区问题。
否则，dynamo db 可扩展到大约 10-40K TPS，具体取决于您的用例。
【讨论】：