在 AWS Lambda 实例之间协调单例令牌

Question

考虑一个编写为AWS Lambda函数的聊天机器人。它通过来自第三方服务的HTTP请求被调用，第三方服务是它集成的聊天服务。现在，第三方API有点…古怪。它的主要问题是：它需要一个身份验证令牌才能与之交互，但任何时候只能存在一个令牌。它的工作方式是：

• Bot创建一个带有一堆秘密信息的POST /auth请求，并返回一个令牌作为响应。
• 然后，Bot向POST /messages发出请求，并带有授权：承载

关键是< code>POST /auth请求会重置任何以前的令牌，并使持有令牌的所有其他客户端无效。没有< code>GET /auth或类似的方法来获取现有令牌。

这现在变成了随机产生的机器人的并发实例之间的协调问题。它们都需要使用同一个令牌，但是会独立生成令牌。我不太热衷于引入一些任务只是协调令牌的单体服务，我希望保持独立伸缩的Lambda范式。我使用DynamoDB来存储令牌，试图在bot实例之间协调它们，但仍然存在边缘情况竞争条件，这可能需要最多三次重试才能解决令牌。

最坏的情况是存储在 DynamoDB 中的无效令牌和两个同时实例化的机器人：

• 两者都将读取无效令牌
• 两者都将尝试失败的请求
• 两者都将尝试再次读取令牌，因为另一个机器人可能在此期间刷新了它
• 两者都将丢弃已知是坏的令牌
• 两者都会生成一个新的代币并存储，其中一个随机“获胜”
• "失败者"将在做另一个糟糕的请求，重复前面的步骤

理想情况下，应该有一个可锁定的资源，一个机器人可以锁定并生成令牌，其他机器人可以等待。但是AFAIK DynamoDB没有那种功能。

有什么好的模式和/或AWS服务来协调独立的、并行的Lambda实例之间的单例令牌？

Answer 1

虽然 DynamoDB 中没有实现本机锁定，但以下是 2017 年的 AWS 博客文章，其中展示了适用于 Java 开发工具包的 DynamoDB 锁定库。https://aws.amazon.com/blogs/database/building-distributed-locks-with-the-dynamodb-lock-client/

以下摘录对该机制有所启发：

DynamoDB锁客户端使用DynamoDB UpdateItem API来心跳和扩展每个主机拥有的锁。此外，锁客户端使用客户端TTL来过期锁。锁客户端使用最新版本的AWS SDKJava。锁定协议在锁的整个生命周期中广泛使用条件更新（创建、心跳更新和删除过期）。

有一些针对其他语言（如Python）的分支和改编。

Answer 2

我想对“延斯”的回答提出一个稍微不同的看法：

>

使用 DynamoDB 存储当前身份验证令牌：具有单个条目的 DDB 表可用作身份验证令牌的权威源。有关如何更新令牌的更多信息，请参阅下面的#3。

auth令牌的本地缓存:虽然Lambda应该是无状态的，但它确实有能力进行一些本地缓存，所以每个Lambda实例都应该遵循如下逻辑:

• 如果它在本地缓存中具有身份验证令牌的 NULL 值，请从 DDB 读取它并更新本地缓存
• 如果它具有身份验证令牌的非 NULL 值，则尝试使用身份验证令牌发出请求
• 如果请求因令牌无效而失败，请尝试执行令牌刷新（请参阅下面的 #3）

利用条件写入来刷新令牌:为此，任何发现坏令牌的lambda实例都应该通过对DDB表中的令牌记录进行条件写入来尝试“指定自己”刷新令牌，尝试将自己声明为自己指定的更新者

< li >如果条件写入成功，lambda继续发出< code>POST /auth请求，获取新令牌，随后更新DDB记录，并将其自身从锁定中移除； < li >如果条件写入失败，lambda应该后退一段时间(可能200毫秒左右),然后尝试重新读取记录，以查看在此期间另一个lambda是否成功刷新了令牌 < li >如果在读取记录时，lambda确定令牌已经被刷新(即令牌值不同于它所拥有的值)，它可以继续使用新令牌，一切正常；如果发现记录仍被锁定，它可以再等待一段时间，然后重试 < li >您可能应该设定一个安全的回退时间段(比如1-2秒)，在此之后，lambda应该“接管”更新令牌的责任，假设之前锁定它的另一个实例由于某种原因已经终止；这意味着您不会陷入所有实例都永远等待的死锁中

这个解决方案的优点是减少了为每个请求从DDB读取数据的需要，并且不需要任何其他服务(除了Lambda和DDB)。

执行条件写入时，lambda 可以为操作生成 UUID，并在项目上存储此 UUID 和时间戳，以指示项目被“锁定”的时间。后续实例将读取 UUID 和时间戳，并确定某个其他实例必须正在处理该项目。如果自项目锁定以来已经过了太多时间，则另一个实例可以“接管”。

Answer 3

就个人而言，我会尝试将令牌的读写操作分离。应该只有一个“进程”写入令牌，而多个“进程”从您的存储中读取令牌。

例如，一种解决方案是使用AWS EventBridge定期触发Lambda(比如每30分钟一次)。这个Lambda调用< code>/authendpoint，获取一个新的令牌，然后将其存储在DynamoDB中。

然后，具有业务逻辑的Lambda应该使用一致/强读取来避免竞争情况(当另一个Lambda读取现在陈旧的令牌时，写入新的令牌)。

您的消息 Lambda 中的业务逻辑现在只需从数据库中读取令牌，从而允许您根据需要“扩展”到任意数量的 Lambda，而无需它们相互干扰。