如何分析Kafka和消息队列之间的超快速比较

如何分析Kafka和消息队列之间的超快速比较，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

Kafka最初是由Linkedin社区开发的一项技术。简而言之，它有点像消息队列系统，但它与消息队列系统不同的就是它能够支持pub/sub，可以在许多服务器上进行扩展，并重新播放消息。

平时你可能不太关注这些问题，但是当你想要采用响应式编程风格而不是命令式编程风格时，上述这些就是你需要进行关注的了。

命令式编程和响应式编程之间的区别

命令式编程是我们一开始就采用的编程类型。当发生了一些事情，换句话说，事件发生了，然后你的代码被告知发生了该事件。例如，用户单击一个按钮，你在代码中处理这个事件的地方，就决定了你希望系统接下来触发哪些动作。您可以将记录保存到数据库中，调用另一个服务，发送电子邮件，或者将这些动作组合在一起。这里最重要一点是，事件是与这些具体发生的动作是直接耦合的。

响应式编程使用户能够响应发生的事件，通常以流的形式出现。多个关注点可以订阅相同的事件，并让事件在它的域中产生影响，而不管其他域发生了什么。换句话说，它支持松散耦合的代码，可以很容易地扩展到更多的功能。有可能在不同的栈中编码的各种大的下流系统会受到事件的影响，甚至是在云的某个地方执行的一大堆没有服务器的函数。

从消息队列到Kafka

为了理解Kafka会给你的架构带来什么，让我们先谈论一下消息队列。我们之所以从消息队列开始，是因为我们将讨论它的局限性，然后看看Kafka是如何解决这些问题的。

消息队列允许一组订阅者从队列的末尾提取一条或多条消息。在消息被移除之前，队列通常允许执行某些级别的事务，以确保在消息被删除之前执行所需的操作。

并不是所有的队列系统都具有相同的功能，但是一旦消息被处理了，就会从队列中删除掉。如果你仔细想想，它其实与命令式编程非常类似，首先得发生一些事情，然后起始系统决定在下游系统中应该执行哪些操作。

尽管可以在队列中扩展多个消费者，但它们都包含相同的功能，而这只是为了处理负载和并行处理消息，换句话说，它不允许你基于相同的事件启动多个独立的操作。队列消息的所有处理器将在相同的域中执行相同类型的逻辑。这意味着队列中的消息实际上是命令，它适合于命令式编程，而不是一个适合于响应式编程的事件。

对于队列，通常在相同的域中为队列中的每个消息执行相同的逻辑

另一方面，使用Kafka，你可以将消息/事件发布到主题上，它们会被持久化。当消费者收到这些消息时，他们也不会被移除掉。这允许你重放消息，但更重要的是，它允许大量的消费者基于相同的消息/事件处理各自不同逻辑。

你仍然可以在相同的域中进行并行处理，但是更重要的是，你还可以添加不同类型的消费者，这些消费者基于相同的事件执行不同的逻辑。换句话说，对于Kafka，用户可以采用一个被动的pub/sub体系结构。

不同的逻辑可以由不同的系统基于相同的事件来执行

在使用Kafka的情况下，这是可能的，因为信息是保留的，消费者群体的概念也是如此。Kafka的消费者团体在向Kafka询问关于某个话题的信息时，将自己定位于Kafka。Kafka将会记录哪些消息(偏移量)被传送到哪个消费者组，这样它就不会再为它服务了。实际上，它比这要复杂一些，因为您有许多可用的配置选项来控制这一点，但是我们不需要全面地探索这些选项，只是为了在高层次上理解Kafka。

关于如何分析Kafka和消息队列之间的超快速比较问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注亿速云行业资讯频道了解更多相关知识。