如何使用 Uber Cadence 设计无状态 worker 仅处理一次消息

how to design a stateless worker to process message only once using Uber Cadence

请帮助我们采用 Cadence :D

这是当前的设计。一些无状态工作者从集中式队列中提取消息来处理它。 worker 和 Deduper 特性涉及复杂的业务逻辑,它利用单独的 Redis 集群作为远程分布式缓存(使用共识的强一致性)。此缓存仅存储消息 ID 及其状态 "in progress"、"completed" 和 "not started"。显然,worker 应该处理未完成的消息。

就我个人而言,我想重新考虑所有可能的解决方案。我想到了工作流模型,因为我对 AWS SWF 有愉快的体验。由于我们所有的服务都是在我们自己的数据中心上用 go 和 运行 编写的,所以我想试试 Uber Cadence(SWF 的开源)。

我看了很多 Uber 用户的视频,我认为第一步是在新的工作流程中有一个 activity 作为开始,然后将其分解为多个活动,或者在我们迁移后可能会使用 AWS lambda它到 AWS。

所以我在这里列出所有要求

  1. 避免多个工作人员处理消息两次。
  2. 50k req/s 所以需要可扩展的解决方案
  3. p99 上的低延迟,希望小于 300 毫秒

目前只有第一个需求很头疼,因为Redis缓存是一个远程缓存集群。产品中存在一些连接问题,我们真的想摆脱它以避免复杂性和额外的网络跃点。

问题:

  1. 所以我想知道切换到Cadence后如何设计去重器?

通过阅读文档,Cadence 在域内提供了工作流 ID 唯一性功能。也许我可以使用消息 ID 作为工作流 ID 的一部分,例如 WF-00001,以保证域内没有重复项。只要我只使用一个域,就不会有问题。然后我不知道这种方法的局限性。例如,域内允许的工作流数量。我们有 50k 消息处理速率/秒(峰值)

我不确定这是否是正确的方法。欢迎提出更多想法。

  1. 是否有列出 Cadence 所有限制的网页?我们需要它来评估 Cadence。

谢谢

SWF Step Function Uber Cadence

在高层次上,Cadence 非常适合您的用例。

  1. Deduper 非常简单。 Workflow 保留最近请求 ID 的映射(或者属于给定 workflowID 的所有请求,如果它们的数量是有界的)并对其执行重复检查。

  2. 大多数 Cadence 限制都是特定于部署且可配置的。让我们在 Slack 讨论您的具体用例。