API请求的进程队列

Question

我们目前有一个API，主要采用两种类型的请求：一个用于识别用户详细信息，另一个用于跟踪他们执行的事件。它当前处理请求中的所有逻辑。我们有两个应用程序框，因此可以同时处理两个具有相同数据的识别请求。虽然性能明智，但这种解决方案在目前的规模上很好，我们已经看到了并发问题。

我的问题是：我们如何处理api请求队列，以便在一个工作人员中按顺序完成与一个人相关的请求？

我们的堆栈是Ruby支持MongoDB，我非常乐意探索其他技术，但显然任何利用我们当前堆栈的解决方案都是一个优势。

我考虑过锁定人员记录，但不知道检查锁的方法，如果有空，请将其锁定在一个操作中，这样两个线程就无法检查锁定同时，认为他们都拥有它，但实际上只有一个拥有它。

我当前的想法（对消息队列的经验非常有限）是对请求进行排队，然后使用一致的散列交换来确保对一个人的请求始终路由到同一个工作人员。但阅读文档它看起来像一个一致的哈希交换实际上是打算帮助在工人之间分配任务，而不是通过某个属性对它们进行分组。

Answer 1

您可以使用redis进行锁定。 redis-objects有原语。这是一个较低级别的版本：https://github.com/PatrickTulskie/redis-lock

过去它对我很有用。

Answer 2

任何特定的基于散列的逻辑/分配都会自动具有路由到同一队列的属性，前提是密钥未更改且队列未更改。因此，如果提供相同数量的存储桶和相同的密钥，则应将其路由到同一个存储桶。

从快速浏览一致的哈希交换，该主体是完整的。主要目标可能是将负载分配到队列中，但唯一/一致路由的次要属性将作为其一部分进行保存。

如果负载分配是唯一的目标，那么就不需要密钥，并且负载也可以循环分配。