消息队列及kafka消息中间件

桃扇骨 2022-10-19 00:47 301阅读 0赞

分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击[http://www.captainbed.net][http_www.captainbed.net]

## **一、什么是消息队列** ##

**消息**指的是两个应用间传递的数据。数据的类型有很多种形式，可能只包含文本字符串，也可能包含嵌入对象。

**“消息队列(Message Queue)”是在消息的传输过程中保存消息的容器**。在消息队列中，通常有生产者和消费者两个角色。生产者只负责发送数据到消息队列，谁从消息队列中取出数据处理，他不管。消费者只负责从消息队列中取出数据处理，他不管这是谁发送的数据。

![0353b7f62c41be08951f3f88143d0c4b.png][]

## **二、为什么使用消息队列** ##

主要有三个作用：

*  **解耦**。如图所示。假设有系统B、C、D都需要系统A的数据，于是系统A调用三个方法发送数据到B、C、D。这时，系统D不需要了，那就需要在系统A把相关的代码删掉。假设这时有个新的系统E需要数据，这时系统A又要增加调用系统E的代码。为了降低这种强耦合，就可以使用MQ，**系统A只需要把数据发送到MQ，其他系统如果需要数据，则从MQ中获取即可**。

![ea0928668c60dab499d4794d9a13f4d2.png][]

*  异步。如图所示。一个客户端请求发送进来，系统A会调用系统B、C、D三个系统，同步请求的话，响应时间就是系统A、B、C、D的总和，也就是800ms。**如果使用MQ，系统A发送数据到MQ，然后就可以返回响应给客户端，不需要再等待系统B、C、D的响应，可以大大地提高性能**。对于一些非必要的业务，比如发送短信，发送邮件等等，就可以采用MQ。

![27eaccadbbac85f89515e741db9b3025.png][]

*  削峰。如图所示。这其实是MQ一个很重要的应用。假设系统A在某一段时间请求数暴增，有5000个请求发送过来，系统A这时就会发送5000条SQL进入MySQL进行执行，MySQL对于如此庞大的请求当然处理不过来，MySQL就会崩溃，导致系统瘫痪。**如果使用MQ，系统A不再是直接发送SQL到数据库，而是把数据发送到MQ，MQ短时间积压数据是可以接受的，然后由消费者每次拉取2000条进行处理，防止在请求峰值时期大量的请求直接发送到MySQL导致系统崩溃**。

## 三、kafka消息中间件 ##

Kafka 最早是由 LinkedIn 公司开发一种分布式的基于发布/订阅的消息系统，之后成为 Apache 的顶级项目。

> 我想分析一下用户行为（pageviews），以便我能设计出更好的广告位  
> 我想对用户的搜索关键词进行统计，分析出当前的流行趋势。这个很有意思，在经济学上有个长裙理论，就是说，如果长裙的销量高了，说明经济不景气了，因为姑娘们没钱买各种丝袜了。  
> 有些数据，我觉得存数据库浪费，直接存硬盘又怕到时候操作效率低。

这个时候，我们就可以用到分布式消息系统了。虽然上面的描述更偏向于一个日志系统，但确实kafka在实际应用中被大量的用于日志系统。

首先我们要明白什么是消息系统，在kafka官网上对kafka的定义叫：A distributed publish-subscribe messaging system。publish-subscribe是发布和订阅的意思，所以更准确的说kafka是一个消息订阅和发布的系统。publish-subscribe这个概念很重要，因为kafka的设计理念就可以从这里说起。

我们将消息的发布（publish）暂时称作producer，将消息的订阅（subscribe）表述为consumer，将中间的存储阵列称作broker，这样我们就可以大致描绘出这样一个场面：

![6f0520de48e57fb490db4942832b4f1c.png][]

## 结构图： ##

![f93991d7098412db2b7f691e7ff9b281.png][]

多个broker协同合作，producer和consumer部署在各个业务逻辑中被频繁的调用，三者通过zookeeper管理协调请求和转发。这样一个高性能的分布式消息发布与订阅系统就完成了。图上有个细节需要注意，producer到broker的过程是push，也就是有数据就推送到broker，而consumer到broker的过程是pull，是通过consumer主动去拉数据的，而不是broker把数据主动发送到consumer端的。

这样一个系统到底哪里体现出了它的高性能，如官网上所述，翻译如下：

> （1）数据在磁盘上存取代价为O(1)。一般数据在磁盘上是使用BTree存储的，存取代价为O（lgn）。  
> （2）高吞吐率。即使在普通的节点上每秒钟也能处理成百上千的message。  
> （3）显式分布式，即所有的producer、broker和consumer都会有多个，均为分布式的。  
> （4）支持数据并行加载到Hadoop中。

## 特性： ##

*  **同时为发布和订阅提供高吞吐量 。**Kafka 的设计目标是以时间复杂度为 O(1) 的方式提供消息持久化能力，即使对TB 级以上数据也能保证常数时间的访问性能。即使在非常廉价的商用机器上也能做到单机支持每秒 100K 条消息的传输。
 *  **消息持久化 **将消息持久化到磁盘，因此可用于批量消费，例如 ETL 以及实时应用程序。通过将数据持久化到硬盘以及 replication 防止数据丢失。
 *  **分布式 功能** 支持 Server 间的消息分区及分布式消费，同时保证每个 partition 内的消息顺序传输。这样易于向外扩展，所有的producer、broker 和 consumer 都会有多个，均为分布式的。无需停机即可扩展机器。
 *  **消费消息采用 pull 模式** 消息被处理的状态是在 consumer 端维护，而不是由 server 端维护，broker 无状态，consumer 自己保存 offset。

[http_www.captainbed.net]: http://www.captainbed.net/troubleshooter
[0353b7f62c41be08951f3f88143d0c4b.png]: /images/20221005/9d2a753f8621463190f423052d42a834.png
[ea0928668c60dab499d4794d9a13f4d2.png]: /images/20221005/bade58856da8461e9f07fcbf07d5bcbe.png
[27eaccadbbac85f89515e741db9b3025.png]: /images/20221005/77a023d2deb447fb98d365a89baec93b.png
[6f0520de48e57fb490db4942832b4f1c.png]: /images/20221005/972ef9a4555548c4b9fd6b497e111a5e.png
[f93991d7098412db2b7f691e7ff9b281.png]: /images/20221005/25f170ee77474c2690dd4f364f6b6de0.png