一文带您快速入门Kafka

作者 | 蔡柱梁,审校 | 重楼,Kafka 是使用 Scala 语言开发的一个多分区、多副本且基于 ZooKeeper 协调的分布式消息系统。目前，它的定位是一个分布式流式处理平台。,Kafka 在我们工作中最常扮演的三个角色：,Kafka 和传统的消息中间件一样具有系统解耦、冗余存储、流量削峰、异步通信等功能。,Kafka 会将消息持久化到磁盘，并且有多副本机制，有效降低了数据丢失的风险。有时，我们也可以使用它来存储数据，只需要把对应的数据保留策略设置成为“永久”即可。,Kafka 不仅为很多流式处理框架（如：Storm、Spark、Flink 等）提供了可靠的数据来源，还提供了一个完整的流式处理类库。,, 上图（图出自于《深入理解Kafka核心设计与实践原理》）体现了 Kafka 的整体架构，Producer 发送消息，Kafka 将元数据存储在 ZK 中并交由ZK 管理，Consumer 通过拉模式获取消息。,生产者，消息的投递方，负责创建消息并投递到 Kafka 中。,Kafka 服务实例,消费者，处理消息的一方 ,上面的概念都是物理层面上的，但是在实际使用过程中还有很多逻辑方面的定义，这些概念也是需要了解的。如果不了解，就算勉强写出了代码，但是自己还是一脸懵不知道自己都定义了什么，它们都有什么意义，估计离生产故障就不远了。,接下来我们再去了解三个重要的逻辑概念：, 生产者创建消息是要发送给特定的主题的，而消费者拉取消息也是要指定主题的。消息就是通过主题来归类的。, 一个Topic 可以有多个 Patition，而一个 Partition 只属于一个 Topic。同一个 Topic 下，不同 Partition 存储的消息是不同的。,Kafka 的消息是可以持久化并反复消费的，这是因为在每个分区中，当有消息写入就会像追加日志那样顺序写入（顺序IO的写入性能是十分好的），通过Offset 来记录对应消息所在的位置。因此，Offset 是消息在 Partition 中的唯一标识，并且能看出同一个 Partition 内的消息的先后顺序，我们称之为 “Kafka 保证消息在分区内是有序的”。,为了更好，更直观体现上面三者的关系，我们先一起看下图（图出自于《深入理解Kafka核心设计与实践原理》）,, 该图展示了一个拥有4个 Partition 的 Topic，而分区里面的阿拉伯数字就是 Offset（也表示着一条消息），虚线部分代表新消息可以插入的位置。每条消息在发送到 Broker 之前，会先计算当前消息应该发送到哪个 Partition。因此，只要我们设置合理，消息可以均匀地分配在不同的 Partition 上，当发现请求数量激增时，我们也可以考虑通过适当增加 Partition（Broker 也要增加）的方式，从而降低每个 Broker 的 I/O 压力。, 另外，为了降低消息丢失的风险，Kafka 为 Partition 引进了多副本（Replica）机制，通过增加副本数量来提高容灾能力。副本之间采用的是“一主多从”的设计，其中 Leader 负责读写请求，Follower 则仅负责同步 Leader 的消息（这种设计方式，大家应该要意识到会存在同步滞后的问题），并且副本处于不同的 Broker 中，当 Leader 出现故障（一般是因为其所在的 Broker 出现故障导致的）时，就从 Follower 中重新选举出新的 Leader 提供服务。当选出新的 Leader 并恢复服务后，Consumer 可以通过之前自己保存的 Offset 来继续拉取消息消费。, 结合到目前为止我们所知道的知识点，一起看下 4 个 Broker 的 Kafka 集群中，某一个 Topic 有三个 Partition，其副本因子为 3（副本因子为3就是每个 Partition 有 3 个副本，一个 Leader，两个 Follower）的架构图（图出自于《深入理解Kafka核心设计与实践原理》）。,, 在 1.1 小节中，我们已经知道一条消息只会存在一个 Partition中（只管 Leader，不管 Follower），而 Offset 则是消息在 Partition 中的唯一标识。而在本章节，我们将一起更深入地了解消息与 Partition 的关系，还有副本间同步数据所衍生的一些概念。, 上面有提到 Kafka 的多副本机制是 Leader 提供读写，而 Flower 是需要同步 Leader 的数据的，那么具体是怎样的呢？请看下图（单主题单分区3副本）：,,当Producer 不断往 Leader 写入消息时，Flower 会不断去 Leader 拉取消息，但是每台机器的性能会有出入，所以同步也有差异，正如上图这般。对于 Consumer 而言，只有 HW 之前的消息是可见可拉取消费的，这样做有个好处就是当发生故障转移时，Consumer 的 Offset 也不会发生数组越界的问题。这种做法是 Kafka 权衡利弊后给出的数据可靠性与性能平衡的方案，即不采取同步复制（性能差，对于高并发场景是灾难般的设计），也不采取异步复制（完全异步，数据丢失问题突出）。, 当然，对于Producer 而言就是消息丢失了，有时我们需要确保消息百分百投递，这样不就有问题了吗？不急，Kafka 可以在 Producer 的配置上配置 acks=-1 + min.insync.replicas=n（n 大于 1），这样配置后，只有消息被写入所有副本后，Kafka 服务端才会返回 ack 给 Producer。,下面来梳理下上面提及的几个概念：,它标识了Consumer 可以拉取消息的最高水位，客户端拉取的 Offset 必须小于 HW。,这个标记位标识下一条写入的消息应该存放的位置。,所有副本的统称,与Leader 保持一定程度同步的 Flower 集合。这个一定程度指的是在可容忍滞后范围内，这个可容忍范围可以通过配置修改。,同步滞后超过了容忍范围的Flower 集合。,这里仅以单节点为例，不配置集群。,在第一章节，我们知道 Kafka 会将元数据交由 ZK 管理，所以我们要先安装好 ZK。,1.首先检查自己的Linux 是否安装好了 yum 工具,,使用 yum 安装好 wget,2.下载 ZK,wget https://archive.apache.org/dist/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz,,,3.解压,4.为ZK 创建存放数据和日志的文件夹,
,,5.修改ZK 配置文件,,vi zoo.cfg,修改配置内容具体如下：,接着，到 /root/zookeeper-3.4.6/data 创建文件 myid（如果部署的是集群，那么这个 myid 必需唯一，不能重复）。,具体如下：,,6.配置环境变量,,再执行 source /etc/profile,至此，ZooKeeper 已经配置好了，我们可以启动看下是否有问题。,1.到官网下载安装包,,2.使用 psftp 上传到服务器,,,3.解压,
,4.修改配置,
,  由于 server.properties 比较大，就不全部贴上来了，只贴我修改的部分：,5.修改环境变量,再执行 source /etc/profile,6.进入bin目录，启动 Broker,ps -ef|grep kafka 看下进程，但是是否已经可以使用，要通过发送消息和消费消息来验证。,,下面是示例代码：,pom.xml,
,application.yml,application-dev.yml,logback.xml,ProducerDemo,ConsumerDemo,TestController,postman请求测试如下：,,控制台信息如下：,,蔡柱梁，51CTO社区编辑，从事Java后端开发8年，做过传统项目广电BOSS系统，后投身互联网电商，负责过订单，TMS，中间件等。