在我的理解中，我们可以使用Kafka消息，并根据消息信息触发异步工作流。
private consumer() {
request_info = kafka.getNextMessage()
trigger_async_workflow(request_info)
}我们将继续消耗和触发下游工作流程，一次一个：
while () {
consumer()
}但问题是，我们永远不知道trigger_async_workflow()需要多长时间才能完成，所以如果由于依赖性中断而花费了相当长的时间，每个消费者都会很慢，那么我们将遭受Kafka消费者滞后的痛苦。
另外，如果trigger_async_workflow()失败，一种方法是将消息发送到另一个延迟的主题，然后推回重试。
那么基本上如何最小化异步工作流不可预测性带来的潜在消费者滞后？还有其他更好的设计或提示吗？谢谢
2条答案
按热度按时间67up9zun1#
欢迎来到并发的世界，我的朋友。这是编程中最具挑战性的主题之一。在数据库世界中，有隔离级别（通常为4）和显式锁定。在JavaScript世界中，有一些处理异步代码的选项：
1.回调，允许您提供在异步方法运行结束后要调用的函数
你应该研究一个回调。本质上你需要识别依赖事件/函数和依赖事件/函数。另一种方式是认为这些是子函数和父函数。还有一种方式是认为这些是下游函数和上游函数。然后你只需在一个完成时放置一个回调。这是JavaScript锁定函数直到它可以安全运行的方式。
这对性能有好处吗？通常没有。然后发挥创造力。在数据库世界中，他们谈论使用特定隔离级别时可以防止的异常。阅读异常的类别以及哪些隔离级别可以避免哪些异常。在JavaScript中，您将遇到完全相同的异常！将JavaScript函数视为SQL事件（INSERT，UPDATE，DELETE）所以这是一个很好的框架，可以考虑您可能会遇到什么。
JavaScript回调是一个在另一个函数执行完毕后执行的函数。更正式的定义是-任何作为参数传递给另一个函数以便在该函数中执行的函数都被称为回调函数。
这很好地解释了这三种方法的视觉效果。
https://medium.com/@anny.huynh32/callbacks-vs-promises-vs-async-await-a66668d44c7b
xe55xuns2#
如果可能的话，更好的设计是让下游应用程序直接从Kafka中消费，而不是“在”它发出任何外部网络请求（而不是等待响应）。
否则，您需要等待/阻塞请求，这确实会导致时间延迟，但这是保证跟踪消息成功/失败的唯一方法，而不是“触发后就忘记”或“最多一次”记录传递