消息只是另一个请求-响应调用一个代理

最后一次,我们讨论了关于复制数据库记录的风险由于DB协议的请求-响应性质。

消息,乍一看,是一个不同的野兽:你不要等到得到回复之前。作为一个事实,你通常不会回复:你只是播放一些事件和你不是真的想知道其他服务将使用它们。

除了消息只是一个API调用委托第三方服务。你真的做些什么消息传递是问另一个服务,通常称为消息代理,负责后期交付可能感兴趣的下游服务。

当你最终交付的委托责任,您仍然需要确保这个代表团已经设置成功:一旦你的包在UPS的手中,这真的不是你的问题了,但是如果你让它为UPS集合在街上没有监督它丢失在UPS司机到来之前,仅是你的责任!

我看到消息描述为“发射后不管”。没有什么可以进一步从真相!你还需要确保你的经纪人收到了消息请求之前。

代理应答问题

像往常一样,如果你打电话给你的消息代理提交进一步分布的新消息,你就不能肯定是否这个代表团已经设置成功,直到你从代理接收应答。如果你没有收到Ack,那么消息可能有也可能没有被提交,这意味着消费者可能会或可能不会收到你的消息。

我们可以做相同的论点为代理我们的简介:

如果你不检查和等待Ack,你永远无法确定你的信息被安全地送到代理,这可能意味着消息丢失。但是如果你等待Ack从未得到它(或你收到一些技术或网络错误),那么你是Ack面临的问题。

从那里有很多可能性:

• 对你有一种方法来检查是否发送的消息是,通过查询代理;
• 你只报告一个错误自己的调用者,任何正在进行的事务回滚。但这意味着您可能没有记录,在您的数据库,是发送的消息;
• 你前进,忽略错误,但这意味着你可能,最后,不能发送消息,要求下游服务;
• 你可以重试发送消息,但这意味着你可能会重复发送请求。如果所有失败重试(如果网络中断了,这是很有可能发生)?

似乎引入这种消息传递方法根本不能解决任何问题。事实上,它可能会引入更多的问题。

在未来的文章中,我们将讨论典型的消息传递模式以及如何处理这些情况。

在前一篇文章我们看到,Ack问题意想不到的后果如何与数据库进行交互。在本文中,我们扩展了message broker谈话。在下一篇文章,我们将会看到,它适用于任何类型的API。