amazon-web-services - 在 AWS Lambda 实例之间协调单例 token

Question

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

机器人向 POST /auth 创建请求带有一堆 secret 信息，并返回一个 token 作为响应。

然后机器人向 POST /messages 发出请求与 Authorization: Bearer <token>将消息发布到聊天中。

token 在几个小时后过期。

关键是一个 POST /auth request 重置任何先前的 token 并使持有 token 的所有其他客户端无效。没有 GET /auth或类似以获取现有 token 。
这现在成为随机产生的机器人的并发实例之间的协调问题。它们都需要使用相同的 token ，但会独立生成 token 。我不太热衷于引入一些单例服务，其任务只是协调 token ，我想保留独立扩展的 Lambda 范式。我正在使用 DynamoDB 来存储 token 以尝试在机器人实例之间协调它们，但仍然存在边缘情况竞争条件，可能需要多达 3 次重试才能解决 token 问题。
最坏的情况是 DynamoDB 中存储的无效 token 和同时实例化的两个机器人:

两者都将读取无效 token

两者都将尝试失败的请求

两者都将尝试再次读取 token ，因为另一个机器人可能同时刷新了它

两者都将丢弃已知为坏的 token

两者都会生成一个新 token 并存储它，其中一个随机“获胜”

“失败者”将执行另一个错误请求并重复前面的步骤

理想情况下，应该有一个可锁定的资源，一个机器人可以锁定并生成 token ，其他机器人可以等待。但是 AFAIK DynamoDB 没有那种功能。
在独立的并行 Lambda 实例之间协调这种单例 token 的良好模式和/或 AWS 服务是什么？

Answer 1

就个人而言，我会尝试将 token 的读写操作解耦。应该只有一个写入 token 的“进程”和多个从存储中读取 token 的“进程”。
例如，一种解决方案可能是您使用 AWS EventBridge 定期触发 Lambda(例如每 30 分钟)。此 Lambda 调用 /auth端点，获取新 token ，然后将其存储在 DynamoDB 中。
然后，具有业务逻辑的 Lambda 应该使用一致/强读取来避免竞争条件(写入新 token 而另一个 Lambda 读取现在过时的 token )。
您的消息 Lambda 中的业务逻辑现在只需从数据库中读取 token ，允许您“扩展”到任意数量的 Lambda，而不会相互干扰。