error-handling - 处理Rabbitmq消息处理超时的最佳方法

Question

我正在努力解决我最近遇到的一个问题，希望有人能够指出我解决问题的最合理方向。

我正在使用Riak KV存储并处理CRDT数据，其中在数据库中存储的每个CRDT项目中都有某种计数器。

我有一个Rabbitmq队列，其中每个消息都是增加或减少一定数量的上述计数器的请求。

最后，我有一组服务人员，他们在队列中侦听，并且针对每个请求尝试相应地更改计数器的数量。

我遇到的问题如下:当一个工作人员正在处理一个请求时，它可能会在对数据库的写操作上停留一会儿-比方说，在三个计数器的第二次更改中。与rabbitmq的连接丢失(超时)，因此消息请求又回到了队列中(我不能错过任何一个)。然后由第二个 worker 将其捡起，然后重新开始所有处理。但是，第一个工作人员完成了工作，结果我处理了一条消息两次。

我可以将这些增量拆分为单个 Action ，但这仍然使我陷入困境–如果某些工作人员长时间卡在写操作中，仍然可以两次更改计数器的值。

我没有可能使Riak KV CRDT的编写工作更快，也不能接受错过任何消息请求。我需要实现一些检查请求是否已经处理过的方法。
我最初的想法是，如果要处理RabbitMQ消息ID，则使用一些替代的快速KV存储来存储RabbitMQ消息ID。这样，其他工作人员便可以判断他们是否没有开始处理已在其他位置解析的消息。
我可以使用任何帮助和指向我可以阅读的 Material 的指针。

Answer 1

您不能具有“完全一次交付”的语义。您可以减少重复发送的邮件或错过的投递，因此由您决定哪种不当行为最不便。

首先，您确定CRDT太慢了吗？您是在 map 中使用简单计数器还是计数器？以我的经验，它们比kv慢，但速度很快。您可以尝试:
-具有简单的CRDT(无 map )和更多的CRDT对象，以降低其压力(可以将计数器分成两部分吗？)
-不使用CRDT，而是在客户端对简单键/值使用良好的旧同级分辨率。
-累积计数更新订单并分批应用它们，但是随后您接受了延迟的增加，所以这等同于增加超时。

您可以提供一些指标吗？如更新需要多长时间，您期望的数字，如果更新少或更新多时速度慢等