数栈产品分享：Kafka—实时离不开的那个TA

1、前言

随着技术不断的成熟及市场需求的日益旺盛，实时开发已经成为当前大数据开发不可或缺的一部分。在整个实时开发的链路中，数据采集须要写入到Kafka，数据处理也须要使用到Kafka。今天咱们就针对Kafka这个时下主流的消息中间件进行简单的介绍。

2、消息队列：数据流的归宿

在实时开发的场景中，来源于各种行为、事件的数据是随着发生时间源源不断如同河流通常进入实时任务并不断产出结果的。传统的异构数据源，数据以结构化的形式存储在对应的库表内。那么除了数据自己包含的业务时间属性，要如何找到一个稳定的时间维度来描述这些数据的前后呢？又要将流式的数据放在哪里去进行处理？

消息队列就是为了应对大量数据须要传递、分析场景所涉及的。

目前消息队列的方式分为如下两种：

• 点对点（point to point，queue）：消息被任一消费者消费后即消失在点对点系统中，消息被保留在队列中，一个或多个消费者能够消耗队列中的消息，可是特定消息只能由最多一个消费者消费，一旦消费者读取队列中的消息，它就从该队列中消失。
• 发布-订阅（publish/subscribe，topic）：消息可被全部订阅者（组）消费在发布-订阅系统中，消息生产者称为发布者，消息消费者称为订阅者。发布者发布的消息被保留在 Topic 中，与点对点系统不一样，消费组能够订阅一个或多个主题并使用该主题中的全部消息，一样，全部发布到Topic的消息都可被全部订阅组消费。一个订阅组内可能包含多个订阅者。

为了更好的理解消息队列的运做方式，咱们先设想以下一个场景：数据是一份快递，数据在不一样开发环节之间的流转就是快递的配送过程。

一、电视购物：上门配送，客户签收

在10年前电视购物还比较盛行的时代，多数货物是经过邮政等快递公司进行上门配送，每每快递员上门后，会让客户在运单上签字验收。这时候的快递员，只有每一份快递被客户签字验收后，才会再开始下一件货品的运输（此为极端状况下的举例）。

当一个客户存在多个快递，而且多个快递是陆续到达的时候，就会出现快递员配送-等待签收-客户签收-快递员回到收发点发现新的快递-快递员配送这样一个反复链路，若是存在客户反应慢，签字速度慢的状况，则会花费更多时间。

一样，在传统的数据开发场景中，数据传输也遵循这样的规律。上下游的两个服务之间对数据进行传输等同于快递配送的过程，若是一次数据传输须要等到下游服务给到的回执来保证数据正常写入，再开始下一次的进行，那么下游服务处理速度及响应速度会严重影响这一环节的数据从而致使数据延迟；若是整条数据传输的链路包含了多个这样的进程，总体数据的时效性就没法获得保证。

二、快递物流：统一快递站

随着网络购物的不断发展，为了提升效率，如今的货物配送方式发生了极大的改变。如今快递员从收发点拣货出发，将快递配送至相应地区的快递站，由快递站替实际用户进行一次代理签收，此时视做快递配送的过程已经完成。快递员就能够快速回到拣货点，后续快递站会以各种形式通知到具体的用户，有相应的快递须要签收，在“某某时间点”前来到快递点拿取。对于用户而言，它只须要持续关注快递站的状态（订阅），当有快递时，及时去取就能够。

当咱们熟悉了快递从仓库中存储到配送到收件人手中的流转过程时，咱们就可以理解消息中间件是如何在实时开发的过程当中运做的。那么在多种消息中间件中，目前应用最普遍的就属Apache Kafka。

3、Kafka：消息中间件

Apache Kafka是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，用于实时处理大量数据，经常使用于大数据，数据挖掘等场景。

Kafka中常常会涉及到以下基本概念：

• Zookeeper：用于将独立的Broker配置成Kafka集群；
• Broker：Kafka集群包含一个或多个服务器，这种服务器被称为Broker；
• Topic：Kafka中的消息主题，相似于Table的概念，用于区分不一样消息；
• Partition：Topic分区，每一个topic能够有多个分区，分区的做用是方便拓展，提升并发。

为了便于理解，咱们能够简单的将Kafka与快递过程进行类好比下：

一、数据写入

1）肯定Topic及Partition

一个Topic下可能存在多个Partition，在向Kafka写入数据时须要先肯定Topic及对应的Partition。

2）找到Partition通讯地址

因为Kafka实现了高可用，肯定写入Partition后，Producer会从ZK中获取到对应Partition的Leader并与其通讯。

3）数据传输

• Leader接收到Producer的信息并写入本地Log
• 其余Follower从Leader Pull信息，并写入本地log，完成后向Leader发送ACK
• Leader接收到全部Follower信息，并设置一个HW（High Watermark），而后向Producer发送ACK

二、消费方式及分配策略

实际消费数据时Kafka中的消费者——Consumer会以Consumer Group的形式与Topic交互并分配对应的Partition。在消费过程当中一个Group内的数据不重复，但多个Group之间的数据可重复消费，这也是发布-订阅制的特色。

开发人员能够利用这一特色实如今不影响主业务流程的状况下，对业务数据进行实时监控等。

一个Group中包含至少有一个Consumer，一个Topic下也至少包含一个Partiton。一个Consumer Group中的多个Consumer能够并行消费不一样的Partition，以此来提升对Kafka数据消费的并行度，从而提升数据处理的速度。可是在消费的过程当中，针对于Partition和Consumer数量的不一样，会出现各类状况，Kafka针对于不一样的状况有相应的分配策略，可参考以下：

4、实时开发如何使用Kafka

在实际生产中，实时开发也是以一个消费者组或生产者组的方式去Kafka中消费相应的数据。

在实时采集任务过程当中，采集数据源的数据到Kafka，经过设置不一样的写入并发数，能够设置多个Producer向同一个Topic下进行数据写入，提升并发度和数据读取效率；一样，当采集Kafka数据源时，经过设置不一样的读取并发数，能够在一个Group内设置多个Consumer同时对Topic内的数据进行消费。

在实时开发任务中，也能够设置Kafka数据源的并行度，从而根据实际业务需求调整并行度来知足消费需求。

5、结语

经过今天的介绍，咱们了解到Kafka做为典型“发布-订阅”形式的消息队列如何经过帮助用户临时存储流式数据，并经过Consumer Group和Partition的机制实现多并发的读写以提升实时开发相关的效率。后续咱们还会继续介绍跟实时开发相关的内容，敬请期待。

数栈是云原生—站式数据中台PaaS，咱们在github和gitee上有一个有趣的开源项目：FlinkX，FlinkX是一个基于Flink的批流统一的数据同步工具，既能够采集静态的数据，也能够采集实时变化的数据，是全域、异构、批流一体的数据同步引擎。你们喜欢的话请给咱们点个star！star！star！

github开源项目：https://github.com/DTStack/flinkx

gitee开源项目：https://gitee.com/dtstack_dev_0/flinkx