搭建Kafka数据传输服务集群(基本概念) - Part.1

2018-6-26 分类: 系统架构

这篇文章尚未完成,以后有时间再继续更新 ...

本来打算给这篇文章起名叫“搭建Kafka消息队列集群”,然而,和RabbitMQ不同,Kafka并没有实现消息队列的协议(例如AMQP,Advanced Message Queuing Protocol,提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计),所以尽管在使用方式上像极了队列,但并不算是严格意义上的消息队列。而按照官方的定义:A distributed streaming platform(分布式流数据平台),又显得太抽象,所以,我还是从实际出发,因为在项目中将Kafka用作一个数据传输和缓冲的中介,于是将标题命名为了“搭建Kafka数据传输服务集群”,关键词是:数据传输服务。

Kafka介绍

按照官方的定义,Kafka有下面三个主要作用:

  1. 发布&订阅:和其他消息系统一样,发布订阅流式数据。
  2. 处理:编写流处理应用程序,对实时事件进行响应。
  3. 存储:在一个分布式、容错的集群中安全地存储流式数据。

在我们的数据中心的项目应用中,主要是用作数据传输。为了看清楚它解决了一个什么问题,先简单介绍一下这个项目的场景:

这个项目的前端是各种应用,应用的数量未来可能有几十上百个,但目前只有10个。这些前端的应用要将数据发送到后端的数据中心(一个我们称为数据采集器的程序,简称采集器),很明显,采集器与应用是一对多的关系。这样就会出现这样一种情况:大部分的时间采集器器空闲,但是当多个应用同时发数据时,采集器又处理不过来。此时就需要一个缓冲机制,使得采集器不会太闲也不会太忙。我们选用了Kafka作为这个数据缓冲池,有时候也叫消息队列。

Kafka的重要概念

Broker(服务进程):Broker直译为代理。我觉得这个称谓不好理解,其实通俗讲就是运行kafka的服务器,再具体一点就是运行Kafka的服务进程。

Topic(主题):可以理解为一个数据的管道,在这个管道的一端生产消息/发布事件,另一端消费消息/响应事件。管道本身进行消息/事件的存储、路由、发送。

Producer(生产者):在数据管道一端 生产消息 的应用程序。

Consumer(消费者):在数据管道一端 消费消息 的应用程序。

Publisher(发布者):在数据管道一端 生成事件 的应用程序。

Subscriber(订阅者):在数据管道一端 响应事件 的应用程序。

生产者/消费者模式 和 发布者/订阅者 模式的区别

对于传统的消息队列中间件,例如RabbitMQ,来说,这两种模式之间的区别是很明显的(为了便于说明做了简化):

生产者/消费者 模式:

  1. 生产者将消息发送至队列,如果此时没有任何消费者连接队列、消费消息,那么消息将会保存在队列中,直到队列满或者有消费者上线。
  2. 生产者将消息发送至队列,如果此时有多个消费者连接队列,那么对于同一条消息而言,仅会发送至其中的某一个消费者。因此,当有多个消费者时,实际上就是一个天然的负载均衡。

发布者/订阅者 模式:

当使用 发布者/订阅者 模式时,发往队列的数据不叫消息,叫事件。对于数据的处理也不叫消费消息,叫事件订阅。

  1. 发布者发布事件,如果此时队列上没有连接任何订阅者,则此事件丢失,即没有任何应用程序对该事件作出响应。将来如果有订阅者上线,也不会重新收到该事件。
  2. 发布者发布事件,如果此时队列上连接了多个订阅者,则此事件会广播至所有的订阅者,每个订阅者都会收到完全相同的事件。所以不存在负载均衡

Kafka的二合一模式

Kafka使用群组(Group)的概念巧妙地实现了两种模式的二合一。

群组位于队列的消费端,一个主题可以有多个群组,一个群组内可以包含多个应用。对于群组内的应用来说,它们是生产者/消费者模式,一个消息只能被群组内的一个应用消费;对于不同的群组来说,它们是发布者/订阅者模式,同一个消息会被发送给所有的群组。

感谢阅读,希望这篇文章能给你带来帮助!