1

请帮助我们采用 Cadence :D

这是当前的设计。一些无状态工作者从一个集中的队列中提取消息来处理它。复杂的业务逻辑涉及工作人员以及利用单独的 Redis 集群作为远程分布式缓存的 Deduper 功能（使用共识的强一致性）。此缓存仅存储消息 ID 及其状态“进行中”、“完成”和“未开始”。显然，工人应该处理未完成的消息。

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

我观看了许多来自 Uber 用户的视频，我认为第一步是在新的工作流程中创建一个活动作为开始，然后将其分解为多个活动，或者在我们将其迁移到 AWS 之后再将其分解为 AWS lambda。

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

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

现在只有第一个要求是一个令人头疼的问题，因为 Redis 缓存是一个远程缓存集群。prod 中存在一些连接问题，我们真的想摆脱它以避免复杂性和额外的网络跃点。

问题：

  1. 所以我想知道在切换到Cadence时如何设计重复数据删除器？

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

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

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

谢谢

SWF 阶梯函数 Uber Cadence

4

1 回答 1

1

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

  1. 重复数据删除器非常简单。Workflow 保留最近请求 id 的映射（或所有属于给定 workflowID 的请求，如果它们的数量是有界的）并对其执行重复检查。

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

于 2019-08-07T17:51:57.157 回答