Centos_7.2 下构建 Kafka_2.13 分布式消息系统的单机版

如何在 Centos_7.2 下构建 Kafka_2.13 分布式消息系统的单例模式

一、前言
本文对于 kafka 分布式消息系统，是一个不错的入口点，首先从安装开始，这样就可以对 kafka 有一个基本的概念了，再了解 kafka 相关的基本概念就比较好理解些啦 ！！！
关于 Kafka：
Kafka 是一个分布式的、可分区的、可复制的消息系统。 Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。



二、安装
1、安装环境
Linux 版本： Centos-7.2
JDK 版本： JDK_1.8_Linux64bit
zookeeper 版本： zookeeper-3.5.3-beta
kafka 版本： kafka_2.12-1.0.0


2、安装 JDK
Kafka 安装时需要依赖 JDK，首先需要安装JDK


这儿有详细的安装图文教程：《Linux下Jdk1.8的安装与环境变量配置教程》



3、安装 zookeeper 
安装 Kafka 所需要依赖 zookeeper ，新版本的 Kafka 自带有 zookeeper，其实自带的 zookeeper 完全够用；
但是可能在有些实际生产环境中需要独立出来，便于分布部署等，使用 Apache 下的 zookeeper 。
这儿有详细的安装图文教程：《 Centos7下搭建Zookeeper集群分布式应用程序协调服务 》

如果你对 Apache 下 zookeeper 还不是很熟悉，建议从这儿开始： 《 Centos7 搭建单机版 Zookeeper 分布式应用程序协调服务 》



4、安装 Kafka
1）、下载 Kafka
《 kafka 分布式消息中间件 基于 Linux 的最新版 kafka_2.12-1.0.0 CSDN 下载 》



2）、下载完成后将 kafka 上传到 Linux 服务器，

并输入命令 “ tar -zxf kafka_2.12-1.0.0.tgz ” 进行解压，如下图：

3）、方便集中管理，将 kafka 复制到指定的目录，并重命名，

输入命令 “ cp kafka_2.12-1.0.0 /usr/local/single_kafka -r ”，如下图：

4）、修改 kafka 服务参数配置文件，进入到 kafka 配置文件目录，
输入命令 “ cd /usr/local/single_kafka/config ”，编辑 kafka 服务配置参数文件，
输入命令 “ vi server.properties ”，内容解释如下：

############################## 服务基础配置 #############################
# kafka 的代理id。必须为每个代理设置一个唯一的整数。
broker.id=0
############################## kafka 网络通信设置 #############################
# 服务器用于接收来自网络的请求的线程数量，并向网络发送响应
num.network.threads=3
# 服务器用于处理请求的线程数量，可能包括磁盘输入流/输出流
num.io.threads=8
# 服务器使用的发送缓冲区(SNDBUF)大小
socket.send.buffer.bytes=102400
# 服务器使用的接收缓冲区(即RCVBUF)大小
socket.receive.buffer.bytes=102400
# 服务器将接受的请求的最大大小
socket.request.max.bytes=104857600
############################# 日志基础配置 #############################
# 指定用来存储 kafka 日志文件目录
log.dirs=/home/temp/kafka_logs
# 默认的分区数，如果设置过多的分区进行平行消费，会导致产生 brokers
num.partitions=1
# 在启动时用于日志恢复和关闭时刷新的每个数据目录的线程数
num.recovery.threads.per.data.dir=1
############################# 日志保留策略 #############################
# 一个日志文件保留的最小时长（单位：小时）
log.retention.hours=168
# kafka 日志段文件的最大大小。当达到这个大小时，将创建一个新的日志段
log.segment.bytes=1073741824
# 检查 kafka 产生日志段的时间间隔时长，以确定是否可以删除这些日志段
log.retention.check.interval.ms=300000
############################# Zookeeper 配置 #############################
# 设置对应的 ZK 服务器，格式为 Host:Port ，当有多个 ZK 服务时，使用逗号隔开
zookeeper.connect=192.168.78.141:2181
# 连接到 zookeeper 最大超时时长（单位：毫秒）
zookeeper.connection.timeout.ms=6000
############################# kafka 的组织协调器设置 #############################
# 设置延迟初始化消费平衡（单位：毫秒），这里设置为 0 便于测试
# 在实际生产环境中设置为 3 秒为适，这样，应用程序在启动时，有效的避免了不必要的再平衡
group.initial.rebalance.delay.ms=0

以上为在实际生产环境中的一些具体描述。
在实际生产环境中，可以根据以上描述的实际需求进行更改，在这儿你可能只需要关注以下几项配置；


新增 kafka 的服务监听 IP 和 端口，示例内容如下：
host.name=192.168.78.141 # 新增本机的服务器 IP 地址
port=9092 # 这儿就写 配置中提供的默认的端口号

如下图：

修改 kafka 日志存放目录，示例内容如下：
log.dirs=/home/temp/kafka_logs

如下图：

修改 zookeeper IP 和 端口，这个是先前 zookeeper 服务配置好的，用于连接到 zookeeper 服务，千万不要大意，写错咯哟，示例内容如下：
zookeeper.connect=192.168.78.141:2181

如下图：

四、测试 Kafka 分布式消息中间件
测试 Kafka 单机版：
注意在新版 Kafka 分布式消息中间件中，自带了 zookeeper ，在这儿我使用两种 zookeeper 进行测试（独立/自带zookeeper)，关于这个独立/自带 zookeeper ，我个人觉得没啥区别，只是说使用独立 zookeeper 我们需要重新下载并配置，而自带的 zookeeper ，只需要稍做配置，即可进行使用，但我个人还是建议使用 < 独立 zookeeper >。
1、使用独立 zookeeper 进行 Kafka 单机环境测试

1）、启动独立 zookeeper ，进入到 zookeeper 的启动目录，输入命令 “ ./zkServer.sh start ”，如下图：

2）、启动 Kafka ，进入到 Kafka 的根目录，输入命令 “ bin/kafka-server-start.sh config/server.properties ”

启动成功后，查看 Kafka 进程，输入命令 “ ps aux|grep kafka ” ，只截取了一部分内容，如下图：

3）、创建一个测试主题 topic，先进入到 Kafka 的 bin 目录，

输入命令 “ ./kafka-topics.sh --create --zookeeper 192.168.78.141:2181 --replication-factor 1 --partitions 1 --topic msg ” ，如下图：

4）、查看所有创建的主题 topic，

输入命令 “ ./kafka-topics.sh --list --zookeeper 192.168.78.141:2181 ”，如下图：

5）、删除主题 topic，

输入命令 “ ./kafka-topics.sh --delete --zookeeper 192.168.78.141:2181 --topic huazai ”，如下图：

6）、使用 kafka producer 生产消息，
输入命令 “ ./kafka-console-producer.sh --broker-list 192.168.78.141:9092 --topic msg ”

并生产 5 条测试消息，如下图：

7）、使用 kafka consumer 消费消息，
输入命令 “ ./kafka-console-consumer.sh --zookeeper 192.168.78.141:2181 --topic msg --from-beginning ”

总共消费了 5 条消息，如下图：

8）、流程走完后，进入到 Kafka 的根目录，停止 Kafka 服务，输入命令 “ bin/kafka-server-stop.sh config/server.properties ”，

如下图：

9）、停止 zookeeper 服务，输入命令 “ ./zkServer.sh stop ” ，如下图：

2、使用自带 zookeeper 进行 Kafka 单机环境测试
1）、配置 Kafka 下的 zookeeper ，在 Kafka 的 /config 目录下，找到 zookeeper.properties 参数配置文件，
输入命令 “ vi zookeeper.properties ” ，
需要配置的内容：
注意：以下的端口不要冲突，这儿只是测试 zookeeper 用，直接在 Kafka 目录下创建数据目录/日志目录即可，在实际的生产环境中，使用外部的 zookeeper 服务；

# 存储快照文件snapshot的目录。默认情况下，事务日志也会存储在这里。    
# 建议同时配置参数dataLogDir, 事务日志的写性能直接影响zk性能。 
dataDir=/usr/local/single_kafka/zk_dir/zk_data 
# 在这个指定了日志的目录，日志存放在指定的日志目录中
dataLogDir=/usr/local/single_kafka/zk_dir/zk_logs
# 客户端连接server的端口，即对外服务端口，注意：不要与本地端口冲突了
clientPort=2181 

如下图：

2）、为了方便快速启动 Kafka 和 zookeeper 服务，编写启动脚本儿，
输入命令 “ vi kk_zk_start.sh ” 

键入如下内容：

#!/bin/bash
# start to zookeeper service
bin/zookeeper-server-start.sh config/zookeeper.properties &
# rest 6 seconds
sleep 6
# start to kafka service
bin/kafka-server-start.sh config/server.properties &

如下图：

运行脚本儿编写完成后，还需要授予可执行脚本儿的权限，输入命令“ chmod +x kk_zk_start.sh ”
运行脚本儿，输入命令 “ ./kk_zk_start.sh ” ，即可！！！


3）、编写 Kafka 和 zookeeper 服务的停止脚本儿，
输入命令 “ vi kk_zk_stop.sh ”
键入如下内容：

#!/bin/bash
# stop to zookeeper service
bin/zookeeper-server-stop.sh &
# rest 6 seconds
sleep 6
# stop to kafka service
bin/kafka-server-stop.sh &

如下图：

需要授予停止脚本儿可执行的权限，输入命令 “ chmod +x kk_zk_stop.sh ”
执行停止脚本儿，输入命令 “ ./kk_zk_stop.sh ”，即可停止服务！！！

三、需要了解的内容

1、基本概念

动态扩容：
动态扩容是绝大部分公司的硬性要求，如果不支持动态扩容就必须停止当前服务，大多关键系统都是不允许的，比如，12306 售票网站，在春运期间，需要升级系统服务，期间需要30分钟时间，如果停止服务，将带来灾难性的影响。
在 kafka 中很好的实现了服务的动态扩容，kafka 中的动态扩容是通过 zookeeper 来实现的。 


事物的概念：
在数据库中，多个操作一起提交，要么操作全部成功，要么全部失败。比如，在购买商品付款的时，付款和收款就是一个完整的事务，如果付款和收款都成功 ，这个事务才提交，有一动作失败，那么这个事务将回滚。 
那么消息在队列中，就是多条消息一起发送，要么全部成功，要么全部失败。
在 ActiveMQ、RabbitMQ、Kafka 中只有 ActiveMQ 支持事务，这个是因为 RabbitMQ 和 Kafka 为了更高的性能，而放弃了对事物的支持 。


集群的概念：
由多台服务器组成的整体叫做集群，这个整体对于生产者和消费者来说，是透明的。对消费系统组成的集群添加一台服务器或减少一台服务器对消息的生产系统和消费系统都是无感知的。
《 分布式与集群的区别？》


负载均衡的概念：
对于 kafka 消息系统来说，负载均衡就是应对大量的生产者和消费者向 kafka 消息系统发来的请求，系统必须均衡这些请求使得每一台服务器的请求达到平衡，而不是大量的请求落到某一台或其中几台服务器上，使得服务器出现高负荷或者超负荷工作，严重情况下会导致服务器异常停止或导致消息系统宕机情况。


高级消息队列协议（Advanced Message Queuing Protocol AMQP）：
AMQP是一个标准开放的应用层的消息中间件（Message Oriented Middleware）协议。AMQP 定义了通过网络发送的字节流的数据格式。因此兼容性非常好，任何实现 AMQP 协议的程序都可以和与 AMQP 协议兼容的其他程序交互，可以很容易做到跨语言，跨平台。



2、Kafka 基本架构：

这个架构图是参照官网画的，加点色彩总是好看些，这图画的有点累呀！！！

3、对 Kafka 动作理解
1）、消息的发布（publish）称作 producer，消息的订阅（subscribe）称作 consumer，中间的存储阵列称作 broker。 
2）、多个 broker 协同合作，producer、consumer 和 broker 三者之间通过 zookeeper 来协调请求和转发。 
3）、producer 产生和推送 (push) 数据到 broker，consumer 从 broker 拉取(pull)数据并进行处理。 
4）、broker 端不维护数据的消费状态，提升了性能。 
5）、直接使用磁盘进行存储，线性读写，速度快：避免了数据在JVM内存和系统内存之间的复制，减少了系统性能的消耗（创建的对象、垃圾的回收）。 
6）、Kafka 使用 scala语言 编写，可以运行在JVM上。 


4、Kafka 名词解释
Broker：Kafka集群包含一个或多个服务器，这种服务器被称为broker
Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）
Partition：Partition 是物理上的概念，每个Topic包含一个或多个Partition.（一般为kafka节点数cpu的总核数）
Producer：负责发布消息到Kafka broker
Consumer：消息消费者，向Kafka broker读取消息的客户端。
Consumer Group：每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。


5、Kafka 基本特点
可扩展
在不需要停止系统的情况下进行扩容；
数据流分区 (partition) 存储在多个机器上；
高性能
一个 broker 就能服务上千客户端；
一个 broker 的读/写 可达 秒/几百兆字节；
多个 broker 组成的集群将达到非常强的吞吐能力；
性能稳定，无论数据多大；
Kafka 在底层摒弃了 Java 堆缓存机制，采用了操作系统级别的页缓存，同时将随机写操作改为顺序写，再结合 Zero-Copy 的特性极大地改善了IO性能；
持久存储
存储在磁盘上；
冗余备份到其他服务器上以防止丢失；

6、对应关系

主题 topic ：
一个 topic 对应一种消息格式，因此消息用 topic 分类；
一个 topic 代表的消息由 1 个或者多个 patition 组成；

分区 partition ：
一个 partition 存放在一个或者多个 server 上，如果存放到一个 server 上，就没有冗余备份，是单机而不是集群，如果存放到多个 server 上，则会选举一个 server 作为 leader，其余 server 作为 follower ，而 leader 需要处理读/写的请求，follower 仅作冗余备份，当 leader 出现故障或者宕机时，系统会自动选举一个 follower 作为 leader，保证服务正常运行；每个 server 都可能扮演一些 partition 的 leader 和其它 partitions 的 follower 角色，这样整个集群就会达到负载均衡的效果，消息按顺序存放，顺序不可变；
只能追加消息，不能插入消息；

每个消息都有一个 offset，用作消息 ID, 在一个 partition 中唯一；
offset 由 consumer 保存和管理，因此读取顺序实际上是完全有 consumer 决定的，不一定是线性读取的；
消息有超时日期，过期消息则自动删除；



生产者 producer：
producer 负责将消息写入 kafka 消息队列；
写入时需要要指定 topic 和 partition；
消息如何分到不同的 partition，算法由 producer 决定；


消费者 consumer：
consumer 负责读取/处理 消息
consumer group 支持两种场景：
1、每条消息分发给一个消费者；
2、每条消息广播给消费组的所有消费者；
多个 consumer group 订阅一个 topic，该 topic 的消息广播给 group 内所有 consumer；
一条消息发送到一个 consumer group 后，只能由该 group 的一个 consumer 接收和使用；
一个 group 中的每个 consumer 对应一个 partition 可以带来如下好处：1）、可以按照 partition 的数目进行并发处理；2）、每个 partition 都只有一个 consumer 使用，因而保证了消息被处理的顺序是按照 partition 的存放顺序进行，注意这个顺序受到 producer 存放消息的算法影响；
一个 consumer 可以有多个线程进行消费，线程数应不多于 topic 的 partition 数，因为对于一个包含单个或多个消费线程的 consumer group 来说，一个 partition 只能分给其中的一个消费线程消费，且让尽可能多的线程能分配到 partition（不过实际上真正去消费的线程及线程数还是由线程池的调度机制来决定）。
这样如果线程数比 partition 数多，那么 topic 分配也会有多出的线程，它们就不会消费到任何一个 partition 中的数据而浪费了系统资源。
如果 consumer 从多个 partition 上读到数据，那么不能保证该数据的顺序性，kafka 只保证在同一个 partition 上读取的数据是有序的。
新增或减少 consumer、broker、partition 会导致 rebalance，所以 rebalance 后 consumer 对应的 partition 会发生变化。


标注：
Zookeeper 分布式应用程序协调服务在分布式系统下的应用：分布式状态管理、分布式协调管理、分布式配置管理以及分布式锁服务的集群服务。
kafka 增加和减少服务器都会在 Zookeeper 节点上触发相应的事件，同时 kafka 系统也会捕获这些事件，进行新一轮的再平衡（rebalance），客户端也会捕获这些事件来进行新一轮的处理工作。


7、kafka支持的客户端语言：
Kafka 客户端支持语言包括：C、C++、Erlang、Java、.net、perl、PHP、Python、Ruby、Go、Javascript。
可以使用其中任意一种语言和kafka服务器进行通信（查阅官方 API 可以很轻松的实现 Producer/Consumer 程序）。

好了，关于 zookeeper 集群环境的搭建就到此结束了，如果还有什么疑问或遇到什么问题，可以给我留言。
歇后语：“共同学习，共同进步”，也希望大家多多关注CSND的IT社区。