英文:
Redisson, working queue / dequeu. Strategies on processing message / element on incomplete message handling on system / pod shutdown
问题
所以我先获取头部元素然后开始处理。问题是，如果要扩展并使用每个Pod/实例的8线程执行器服务，在系统突然关闭时，“消息”可能已被视为已获取/已消耗。
我猜一种策略是为每个队列/出队使用一个单独的分布式Redisson 列表/映射，表示这些元素/消息正在被处理。我猜这会起作用，但是跟踪该列表也不容易。
是否有一种方法可以获取头部元素，以某种方式使用活动对象，然后标记队列中的元素为已管理，并在完成后以某种方式将其移除，复杂度为O(1)？
英文:
So I takeHead then i start processing. Problem if this is to be scaled and using an 8 thread executor service per pod/instance, on sudden shutdown of system, the "messages" would have been deemed taken / consumed already.
One strategy I guess is to use a separate distributed Redisson list / map per queue / dequeue that says that these elements / messages are being processed. I guess that would work, however keeping track of that list is not easy either.
Is there a way to takeHead, use live object somehow and then mark an element in queue as being managed, and then somehow remove it when done O(1) ?
答案1
得分: 1
所以我取了头部，然后开始处理。问题在于如果要进行扩展并且每个 pod/实例使用一个包含 8 个线程的执行器服务，系统突然关闭时，“消息” 已被视为已取出/已消耗。
您需要使用 RStream 对象，它允许跟踪每个消费者未消耗的元素。
英文:
> So I takeHead then i start processing. Problem if this is to be scaled and using an 8 thread executor service per pod/instance, on sudden shutdown of system, the "messages" would have been deemed taken / consumed already.
You need to use RStream object instead it allows to track unconsumed elements per consumer.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论