我们正在为要连接的移动应用程序设置后端架构，但我们需要一些帮助。我们的应用程序旨在模仿您在熟食店或药房看到的“取号”票。用户将使用我们的移动应用程序向我们的节点控制器发送请求，我们的节点控制器将响应一个点号。
我们目前在 Amazon Elastic Beanstalk 上设置了我们的节点控制器，并启用了负载平衡来处理任何请求激增。我们的问题是：我们如何在节点控制器的多个实例中持久化我们的spotNumber？我们现在将它构建为一个从 1 开始并随着每个请求递增的局部变量，但是如果 AWS 启动我们节点控制器的新实例来处理增加的流量，这种情况会持续存在吗？如果不是，那么在我们服务器的所有潜在实例中保留 spotNumber 的最佳做法是什么？
提前谢谢你！
【问题讨论】：
标签： amazon-web-services server architecture load-balancing
使用数据库。
显然，您不能将值存储在节点应用程序中，这不仅是因为缩放，而且是为了防止应用程序意外关闭时数据丢失。
听起来您还没有数据库，因此 DynamoDB 可能是一个不错的选择，只要您的唯一用例是在应用程序之间共享计数器。你可以找到一个例子here。
您也可以使用Redis on Elasticache，但我认为这对于单个计数器来说太过分了。
【讨论】：
ReturnValues:"UPDATED_NEW" 在响应中返回更新后的值。你永远不想读，然后递增（本地），然后写，因为两个并发请求最终会得到相同的值（如果顺序是读 1，读 2，写 1，写 2——这是一场竞赛健康）状况）。让 DynamoDB 进行 +1 数学运算可以避免这种情况，因为并发请求不会干扰彼此的原子性。
在不同的规模上保持准确的计数器可能需要不同的实现。在小规模上，应用程序中的简单会话变量和锁定逻辑就足够了。但是，在更大规模的会话同步和锁定中，使用数据库可以更好地管理。特别是对于您的情况，DynamoDB conditional writes 或 Redis counters 似乎很有用。但是，请保持您的要求简单明了，大规模管理计数器可能需要具有有趣名称的算法和数据结构，例如 HyperLogLog。
【讨论】：