Kafka安装部署(Linux环境)

 Kafka 由 Scala 语言编写而成，编译之后的源代码就是普通的“.class”文件。本来部署到哪个操作系统应该都是一样的，但是不同操作系统的差异还是给 Kafka 集群带来了相当大的影响。目前常见的操作系统有 3 种：Linux、Windows 和 macOS。应该说部署在 Linux 上的生产环境是最多的，也有一些 Kafka 集群部署在 Windows 服务器上。
 如果考虑操作系统与 Kafka 的适配性，Linux 系统显然要比其他两个特别是 Windows 系统更加适合部署 Kafka。

一、环境准备

1.1 创建用户和用户组

useradd kafka  # 新建 kafka 用户
passwd kafka   # 修改 Kafka 用户的密码

1.2 环境变量

 为 kafka 用户配置 Kafka 环境变量。

vim ~/.bashrc

 将如下信息追加到文件末尾的新行中：

KAFKA_HOME=/usr/local/kafka
PATH=$PATH:$KAFKA_HOME/bin

 在通过键入:wq保存且退出后，一定要再通过执行下述命令使变更生效。

source ~/.bashrc

 Kafka 的 Broker 端完全是基于 Scala 编写的，

• JDK：建议版本在 1.7 及以上，否则可能会报如下错误：java.lang.UnsupportedClassVersionError
   极其不推荐将 Kafka 运行在 Java 6 或 7 的环境上，Java 6 实在太过陈旧了，没有理由不升级到更新版本。而 Kafka 自 2.0.0 版本开始，已经正式摒弃对 Java 7 的支持，所以本文使用的版本为 Java 8。
  （安装步骤略）

• ZooKeeper：Kafka 的安装包中自带 zookeeper，但建议另行部署一个 zookeeper 环境。
  （安装步骤略）

二、下载

下载地址:http://kafka.apache.org/downloads
本文下载的是当前最新的稳定版：kafka_2.13-2.7.0.tgz

三、安装配置

3.1 解压安装包

 将下载好的安装包 kafka_2.13-2.7.0.tgz 上传至 kafka 用户的主目录下，解压并移动到 /usr/local 目录下（不⼀定是 /usr/local ⽬录， 也可以是别的⽬录， 只是笔者⽐较喜欢把程序⽂件夹放到这个⽬录下， 把数据⽂件夹放到 /data ⽬录下⽽已。如果修改成其他目录，记得相应调整环境变量所指向的目录） 。
 注意：需使用 root 用户执行下述命令。

tar -zxf kafka_2.13-2.7.0.tgz          # 解压安装包
mv kafka_2.13-2.7.0 /usr/local/kafka   # 移动到指定⽬录，并更名
chown -R kafka:kafka /usr/local/kafka  # 变更程序所属⽤户及用户组

3.2 JVM 参数（可选）

 虽然 Kafka 的 Broker 端代码是用 Scala 语言编写的，但终归还是编译成 .class 文件在 JVM 上运行，因此 JVM 参数设置对于 Kafka 集群的重要性不言而喻。
 说到 JVM 端设置，堆大小这个参数至关重要。在此建议将 JVM 堆大小设置成 6GB 吧，这是目前业界比较公认的一个合理值。很多人直接使用默认的 Heap Size 来跑 Kafka，说实话默认的 1GB 有点小，毕竟 Kafka Broker 在与客户端进行交互时会在 JVM 堆上创建大量的 ByteBuffer 实例，Heap Size 不能太小。
 JVM 端配置的另一个重要参数就是垃圾回收器的设置，也就是平常说的 GC 设置。Java 8 环境下，建议就使用 G1 收集器。在没有任何调优的情况下，G1 表现得要比 CMS 出色，主要体现在更少的 Full GC，需要调整的参数更少等，所以使用 G1 就好了。
 现在确定好了要设置的 JVM 参数，我们只需要在配置环境变量时再追加下面两行即可：

export KAFKA_HEAP_OPTS='-Xms6g -Xmx6g'
export  KAFKA_JVM_PERFORMANCE_OPTS=' -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true'

3.3 参数配置

 主要的配置文件为 config/server.properties。

vim /usr/local/kafka/config/server.properties

3.3.1 通信

 若此 Broker 要与客户端程序或其它 Broker 进行通信，就需要为其指定通信协议、主机名和端口，对应的参数如下：

参数名	默认值	描述
listeners	null	声明外部连接 Kafka 服务的协议、主机名和端口
advertised.listeners	null	Broker 对外发布监听器的协议、主机名和端口
host.name,host.port		已过期参数，请勿使用

 从构成上来说，监听器是若干个逗号分隔的三元组，每个三元组的格式为 <协议名称://主机名:端口>。这里的协议名称可以是标准的名字，比如 PLAINTEXT 表示明文传输、SSL 表示使用 SSL 或 TLS 加密传输等；也可以是自定义的协议名字，比如 CONTROLLER://localhost:9092。

 一旦自定义了协议名称，就必须还要指定 listener.security.protocol.map 参数告诉这个协议底层使用了哪种安全协议，比如指定 listener.security.protocol.map = CONTROLLER:PLAINTEXT 表示 CONTROLLER 这个自定义协议底层使用明文不加密传输数据。

 至于三元组中的主机名和端口则比较直观，不需要做过多解释。不过有个事情还要注意一下：主机名这个设置中，到底使用 IP 地址还是主机名？这里给出统一的建议：最好全部使用主机名，即 Broker 端和 Client 端应用配置中全部填写主机名。因为 Broker 源码中使用的是主机名，如果你在某些地方使用了 IP 地址进行连接，可能会发生无法连接的问题。

3.3.2 Topic 管理（可选）

参数名	默认值	描述
auto.create.topics.enable	true	是否允许自动创建 Topic
unclean.leader.election.enable	false	是否允许 Unclean Leader 选举
auto.leader.rebalance.enable	true	是否允许定期进行 Leader 选举

• auto.create.topics.enable
   该参数值建议最好设置成 false，即不允许自动创建 Topic。在我们的线上环境里面有很多名字稀奇古怪的 Topic，大概都是因为该参数被设置成了 true 的缘故吧。
   你可能有这样的经历，要为名为 test 的 Topic 发送事件，但是不小心拼写错误了，把 test 写成了 tst，之后启动了生产者程序，恭喜你，一个名为 tst 的 Topic 就被自动创建了。
   所以好的运维应该防止这种情形的发生，特别是那些大公司而言，每个部门被分配的 Topic 应该由运维严格把控，绝不能允许自动创建任何 Topic。
• unclean.leader.election.enable
   关闭 Unclean Leader 选举。何谓 Unclean？Kafka 中每个分区都有多个副本来提供高可用。在这些副本中只能有一个副本对外提供服务，即所谓的 Leader 副本。那么所有的副本都有资格竞争 Leader 吗？显然不是，只有保存数据比较多的那些副本才有资格竞选，那些落后进度太多的副本没资格做这件事。
   好了，现在出现这种情况了：假设那些保证数据比较多的副本都挂了怎么办？我们还要不要进行 Leader 选举了？此时这个参数就派上用场了。
   如果设置成 false，那么就坚持之前的原则，坚决不能让那些落后太多的副本竞选 Leader。这样做的后果是这个分区就不可用了，因为没有 Leader 了。反之如果是 true，那么 Kafka 允许你从那些“跑的慢”的副本中选出一个来当 Leader。这样做的后果是数据有可能就丢失了，因为这些副本保存的数据本来就不全，当了 Leader 之后它本人就变得膨胀了，认为自己的数据才是权威的。
   这个参数在最新版的 Kafka 中默认就是 false，本来不需要特意提的，但社区对这个参数的默认值来来回回改了好几版，鉴于不清楚你用的是哪个版本的 Kafka，所以建议你还是显式地把它设置成 false 吧。
• auto.leader.rebalance.enable
   auto.leader.rebalance.enable 的影响貌似没什么人提，但其实对生产环境影响非常大。设置它的值为 true 表示允许 Kafka 定期地对一些 Topic 分区进行 Leader 重选举，当然这个重选举不是无脑进行的，它要满足一定的条件才会发生。严格来说它与上一个参数中 Leader 选举的最大不同在于，他不是选 Leader，而是换 Leader！比如 Leader A 一直表现的很好，但若 auto.leader.rebalance.enable=true，那么有可能一段时间后 Leader A 就要被强行卸任换成 Leader B。
   要知道换一次 Leader 代价很高的，原本向 A 发送请求的所有客户端都要切换成向 B 发送请求，而且这种换 Leader 本质上没有任何性能收益，因此建议在生产环境中把这个参数设置成 false。

3.3.3 数据存储地址信息（可选）

 生产者发往 Broker 的数据是需要在 Broker 端刷盘的，那么就需要为其指定使用哪些磁盘。那么针对存储信息的重要参数有以下两种：

参数名	默认值	描述
log.dirs	null	指定 Broker 需要使用的若干各文件目录
log.dir	/tmp/kafka-logs

 只需要设置 log.dirs 即可。重要的是，在生产环境中一定要为 log.dirs 配置多个路径，具体格式是一个 CSV 格式，也就是用逗号分隔的多个路径，比如：

log.dirs=/data/kafka1,/data/kafka2,/data/kafka3

 如果有条件话，最好保证这些目录挂载到不同的物理磁盘上，这样做有两个好处：

• 提升读写性能：比起单块磁盘，多块物理磁盘同时读写数据有更高的吞吐量。
• 能够实现故障转移：即 Failover。这是 1.1.0 版本引入的新功能，在这之前，只要 Kafka Broker 使用的任何一块磁盘挂掉了，整个 Broker 进程都会关闭。但是自 1.1.0 版本开始，这种情况被修正了，坏磁盘上的数据会自动转移到其他正常的磁盘上，而且 Broker 还能正常工作（舍弃 RAID 方案）。

3.3.4 数据留存（可选）

• log.retention.{hour|minutes|ms}
   这是个“三兄弟”，都是控制一条消息数据被保存多长时间。从优先级上来说 ms 设置最高、minutes 次之、hour 最低。
   虽然 ms 设置有最高的优先级，但是通常情况下我们还是设置 hour 级别的多一下，比如 log.retention.hour=168 表示默认保存 7 天前的数据。很多公司把 Kafka 当作存储来使用，那么这个值就要相应地调大。
• log.retention.bytes
   这是指定 Broker 为消息保存的总磁盘容量大小，默认值是 -1，表明你想在这台 Broker 上保存多少数据都可以，至少在容量方面 Broker 绝对为你开绿灯，不会做任何阻拦。这个参数真正发挥作用的场景其实是在云上构建多租户的 Kafka 集群：设想你要做一个云上的 Kafka 服务，每个租户只能使用 100GB 的磁盘空间，为了避免有个“恶意”租户使用过多的磁盘空间，设置这个参数就显得至关重要了。
• message.max.bytes
   控制 Broker 能够接收的最大消息大小。默认的 1000012B 太少了，还不到 1MB。实际场景中突破 1MB 的消息都是屡见不鲜的，因此在线上环境中设置一个比较大的值还是比较保险的做法。毕竟它只是一个标尺而已，仅仅衡量 Broker 能够处理的最大消息大小，即使设置大一点也不会耗费什么磁盘空间的。

3.3.5 连接 ZooKeeper

 Kafka 与 ZooKeeper 相关的最重要的参数当属 zookeeper.connect。这也是一个 CSV 格式的参数，比如可以指定它的值为 zk1:2181,zk2:2181,zk3:2181。2181 是 ZooKeeper 的默认端口。
 那么问题来了，如果要让多个 Kafka 集群使用同一套 ZooKeeper 集群，那么这个参数应该怎么设置呢？这时候 chroot 就派上用场了。这个 chroot 是个 ZooKeeper 的概念。类似于别名。

zookeeper.connect=zk1:2181,zk2:2181,zk3:2181/kafka

 如果你有两套 Kafka 集群，假设分别叫它们 kafka1 和 kafka2，那么两套集群的 zookeeper.connect 参数可以这样指定：zk1:2181,zk2:2181,zk3:2181/kafka1 和 zk1:2181,zk2:2181,zk3:2181/kafka2。

切记 chroot 只需要写一次，而且是加到最后的。zk1:2181/kafka1,zk2:2181/kafka2,zk3:2181/kafka3，这样的格式是错误的。

3.4 启动

 虽然我们已配置好了环境变量，但也仅是使 Kafka 的脚本能够单独使用，可启动 Kafka 需要为其制定配置文件，所有还是建议进入 Kafka 的主目录（/usr/local/kafka）下执行下述命令：

bin/kafka-server-start.sh config/server.properties

上述命令尽是启动 Kafka 服务，执行完后，依旧停留在 kafka 的控制台上，即不是后台启动。而 Kafka 提供了后台启动命令，即上述命令中添加 –daemon 指令，如下所示：

kafka-server-start.sh -daemon config/server.properties

 命名执行完后，可通过监看日志，获知启动情况：

tail -f /usr/local/kafka/logs/server.log

 从看到类似如下日志表示启动成功：

INFO Kafka version : 2.7.0 (org.apache.kafka.common.utils.AppInfoParser)
INFO Kafka commitId : aaa7af6d4a11b29d (org.apache.kafka.common.utils.AppInfoParser)
INFO [KafkaServer id=0] started (kafka.server.KafkaServer)

3.5 停止

kafka-server-stop.sh

四、集群部署

 Kafka 集群与单节点的部署配置几乎完全一致，不同之处在于需要把 config/server.properties 配置文件中仅多出如下步骤：

• 多节点
  在不同的物理机上都需要一份部署一个 Kafka server（若多个 server 部署在同一机器上，则称为：伪集群）。

• broker 编号
  配置文件中默认为 0，集群环境需要每个物理节点标识具有唯一性，即：若节点 A 为 broker.id=0 那么节点 B 为 broker.id=1，节点 C 为 broker.id=2

  broker.id 的取值范围非负的整数。