【问题标题】:How to check if the DELETE API has been called如何检查是否已调用 DELETE API
【发布时间】:2018-09-23 09:24:59
【问题描述】:

我的任务是实现一个分布式排队系统,比如 Amazon SQS。

如果有 GET 请求,我必须将消息从主队列传递给用户,并将消息放入不可见队列中。并且会立即收到一个 DELETE 请求,我应该从隐形队列中删除该消息。

如果没有删除请求,我应该增加重新发送计数并将消息发送回主队列。这将一直发生,直到重新发送计数变为 5,之后我将永久删除该消息。

现在我的疑问是,我怎么知道没有 DELETE 请求,这意味着我应该将消息发送回主队列?

我的程序适用于 DELETE 请求跟随 GET 请求的情况。我正在使用 java 来实现。

【问题讨论】:

  • 您应该建立一个请求删除的时间窗口。说30秒。在那之后,系统将像没有收到任何删除一样行事
  • @SharonBenAsher 我对如何实现它感到困惑。你是说我等待大约一分钟然后检查我上次尝试传递的消息是否在隐形队列中,如果是,我应该把它放回去吗?对我来说,这似乎是错误的解决方案。

标签: java service message-queue


【解决方案1】:

首先,在设计层面,get 和 delete 应该在一个动作中完成。注意in the JDKpull() 操作Queue 将执行获取和删除。如果您坚持单独的操作,至少您应该支持可选的获取和删除请求类型。

现在,当您想要检测一个没有发生的动作时会出现问题,因为它可能永远“可能在未来发生”。因此,您需要设置一个时间窗口,在此之后您决定预期的操作没有发生。

通常的做法是,在将请求放入不可见队列(更好的名称是“待删除请求”队列)之前,将“已接收”时间戳附加到请求(以及重新发送计数),您可以包装添加属性的自定义 java 类中的请求。

实际上,我不认为队列是集合的好选择。当删除请求确实到来时,您需要随机访问该请求。所以也许哈希映射是更好的选择。

您需要实现一个Timer,它每 x 秒调用一次任务。这些任务将扫描pendingDeleteRequests 地图以查找在允许的时间窗口内未收到删除并从地图中删除的请求。

最后一点:一些消息传递系统具有"dead letter" 功能,这是发送失败通知的目的地。这将有助于调试问题。

【讨论】:

  • 我将队列实现为 LinkedHashMap(实际上,三个 LinkedHashMap 中的一个 HasMap 充当多个队列)。是的,我也想过实现死信功能,但这将在此工作之后。
  • 非常感谢我能做到!
猜你喜欢
  • 2020-06-03
  • 1970-01-01
  • 2012-03-02
  • 2019-06-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-05-01
  • 1970-01-01
相关资源
最近更新 更多