可靠的消息传递

Question

对不起，我需要先解释一下才能解决这个问题。

我正在使用Kafka Client 0.9.0.0向Kafka集群发送消息。该系统是一种管道，它使用来自JMS的消息并将其发送给Kafka。为确保消息可靠性，JMS确认模式设置为CLIENT_ACKNOWLEDGE，以便在成功使用和处理消息时，应用程序确认消息接收。

消息被消费后，消息将发送给Kafka，这就是问题所在。

异步：

我可以使用Kafka生产者异步发送和回调，如果将消息发送到Kafka时出错，则通知JMS使用者不要确认消息消耗为时已晚。为了解决这个问题，我想到的唯一的事情是如果有异常则在Callback中存留消息，并尝试稍后发送消息。但我认为这将是太多的开销。

有没有其他方法可以使用异步调用来处理这种情况？

同步

使用同步调用，在Producer.send（）返回的未来上调用get（），如果在向Kafka发送消息时出现任何问题，则会抛出异常，并且可以将其报告给JMS使用者，以便获胜不承认该消息，并在稍后重试。

显然它会产生性能影响，因为这将是一个阻塞调用，不好的部分是没有批量消息，因为Kafka会确认每条消息。

我倾向于同步通话，因为我不想要额外的持久性。

是否有任何方式或配置，我可以使用同步呼叫，并最大限度地减少同步呼叫的影响？我做的一个配置是拥有一个JMS使用者池。

Answer 1

异步方式：

除了坚持之外别无他法。你需要权衡表现。

您收到了来自JMS的消息。承认你读过它。当试图推动卡夫卡的话题，由于某种原因它失败了。为了保证这一点，你需要做两件事。

1. 如果失败，有一个重新启动机制推送到kafka。您可以使用指数退避重试机制来满足间歇性问题（例如，网络中断）
2. 如果kafka推送失败，则在kafka或JMS中创建一个错误主题。将错误主题再次作为管道的输入。您将需要限制错误主题的消耗，因为如果由于某种原因导致应用程序重复失败，它可能会使您的应用程序过载。

这将使其更加可靠。

同步方式：

我不确定在这种情况下如何改善性能。如果性能在您的应用程序中不是问题，我建议您采用这种方式，因为这是最快速和最简单的方法。

我不确定你坚持回调是什么意思。如果你的意思是你将消息存储在内存中，那么这是一个坏主意，因为如果应用程序由于某种原因关闭或停止，你将丢失消息。