使用redis的协作脱机多步骤作业队列

iswrvxsc  于 2021-06-09  发布在  Redis
关注(0)|答案(0)|浏览(232)

我有以下结构:

+-------------------+
        |                   |
        |       Server      |
        |                   |
        +--+--------------+-+
           |              |
           |              |
           |              |
           |              |
+----------+--+         +-+----------+
|             |         |            |
|             |         |            |
|    User1    |         |    User2   |
|             |         |            |
|             |         |            |
+-------------+         +------------+

其中所有三个(服务器、用户1、用户2)都需要为用户1创建的每个作业处理来自彼此的多个数据项。 User1 创建作业。他做了些工作,把数据发给 Server 以及 User2 . Server 为这份工作做一些工作,并把他的数据发送给 User1 以及 User2 . User2 为工作做一些工作并将数据发送给 Server 以及 User1 .
在所有3个参与者从所有其他参与者处收到该步骤的数据后,他们可以使用新数据开始该过程的下一步/迭代,直到作业完成(需要5次迭代)。
注意:任何给定的用户都可能从事有多个用户的作业。在使用类似流程的情况下,还会有多种类型的作业。在每个作业过程中,在所有3个参与者完成当前步骤并将其数据发送给其他参与者之前,任何参与者都不能继续作业的下一步。
我最初是用redis pub/sub实现的,每个用户都有自己的频道。然后我意识到,如果一个用户离线,它会破坏这个过程。我希望用户能够在线继续处理他可能在处理过程中离线的作业。同时,他也能够在离线时以参与者的身份开始的工作中履行自己的职责。如果不将消息缓存到其他位置,则无法使用pub/sub完成此操作。
在redis中,有列表和流。我渴望切换到其中一个或使用两个如果必要的。
我应该使用列表还是流来执行此任务?
也许流的列表(队列)更合适?
每个用户都应该获得自己的列表/队列或流吗?
我认为当有新的作业或步骤/数据点等待用户处理时,仍然应该使用pub/sub来通知用户。这样他们就不必轮询服务器(可能有成千上万的用户)。也许他们应该只在第一次上网的时候对自己的列表或流媒体进行投票,然后pub/sub就可以告诉他们什么时候有新的东西?
我很感激你的洞察力。

暂无答案!

目前还没有任何答案,快来回答吧!

相关问题