大数据技术Kafka详解 ① | 消息队列（Messages Queue）

消息(Message)是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。消息队列(MessageQueue)是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。

2、消息队列的应用场景

消息队列在实际应用中包括如下四个场景：

1）应用耦合 ：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；
2）异步处理 ：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；
3）限流削峰 ：广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；
4）消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；

下面详细介绍上述四个场景以及消息队列如何在上述四个场景中使用。

2.1、应用耦合

具体场景：用户使用QQ相册上传一张图片，人脸识别系统会对该图片进行人脸识别，一般的做法是，服务器接收到图片后，图片上传系统立即调用人脸识别系统，调用完成后再返回成功，如下图所示：

该方法有如下缺点：

人脸识别系统被调失败，导致图片上传失败；

延迟高，需要人脸识别系统处理完成后，再返回给客户端，即使用户并不需要立即知道结果；

图片上传系统与人脸识别系统之间互相调用，需要做耦合；

若使用消息队列：

客户端上传图片后，图片上传系统将图片信息如uin、批次写入消息队列，直接返回成功；而人脸识别系统则定时从消息队列中取数据，完成对新增图片的识别。

此时图片上传系统并不需要关心人脸识别系统是否对这些图片信息的处理、以及何时对这些图片信息进行处理。事实上，由于用户并不需要立即知道人脸识别结果，人脸识别系统可以选择不同的调度策略，按照闲时、忙时、正常时间，对队列中的图片信息进行处理。

2.2、异步处理

具体场景：用户为了使用某个应用，进行注册，系统需要发送注册邮件并验证短信。对这两个操作的处理方式有两种：串行及并行。

串行方式：新注册信息生成后，先发送注册邮件，再发送验证短信。在这种方式下，需要最终发送验证短信后再返回给客户端。

并行处理：新注册信息写入后，由发短信和发邮件并行处理。在这种方式下，发短信和发邮件需处理完成后再返回给客户端。假设以上三个子系统处理的时间均为50ms，且不考虑网络延迟，则总的处理时间：

串行：50+50+50=150ms

并行：50+50=100ms

若使用消息队列：

在写入消息队列后立即返回成功给客户端，则总的响应时间依赖于写入消息队列的时间，而写入消息队列的时间本身是可以很快的，基本可以忽略不计，因此总的处理时间相比串行提高了2倍，相比并行提高了一倍。

2.3、限流削峰

具体场景：购物网站开展秒杀活动，一般由于瞬时访问量过大，服务器接收过大，会导致流量暴增，相关系统无法处理请求甚至崩溃。而加入消息队列后，系统可以从消息队列中取数据，相当于消息队列做了一次缓冲。

该方法有如下优点：

请求先入消息队列，而不是由业务处理系统直接处理，做了一次缓冲，极大地减少了业务处理系统的压力；

队列长度可以做限制，事实上，秒杀时，后入队列的用户无法秒杀到商品，这些请求可以直接被抛弃，返回活动已结束或商品已售完信息；

在这里，给大家重点推荐一下我的几个热门畅销专栏，欢迎订阅：（博客主页还有其他专栏，可以去查看）

专栏1： （该精品技术专栏的订阅量已达到560多个，专栏中包含大量项目实战分析案例，有很强的实战参考价值，广受好评！专栏文章持续更新中，预计更新到200篇以上！欢迎订阅！）

C++软件调试与异常排查从入门到精通系列文章汇总https://blog.csdn.net/chenlycly/article/details/125529931

本专栏根据多年C++软件异常排查的项目实践，系统地总结了引发C++软件异常的常见原因以及排查C++软件异常的常用思路与方法 ，详细讲述了C++软件的调试方法与手段，以图文并茂的方式给出具体的项目问题实战分析实例（很有实战参考价值），带领大家逐步掌握C++软件调试与异常排查的相关技术，适合基础进阶和想做技术提升的相关C++开发人员！

考察一个开发人员的水平，一是看其编码及设计能力，二是要看其软件调试能力 ！所以软件调试能力（排查软件异常的能力）很重要，必须重视起来！能解决一般人解决不了的问题，既能提升个人能力及价值，也能体现对团队及公司的贡献！

**专栏中的文章都是通过项目实战总结出来的，包含大量项目问题实战分析案例，有很强的实战参考价值！**专栏文章还在持续更新中，预计文章篇数能更新到200篇以上！

专栏2： （本专栏涵盖了C++多方面的内容，是当前重点打造的专栏，订阅量已达200多个，专栏文章已经更新到460多篇，持续更新中...）

C/C++实战进阶（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_11931267.html

以多年的开发实战为基础，总结并讲解一些的C/C++基础与项目实战进阶内容，以图文并茂的方式对相关知识点进行详细地展开与阐述！专栏涉及了C/C++领域多个方面的内容，包括C++基础及编程要点（模版泛型编程、STL容器及算法函数的使用等）、数据结构与算法、C++11及以上新特性（不仅看开源代码会用到，日常编码中也会用到部分新特性，面试时也会涉及到）、常用C++开源库的介绍与使用、代码分享（调用系统API、使用开源库）、常用编程技术（动态库、多线程、多进程、数据库及网络编程等）、软件UI编程（Win32/duilib/QT/MFC）、C++软件调试技术（排查软件异常的手段与方法、分析C++软件异常的基础知识、常用软件分析工具使用、实战问题分析案例等）、设计模式、网络基础知识与网络问题分析进阶内容等。

专栏3：

C++常用软件分析工具从入门到精通案例集锦汇总（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/article/details/131405795

常用的C++软件辅助分析工具有SPY++、PE工具、Dependency Walker、GDIView、Process Explorer、Process Monitor、API Monitor、Clumsy、Windbg、IDA Pro等，本专栏详细介绍如何使用这些工具去巧妙地分析和解决日常工作中遇到的问题，很有实战参考价值！

专栏4：

VC++常用功能开发汇总（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/article/details/124272585

将10多年C++开发实践中常用的功能，以高质量的代码展现出来。这些常用的高质量规范代码，可以直接拿到项目中使用，能有效地解决软件开发过程中遇到的问题。

专栏5：

C++ 软件开发从入门到精通（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_12695902.html

根据多年C++软件开发实践，详细地总结了C/C++软件开发相关技术实现细节，分享了大量的实战案例，很有实战参考价值。

2.4、消息驱动的系统

具体场景：用户新上传了一批照片，人脸识别系统需要对这个用户的所有照片进行聚类，聚类完成后由对账系统重新生成用户的人脸索引(加快查询)。这三个子系统间由消息队列连接起来，前一个阶段的处理结果放入队列中，后一个阶段从队列中获取消息继续处理。

该方法有如下优点：

避免了直接调用下一个系统导致当前系统失败；

每个子系统对于消息的处理方式可以更为灵活，可以选择收到消息时就处理，可以选择定时处理，也可以划分时间段按不同处理速度处理。

3、消息队列的两种模式

消息队列包括两种模式,点对点模式(pointtopoint, queue)和发布/订阅模式(publish/subscribe, topic)

3.1、点对点模式

点对点模式下包括三个角色：

消息队列

发送者(生产者)

接收者(消费者)

消息发送者生产消息发送到queue中，然后消息接收者从queue中取出并且消费消息。消息被消费以后，queue中不再有存储，所以消息接收者不可能消费到已经被消费的消息。

3.2、发布/订阅模式

发布/订阅模式下包括三个角色：

角色主题(Topic)

发布者(Publisher)

订阅者(Subscriber)

发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。

发布/订阅模式特点：

每个消息可以有多个订阅者。

发布者和订阅者之间有时间上的依赖性。针对某个主题(Topic)的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。

为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行；

4、常用的消息队列介绍

4.1、RabbitMQ

RabbitMQ于2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。关于RabbitMQ的详细介绍，可以查看我的文章：

深入详解高性能消息队列中间件 RabbitMQhttps://blog.csdn.net/chenlycly/article/details/140717778

4.2、ActiveMQ

ActiveMQ是由Apache出品，ActiveMQ是一个完全支持JMS1.1和J2EE1.4规范的JMSProvider实现。它非常快速，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。

4.3、RocketMQ

RocketMQ出自阿里公司的开源产品，用Java语言实现，在设计时参考了Kafka，并做出了自己的一些改进，消息可靠性上比Kafka更好。RocketMQ在阿里集团被广泛应用在订单、交易、充值、流计算、消息推送、日志流式处理等。

4.4、Kafka

ApacheKafka是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统(adistributedcommitlog)，之后成为Apache项目的一部分。Kafka系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。

4.5、Pulsar

ApahcePulasr是一个企业级的发布-订阅消息系统，最初是由雅虎开发，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。

Pulsar非常灵活：它既可以应用于像Kafka这样的分布式日志应用场景，也可以应用于像RabbitMQ这样的纯消息传递系统场景。它支持多种类型的订阅、多种交付保证、保留策略以及处理模式演变的方法，以及其他诸多特性。

Pulsar的特性

内置多租户：不同的团队可以使用相同的集群并将其隔离，解决了许多管理难题。它支持隔离、身份验证、授权和配额；

多层体系结构：Pulsar将所有topic数据存储在由ApacheBookKeeper支持的专业数据层中。存储和消息传递的分离解决了扩展、重新平衡和维护集群的许多问题。它还提高了可靠性，几乎不可能丢失数据。另外，在读取数据时可以直连BookKeeper，且不影响实时摄取。例如，可以使用Presto对topic执行SQL查询,类似于KSQL,但不会影响实时数据处理;

虚拟topic：由于采用n层体系结构，因此对topic的数量没有限制，topic及其存储是分离的。用户还可以创建非持久性topic；

N层存储：Kafka的一个问题是，存储费用可能变高。因此，它很少用于存储"冷"数据，并且消息经常被删除，ApachePulsar可以借助分层存储自动将旧数据卸载到AmazonS3或其他数据存储系统，并且仍然向客户端展示透明视图；Pulsar客户端可以从时间开始节点读取，就像所有消息都存在于日志中一样。

Pulsar存储架构

Pulsar的多层架构影响了存储数据的方式。Pulsar将topic分区划分为分片(segment),然后将这些分片存储在ApacheBookKeeper的存储节点上，以提高性能、可伸缩性和可用性。

Pulsar的无限分布式日志以分片为中心,借助扩展日志存储(通过ApacheBookKeeper)实现,内置分层存储支持，因此分片可以均匀地分布在存储节点上。由于与任一给定topic相关的数据都不会与特定存储节点进行捆绑，因此很容易替换存储节点或缩扩容。另外，集群中最小或最慢的节点也不会成为存储或带宽的短板。

Pulsar架构能实现分区管理，负载均衡，因此使用Pulsar能够快速扩展并达到高可用。这两点至关重要，所以Pulsar非常适合用来构建关键任务服务，如金融应用场景的计费平台，电子商务和零售商的交易处理系统，金融机构的实时风险控制系统等。

通过性能强大的Netty架构，数据从producers到broker，再到bookie的转移都是零拷贝，不会生成副本。这一特性对所有流应用场景都非常友好，因为数据直接通过网络或磁盘进行传输，没有任何性能损失。

Pulsar消息消费

Pulsar的消费模型采用了流拉取的方式。流拉取是长轮询的改进版，不仅实现了单个调用和请求之间的零等待，还可以提供双向消息流。通过流拉取模型，Pulsar实现了端到端的低延迟，这种低延迟比所有现有的长轮询消息系统(如Kafka)都低。

4.6、Kafka与Pulsar对比

Pulsar的主要优势：

更多功能:PulsarFunction、多租户、Schemaregistry、n层存储、多种消费模式和持久性模式等；

更大的灵活性：3种订阅类型(独占，共享和故障转移)，用户可以在一个订阅上管理多个topic；

易于操作运维：架构解耦和n层存储；

与Presto的SQL集成，可直接查询存储而不会影响broker；

借助n层自动存储选项，可以更低成本地存储。

Pulsar的劣势：

Pulsar并不完美,Pulsar也存在一些问题；

相对缺乏支持、文档和案例；

n层体系结构导致需要更多组件:BookKeeper；

插件和客户端相对Kafka较少；

云中的支持较少，Confluent具有托管云产品。

什么时候应该考虑Pulsar

同时需要像RabbitMQ这样的队列和Kafka这样的流处理程序；

需要易用的地理复制；

实现多租户，并确保每个团队的访问权限；

需要长时间保留消息，并且不想将其卸载到另一个存储中；

需要高性能，基准测试表明Pulsar提供了更低的延迟和更高的吞吐量。

总之，Pulsar还比较新，社区不完善，用的企业比较少，网上有价值的讨论和问题的解决比较少，远没有Kafka生态系统庞大，且用户量非常庞大，目前Kafka依旧是大数据领域消息队列的王者！所以我们还是以Kafka为主！