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

Question

请帮助我们采用Cadence：D

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

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

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

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

1. 避免由多个工作人员两次处理消息。
2. 5万请求/秒，因此需要可扩展的解决方案
3. 在p99上的低延迟，希望<300ms

由于Redis缓存是一个远程缓存群集，因此目前唯一的首要要求是头痛。产品中存在一些连通性问题，我们真的想摆脱它，以避免复杂性和额外的网络跳数。

问题：

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

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

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

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

谢谢

SWF步功能Uber节奏

Answer 1

从总体上讲，Cadence非常适合您的用例。

1. Deduper非常简单。工作流会保留最近的请求ID（或如果它们的编号受限制，则属于给定工作流ID的所有请求）的映射，并对其进行重复检查。

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