商用kafka集群硬盘要做raid吗 kafka集群作用

文章目录

• 一、Kafka的概述

• 1、为什么需要消息队列(MQ)
• 2、使用消息队列的好处

• （1）解耦
• （2）可恢复性
• （3）缓冲
• （4）灵活性、峰值处理能力
• （5）异步通信

• 3、消息队列的两种模式

• （1）点对点模式
• （2）发布/订阅模式

• 4、Kafka 的特性

• （1）高吞吐量、低延迟
• （2）可扩展性
• （3）持久性、可靠性
• （4）容错性
• （5）高并发

• 5、Kafka 系统架构

• （1）Broker
• （2）Topic
• （3）Partition
• （4） Leader
• （5）Follower
• （6）Replica
• （7）Producer
• （8）Consumer
• （9）Consumer Group (CG)
• （10）offset 偏移量
• （11）Zookeeper

• 二、kafka、zookeeper集群部署

• 1、下载kafka安装包
• 2、安装Kafka

• （1）、修改配置文件
• （2）、修改环境变量
• （3）、配置 kafka 启动脚本
• （4）、启动服务

• 3、Kafka 命令行操作

• （1）、创建topic
• （2）、查看当前服务器中的所有 topic
• （3）、查看某个 topic 的详情
• （4）、发布消息
• （5）、消费消息
• （6）、修改分区数
• （7）、删除 topic

• 三、Filebeat+Kafka+ELK部署

• 1.部署 Zookeeper+Kafka 集群
• 2.部署 Filebeat
• 3.部署 ELK，在 Logstash 组件所在节点上新建一个 Logstash 配置文件
• 4.访问测试

• 四、kafka架构

• 1、Kafka 工作流程及文件存储机制
• 2、数据可靠性保证
• 3、数据一致性问题

• （1）follower 故障
• （2）leader 故障

• 4、ack 应答机制

一、Kafka的概述

Kafka是一个分布式的基于发布/订阅模式的消息队列(MQ，MessageQueue)，主要应用于大数据实时处理领域。

Kafka是最初由Linkedin 公司开发，是一个分布式、支持分区的(partition) 、多副本的(replica) ，基于Zookeeper
协调的分布式消息中间件系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景，比如基于hadoop的批处理系统、低延迟的实时系统、Spark/Flink 流式处理引擎、nginx 访问日志，消息服务等等，用scala 语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

主要应用场景是：日志收集系统和消息系统。

Kafka主要设计目标如下：

• 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。
• 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。
• 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。
• 同时支持离线数据处理和实时数据处理。
• Scale out:支持在线水平扩展

---

1、为什么需要消息队列(MQ)

• 主要原因是由于在高并发环境下，同步请求来不及处理，请求往往会发生阻塞。比如大量的请求并发访问数据库，导致行锁表锁，最后请求线程会堆积过多，从而触发too many connection 错误，引发雪崩效应。
• 我们使用消息队列，通过异步处理请求，从而缓解系统的压力。消息队列常应用于异步处理，流量削峰，应用解耦，消息通讯等场景。
• 当前比较常见的MQ中间件有ActiveMQ、 RabbitMQ、 RocketMQ、 Kafka 等。

---

2、使用消息队列的好处

（1）解耦

• 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

（2）可恢复性

• 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使–个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

（3）缓冲

• 有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况

（4）灵活性、峰值处理能力

• 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

（5）异步通信

• 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

---

3、消息队列的两种模式

（1）点对点模式

• 一对一，消费者主动拉取数据，消息收到后消息清除
• 消息生产者生产消息发送到消息队列中，然后消息消费者从消息队列中取出并且消费消息。消息被消费以后，消息队列中不再有存储，所以消息消费者不可能消费到已经被消费的消息。消息队列支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

（2）发布/订阅模式

• 一对多，又叫观察者模式，消费者消费数据之后不会清除消息
• 消息生产者(发布)将消息发布到topic 中，同时有多个消息消费者(订阅)消费该消息。和点对点方式不同，发布到
  topic的消息会被所有订阅者消费。
• 发布/订阅模式是定义对象间一种一对多的依赖关系，使得每当一个对象(目标对象)的状态发生改变，则所有依赖于它的对象观察者对象)都会得到通知并自动更新。

---

4、Kafka 的特性

（1）高吞吐量、低延迟

• Kafka 每秒可以处理几十万条消息，它的延迟最低只有几毫秒。每个topic 可以分多个Partition, Consumer Group 对Partition进行消费操作，提高负载均衡能力和消费能力。

（2）可扩展性

• kafka 集群支持热扩展

（3）持久性、可靠性

• 消息被持久化到本地磁盘，并且支持数据备份防止数据丢失

（4）容错性

• 允许集群中节点失败(多副本情况下，若副本数量为n，则允许n-1个节点失败)

（5）高并发

• 支持数千个客户端同时读写

---

5、Kafka 系统架构

（1）Broker

• 一台kafka服务器就是一个broker。 一个集群由多个broker组成。一个broker 可以容纳多个topic。

（2）Topic

• 可以理解为一个队列，生产者和消费者面向的都是一-个topic
• 类似于数据库的表名或者ES的index
• 物理上不同topic 的消息分开存储

（3）Partition

• 为了实现扩展性，一个非常大的topic可以分布到多个broker (即服务器).上，一个topic可以分割为一个或多个partition， 每个partition是一个有序的队列。Kafka 只保证partition 内的记录是有序的，而不保证topic 中不同partition的顺序。
• 每个topic至少有一个partition，当生产者产生数据的时候，会根据分配策略选择分区，然后将消息追加到指定的分区的队列末尾。
• Partation数据路由规则：
           1.指定了patition，则直接使用

              2.未指定patition但指定key (相当于消息中某个属性),通过对key 的value 进行hash取模，选出一个patition

              3. patition和key都未指定，使用轮询选出一个patition

• 每条消息都会有一个自增的编号，用于标识消息的偏移量，标识顺序从0开始。
• 每个partition中的数据使用多个segment 文件存储。
• 如果topic有多个partition,消费数据时就不能保证数据的顺序。严格保证消息的消费顺序的场景下(例如商品秒杀、
  抢红包)，需要将partition 数目设为1。
• broker存储topic 的数据。如果某topic 有N个partition,集群有N个broker, 那么每个broker 存储该topic的一个partition。
• 如果某topic有N个partition， 集群有(N+M) 个broker,那么其中有N个broker存储topic 的一个partition,剩下的M个broker 不存储该topic 的partition数据。
• 如果某topic有N个partition，集群中broker 数目少于N个，那么一个broker 存储该topic 的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka 集群数据不均衡。
• 分区的原因：

            1、方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个
               Partition组成， 因此整集群就可以适应任意大小的数据了

            2、可以提高并发，因为可以以Partition为单位读写了。

（4） Leader

• 每个partition 有多个副本，其中有且仅有一一个作为Leader, Leader是当前负贵数据的读写的partition。

（5）Follower

• Follower跟随Leader,所有写请求都通过Leader 路由，数据变更会广:播给所有Follower, Follower 与Leader
  保持数据同步。Follower 只负责备份，不负责数据的读写。
• 如果Leader 故障，则从Follower 中选举出一个新的Leader。
• 当Follower 挂掉、卡住或者同步太慢，Leader 会把这个Follower 从ISR (Leader 维护的一个和Leader 保持同步的
  Follower集合)列表中删除， 重新创建一个 Follower。

（6）Replica

• 副本，为保证集群中的某个节点发生故障时，该节点上的partition 数据不丢失，且kafka 仍然能够继续工作，kafka
  提供了副本机制，一个topic的每个分区都有若干个副本，一个leader 和若千个follower。

（7）Producer

• 生产者即数据的发布者，该角色将消息发布到Kafka 的topic 中。
• broker接收到生产者发送的消息后，broker 将该消息追加到当前用于追加数据的segment文件中。
• 生产者发送的消息，存储到一个partition 中，生产者也可以指定数据存储的partition。

（8）Consumer

• 消费者可以从broker 中读取数据。消费者可以消费多个topic 中的数据。

（9）Consumer Group (CG)

• 消费者组，由多个consumer 组成。
• 所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。可为每个消费者指定组名，若不指定组名则属于默认的将多个消费者集中到一-起去处理某一个Topic的数据，可以更快的提高数据的消费能力。
• 消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费，防止数据被重复读取。
• 消费者组之间互不影响。

（10）offset 偏移量

• 可以唯一的标识一条消息。
• 偏移量决定读取数据的位置，不会有线程安全的问题，消费者通过偏移量来决定下次读取的消息(即消费位置)。
• 消息被消费之后，并不被马上删除，这样多个业务就可以重复使用Kafka 的消息。
• 某一个业务也可以通过修改偏移量达到重新读取消息的目的，偏移量由用户控制。
• 消息最终还是会被删除的，默认生命周期为1周(7*24小时) 。

（11）Zookeeper

• Kafka通过Zookeeper 来 存储集群的meta信息。
• 由于consumer在消费过程中可能会出现断电宕机等故障，consumer恢复后，需要从故障前的位置的继续消费，所以consumer需要实时记录自己消费到了哪个offset，以便故障恢复后继续消费。
• Kafka 0.9版本之前，consumer 默认将offset保存在Zookeeper 中;从0.9版本开始，consumer默认将offset 保存在Kafka 一个内置的topic中，该topic为_consumer_offsets。

---

二、kafka、zookeeper集群部署

1、下载kafka安装包

kafka软件包

官方下载地址http://kafka.apache.org/downloads.html

cd /opt
wget https://mirrors.tuna.tsinghua.edu.cn/apache/kafka/2.7.1/kafka_2.13-2.7.1.tgz

---

2、安装Kafka

cd /opt/
tar zxvf kafka_2.13-2.7.1.tgz
mv kafka_2.13-2.7.1 /usr/local/kafka

---

（1）、修改配置文件

cd /usr/local/kafka/config/
cp server.properties{,.bak}

vim server.properties

#21行，broker的全局唯一编号， 每个broker不能重复，因此要在其他机器上配置broker.id=1、broker.id=2
broker.id=0
#31行，指定监听的IP和端口，如果修改每个broker的IP需区分开来，也可保持默认配置不用修改
listeners=PLAINTEXT://192.168.8111.80:9092
#42行，broker 处理网络请求的线程数量，一般情况下不需要去修改
num.network.threads=3
#45行，用来处理磁盘I0的线程数量，最好配置成CPU核数的2倍，数值应该大于硬盘数
num.io.threads=8
#48行，发送套接字的缓冲区大小
socket.send.buffer.bytes=102400
#51行，接收套接字的缓冲区大小
socket.receive.buffer.bytes=102400
#54行，请求套接字的缓冲区大小
socket.request.max.bytes=104857600
#60行，kafka运行日志存放的路径，也是数据存放的路径
log.dirs=/usr/local/kafka/logs
#65行，topic在当前broker上的默认分区个数，会被topic创建时的指定参数覆盖
num.partitions=1
#69行，用来恢复和清理data下数据的线程数量
num.recovery.threads.per.data.dir=1
#103行，segment文件 (数据文件)保留的最长时间，单位为小时，默认为7天，超时将被删除
log.retention. hours=168
#110行，一个segment文件最大的大小，默认为1G，超出将新建一-个新的segment文件
log.segment.bytes=1073741824
#123行，配置连接Zookeeper集群地址
zookeeper.connect=192.168.111.80:2181, 192.168.111.90:2181, 192.168.111.100:2181

将修改好的配置文件复制到另外两台服务器上，修改borker.id和监听地址

---

（2）、修改环境变量

vim /etc/profile
export KAFKA_HOME=/usr/local/kafka 
export PATH=$PATH:$KAFKA_HOME/bin

source /etc/profile

---

（3）、配置 kafka 启动脚本

vim /etc/init.d/kafka
#!/bin/bash
#chkconfig:2345 22 88
#description:Kafka Service Control Script
KAFKA_HOME='/usr/local/kafka'
case $1 in
start)
	echo "---------- Kafka 启动 ------------"
	${KAFKA_HOME}/bin/kafka-server-start.sh -daemon ${KAFKA_HOME}/config/server.properties
;;
stop)
	echo "---------- Kafka 停止 ------------"
	${KAFKA_HOME}/bin/kafka-server-stop.sh
;;
restart)
	$0 stop
	$0 start
;;
status)
	echo "---------- Kafka 状态 ------------"
	count=$(ps -ef | grep kafka | egrep -cv "grep|$$")
	if [ "$count" -eq 0 ];then
        echo "kafka is not running"
    else
        echo "kafka is running"
    fi
;;
*)
    echo "Usage: $0 {start|stop|restart|status}"
esac

---

（4）、启动服务

//设置开机自启
chmod +x /etc/init.d/kafka
chkconfig --add kafka

//分别启动 Kafka
service kafka start

---

3、Kafka 命令行操作

（1）、创建topic

kafka-topics.sh --create --zookeeper 192.168.111.80:2181,192.168.111.90:2181,192.168.111.100:2181 --replication-factor 2 --partitions 3 --topic test

–zookeeper：定义 zookeeper 集群服务器地址，如果有多个 IP 地址使用逗号分割，一般使用一个 IP 即可
–replication-factor：定义分区副本数，1 代表单副本，建议为 2
–partitions：定义分区数
–topic：定义 topic 名称

---

（2）、查看当前服务器中的所有 topic

kafka-topics.sh --list --zookeeper 192.168.111.80:2181,192.168.111.90:2181,192.168.111.100:2181

---

（3）、查看某个 topic 的详情

kafka-topics.sh  --describe --zookeeper 192.168.111.80:2181,192.168.111.90:2181,192.168.111.100:2181

---

（4）、发布消息

kafka-console-producer.sh --broker-list 192.168.111.80:9092,192.168.111.90:9092,192.168.111.100:9092  --topic test

---

（5）、消费消息

kafka-console-consumer.sh --bootstrap-server 192.168.111.80:9092,192.168.111.90:9092,192.168.111.100:9092 --topic test --from-beginning

–from-beginning：会把主题中以往所有的数据都读取出来

---

（6）、修改分区数

kafka-topics.sh --zookeeper 192.168.111.80:2181,192.168.111.90:2181,192.168.111.100:2181 --alter --topic test --partitions 6

（7）、删除 topic

kafka-topics.sh --delete --zookeeper 192.168.111.80:2181,192.168.111.90:2181,192.168.111.100:2181 --topic test

三、Filebeat+Kafka+ELK部署

1、打开原来配置ELK的三台服务器，与配置的kafka一起配合使用
2、登录kibana，将原来的filebeat-*删除
3、然后进行对接

1.部署 Zookeeper+Kafka 集群

2.部署 Filebeat

cd /usr/local/filebeat

vim filebeat.yml

  paths:
    - /etc/httpd/logs/*_log
......
#添加输出到 Kafka 的配置
output.kafka:
  enabled: true
  hosts: ["192.168.111.80:9092","192.168.111.90:9092","192.168.111.100:9092"]    #指定 Kafka 集群配置
  topic: "filebeat_test"    #指定 Kafka 的 topic
  
#启动 filebeat
./filebeat -e -c filebeat.yml

---

3.部署 ELK，在 Logstash 组件所在节点上新建一个 Logstash 配置文件

cd /etc/logstash/conf.d/

vim filebeat.conf
input {
    kafka {
        bootstrap_servers => "192.168.111.80:9092,192.168.111.90:9092,192.168.111.100:9092"
        topics  => "filebeat_test"
        group_id => "test123"
        auto_offset_reset => "earliest"
    }
}

output {
    elasticsearch {
        hosts => ["192.168.111.30:9200"]
        index => "filebeat-%{+YYYY.MM.dd}"
    }
    stdout {
        codec => rubydebug
    }
}

#启动 logstash
logstash -f filebeat.conf

4.访问测试

浏览器访问 http://192.168.111.30:5601 登录 Kibana，单击“Create Index Pattern”按钮添加索引“filebeat-*”，单击 “create” 按钮创建，单击 “Discover” 按钮可查看图表信息及日志信息。

四、kafka架构

1、Kafka 工作流程及文件存储机制

• Kafka 中消息是以 topic 进行分类的，生产者生产消息，消费者消费消息，都是面向 topic 的。
• topic 是逻辑上的概念，而 partition 是物理上的概念，每个 partition 对应于一个 log 文件，该 log 文件中存储的就是 producer 生产的数据。Producer 生产的数据会被不断追加到该 log 文件末端，且每条数据都有自己的 offset。消费者组中的每个消费者，都会实时记录自己消费到了哪个 offset，以便出错恢复时，从上次的位置继续消费。
• 由于生产者生产的消息会不断追加到 log 文件末尾，为防止 log 文件过大导致数据定位效率低下，Kafka 采取了分片和索引机制，将每个 partition 分为多个 segment。每个 segment 对应两个文件：“.index” 文件和 “.log” 文件。这些文件位于一个文件夹下，该文件夹的命名规则为：topic名称+分区序号。例如，test 这个 topic 有三个分区， 则其对应的文件夹为 test-0、test-1、test-2。
• index 和 log 文件以当前 segment 的第一条消息的 offset 命名。
• “.index” 文件存储大量的索引信息，“.log” 文件存储大量的数据，索引文件中的元数据指向对应数据文件中 message 的物理偏移地址。

2、数据可靠性保证

• 为保证 producer 发送的数据，能可靠的发送到指定的 topic，topic 的每个 partition 收到 producer 发送的数据后， 都需要向 producer 发送 ack（acknowledgement 确认收到），如果 producer 收到 ack，就会进行下一轮的发送，否则重新发送数据。

3、数据一致性问题

• LEO：指的是每个副本最大的 offset；
• HW：指的是消费者能见到的最大的 offset，所有副本中最小的 LEO。

（1）follower 故障

• follower 发生故障后会被临时踢出 ISR（Leader 维护的一个和 Leader 保持同步的 Follower 集合），待该 follower 恢复后，follower 会读取本地磁盘记录的上次的 HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 leader 进行同步。等该 follower 的 LEO 大于等于该 Partition 的 HW，即 follower 追上 leader 之后，就可以重新加入 ISR 了。

（2）leader 故障

• leader 发生故障之后，会从 ISR 中选出一个新的 leader， 之后，为保证多个副本之间的数据一致性，其余的 follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 leader 同步数据。

注：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。

4、ack 应答机制

• 对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等 ISR 中的 follower 全部接收成功。所以 Kafka 为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡选择。
• 当 producer 向 leader 发送数据时，可以通过 request.required.acks 参数来设置数据可靠性的级别：
     0：这意味着producer无需等待来自broker的确认而继续发送下一批消息。这种情况下数据传输效率最高，但
      是数据可靠性确是最低的。当broker故障时有可能丢失数据。

    1（默认配置）：这意味着producer在ISR中的leader已成功收到的数据并得到确认后发送下一条message。如
            果在follower同步成功之前leader故障，那么将会丢失数据。

    -1（或者是all）：producer需要等待ISR中的所有follower都确认接收到数据后才算一次发送完成，可靠性最
            高。但是如果在 follower 同步完成后，broker 发送ack 之前，leader 发生故障，那么会造成数据重复。

• 三种机制性能依次递减，数据可靠性依次递增。

注：在 0.11 版本以前的Kafka，对此是无能为力的，只能保证数据不丢失，再在下游消费者对数据做全局去重。在 0.11 及以后版本的 Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指 Producer 不论向 Server 发送多少次重复数据， Server 端都只会持久化一条。