Architecture 消息需要访问共享数据时的消息队列体系结构

我必须建立一个运动检测服务。运动检测不在视频上运行，而是在静止图像上运行

该微服务需要能够接收无序的图像（带有时间戳），并确定图像是否与之前拍摄的图像不同（带有早于它的时间戳）。需要多个运动检测人员

因此，关键要求似乎是：

一个web服务可以按顺序接收图像，能够将它们分成前一对和下一对，然后计算一个图像与前一个图像相比是否有运动

许多图像制作人平均每秒似乎有100张左右的图像

许多运动检测消费者

优先考虑延迟而不是吞吐量

不易独立使用的任务

我正在考虑使用单个消息队列。生产者将图像文档推送到队列中。然后，运动检测工作人员从该队列中读取数据，并向该文档添加一个“diff_percentage”字段，并在数据库中更新该记录

给定队列中的一个任务，工作人员可以单独操作该任务，方法是直接从数据库中获取图像，然后进行比较，然后更新数据库中的记录。不幸的是，虽然这样做已经足够好了，但速度会非常慢。我想我需要减少对数据库的读取。理想情况下，我希望这个“队列”能够缓冲，直到它具有给定作业所需的图像。类似于。。。当工作进程从队列中读取时，检查它需要比较的映像是否在队列中，如果不在队列中，则转到数据库

谁能给我指出正确的方向吗？也许排队不是我想要的？也许是一个队列，或者某种缓存桶

我建议您不要将图像直接存储在数据库中。将所有二进制信息输入和输出数据库很容易造成瓶颈。将图像存储在blob存储（如amazons3或googlecloudstorage）上，只需在数据库中存储对它们的引用

我建议您将ApacheKafka作为消息队列的一个选项。它支持多个并发读卡器读取单个队列中的所有消息

---

我认为您的问题来自于尝试对许多图像制作者使用单个队列。这会导致图像集中在一起，然后需要解开图像序列

我的方法是将图像流到带有时间戳的目录和文件中。不要混用图像制作人，让他们分开。然后很容易扫描文件并用

差异百分比标记它们

例如，图像生成器#1将文件存储在目录
/IP1/date/time/sequence
中，其中
date
类似于20140727（2014-07-27），
time
类似于1542（3:42pm），
sequence
是一个从1到6000的计数器（最高每秒100帧，每分钟60秒）。为其他图像制作者复制此结构。通过这种方式，映像独立于工作进程进行存储，并且不存在队列或数据库的瓶颈

然后，并行运行您想要的尽可能多的消费者，这些消费者可以醒来，处理一大块图像，并在文件用完时进入睡眠状态。它们需要在单独的目录上工作，从而彼此独立工作。我会让他们为每个图像添加带有
diff_percentage
的文件到目录中，并且在目录（
time
或
date
）完成时添加另一个文件。这使得它们很容易重新启动并赶上，以防意外停止

这是旧的“方法”。通过使图像流保持分离，可以更容易地在消费者进程之间分配工作。
具有多个生产者和多个消费者的图像队列似乎是正确的方法。对于这个答案的其余部分，我将从这个队列的细节中抽象出来，因为这些细节取决于生产者和消费者所在的位置（物理上在哪台机器上）

以下是在消费者端要做的事情：

将图像暂时保存在内存中。键是时间戳，值是指向图像内容（以及您可能希望保留的任何元数据）的指针。一旦将图像与连续时间戳的图像进行比较，就可以从哈希表中删除图像

您的消费机器需要有足够的工作内存来存储图像。如果在给定时间戳和该时间戳之间直接在其之前或之后接收到平均100个图像，并且图像的平均大小为1MB，则这些图像将一起占用100*2*1MB=200MB的内存

创建第二个内存队列，以跟踪尚无法比较的图像。如果在接收具有当前时间戳的图像时，具有上一个时间戳的图像无法从哈希表中获得，则工作人员会将具有其时间戳的图像指针放入该队列。第二组worker从这个队列中获取时间戳，并同时测试前一个时间戳的映像是否可用。如果是这样，它会比较图像，否则会将图像和时间戳推回到队列中

第一组和第二组工作人员的相对大小应与其直接后续人员之前到达的图像的相对频率成比例。换句话说，如果60%的时间图像在其直接后继图像之前进入哈希表（因此40%的时间图像在其直接后继图像之后到达），则60%的辅助图像应位于第一组，40%的辅助图像应位于第二组。或者，您可以根据需要动态地将工作人员分配到集合；如果出现故障，这可能是适当的