你可能用错了 kafka 的重试机制( 五 ) 作者｜DaveTaubler译者

文章图片
Zo?消息已隐藏，并且Zoiee消息现在已成功处理完毕。目前，两个有界上下文之间的数据是一致的。
晚些时候，我们的团队会修复消费者，以便其可以正确处理特殊字符并重新部署它。然后，我们将Zo?消息重新发布给消费者，消费者现在可以正确处理该消息了。

文章图片
当更新的消费者随后处理隐藏的Zo?消息后，两个有界上下文之间的数据将变得不一致。因此，当User有界上下文将用户视为Zoiee时， Login有界上下文会将她称为Zo? 。
显然，我们没有保持排序；Zo?是在Zoiee之前由Login消费者处理的，但正确的顺序是倒过来的。隐藏一条消息后，我们可以开始隐藏所有消息，但在那种情况下我们实际上会陷入困境。幸运的是，我们不需要保持所有消息的顺序，只需考虑与单个聚合相关联的消息即可。因此，如果我们的消费者可以跟踪已隐藏的特定聚合，它就可以确保属于同一聚合的后续消息也被隐藏。
收到隐藏主题中消息的警报后，我们可以取消部署消费者并修复其代码（请注意：切勿修改消息本身；消息代表不可变的事件！）在修复并测试了我们的消费者之后，我们可以重新部署它。当然，在继续使用主要主题之前，我们将需要特别注意先处理隐藏主题中的所有记录。这样，我们将继续保持正确的排序状态。出于这个原因，我们将首先部署隐藏消费者，并且只有在其完成时（这意味着消费者组中的所有实例都完成，如果我们使用了多个消费者），我们才会取消部署它并部署主消费者。
我们还应该考虑以下事实：固定的消费者处理了隐藏消息后，它仍可能会遇到其他错误。在这种情况下，其错误处理行为应像我们之前描述的那样：
如果错误是可恢复的，则使用退避策略重试；
如果错误是不可恢复的，它将隐藏消息并继续下一条消息。
为此，我们可以考虑使用第二个隐藏主题。
5可以接受一些数据不一致？这样的系统构建起来可能会变得相当复杂。它们可能很难构建、测试和维护。因此，某些组织可能会想要确定出数据不一致的可能性，并判断他们是否可以承受这种风险。
在许多情况下，这些组织可能会采用数据协调机制，以使他们的数据最终（是相对较长的“最终”）变得一致。为此也存在许多策略（超出了本文的范围）。
6总结处理重试似乎很复杂，那是因为它就是这么麻烦——和一切正常时Kafka相对优雅的风格相比之下尤其明显。我们构建的任何合适的解决方案（无论是重试主题、隐藏主题还是其他解决方案）都将比我们想要的更复杂。
不幸的是，如果我们希望在微服务之间建立弹性的异步通信流，那么我们就不能忽略它。
本文介绍了一种流行的解决方案、它的缺点以及在设计替代解决方案时应考虑的一些事项。到最后，想要构建正确的解决方案，我们就应该牢记一些事情，例如：
了解Kafka通过主题、分区和分区键提供的功能。
【你可能用错了 kafka 的重试机制】考虑到可恢复错误与不可恢复错误之间的差异。
设计模式的用法，例如有界上下文和聚合。
无论现在还是将来，都要搞清楚我们组织的用例特性。我们只是在移动独立的记录吗？……在这种情况下，我们可能不关心排序；还是说我们正在传播表示数据更改的事件？……在这种情况下，排序至关重要。
仔细考虑我们是否愿意承受任何水平的数据不一致。
参考资料：https://dzone.com/articles/creating-apache-kafka-topics-dynamically-as-part-ohttps://quarkus.io/blog/kafka-failure-strategy/https://eng.uber.com/reliable-reprocessing/https://jaceklaskowski.gitbooks.io/apache-kafka/content/kafka-topics.htmlhttps://www.red-gate.com/simple-talk/sql/bi/reconciling-data-across-systems-using-reconciliation-hub/原文链接：https://dt-23597.medium.com/if-youre-using-kafka-with-your-microservices-you-re-probably-handling-retries-wrong-8492890899fa今日好文推荐InfoQ读者交流群上线啦！各位小伙伴可以扫描下方二维码，添加InfoQ小助手，回复关键字“进群”申请入群。回复“资料” ，获取资料包传送门，注册InfoQ网站后，可以任意领取一门极客时间课程，免费滴！大家可以和InfoQ读者一起畅所欲言，和编辑们零距离接触，超值的技术礼包等你领取，还有超值活动等你参加，快来加入我们吧！