处理rabbitmq消息处理时的最佳方法

时间:2016-06-21 16:05:39

标签: error-handling timeout rabbitmq riak

我正试图解决我最近遇到的一个问题,我希望有人能指出我解决问题的最合理方向。

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

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

最后,我有一组服务工作者,它们侦听队列,并为每个请求尝试相应地更改计数器的数量。

我遇到的问题如下:当一个工作者正在处理一个请求时,它可能会在对数据库的写操作上停留一段时间 - 让我们说第二次更改三个计数器。它与rabbitmq的连接丢失(超时),因此消息请求返回到队列(我不能错过一个)。然后它由第二个工作人员接收,它开始重新处理。但是,第一个工作人员完成了它的工作,结果我已经处理了两次单个消息。

我可以将这些增量分成单个动作,但这仍然让我陷入两难境地 - 如果某个工作人员长时间陷入写操作,仍然可以两次更改计数器的值。

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

1 个答案:

答案 0 :(得分:1)

你不能拥有“完全一次交付”的语义。您可以减少双重发送的消息或错过的交付,因此您可以自行决定哪种不当行为最不方便。

首先,您确定CRDT太慢了吗?你在地图中使用简单的计数器或计数器吗?根据我的经验,它们非常快,虽然比kv慢。你可以尝试: - 拥有简单的CRDT(没有地图)和更多的CRDT对象,以降低他们的压力(你可以将计数器分成两部分吗?) - 不使用CRDT,而是在客户端使用简单的键/值使用良好的旧兄弟分辨率。 - 累积计数更新订单并批量应用它们,但随后您接受延迟增加,因此相当于增加超时。

您能提供一些指标吗?比如更新需要多长时间,你会期望什么数字,如果你没有更新或很多更新等等那么慢,等等