Linux工作记录（kafka安装相关问题）

最新推荐文章于 2023-12-16 11:33:46 发布

我说了算不算

最新推荐文章于 2023-12-16 11:33:46 发布

阅读量792

点赞数

文章标签： kafka linux

本文链接：https://blog.csdn.net/kaisen369/article/details/126514424

版权

（1）使用场景

日志收集：一个公司可以用Kafka收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。
消息系统：解耦和生产者和消费者、缓存消息等。
用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。

（2）kafka相关概念

Broker：消息中间件处理节点，一个Kafka节点就是一个broker，一个或者多个Broker可以组成一个Kafka集群
Topic：Kafka根据topic对消息进行归类，发布到Kafka集群的每条消息都需要指定一个topic
Producer：消息生产者，向Broker发送消息的客户端
Consumer：消息消费者，从Broker读取消息的客户端
ConsumerGroup：每个Consumer属于一个特定的Consumer Group，一条消息可以被多个不同的Consumer Group消费，但是一个Consumer Group中只能有一个Consumer能够消费该消息
Partition：物理上的概念，一个topic可以分为多个partition，每个partition内部消息是有序的

（3）linux安装kafka步骤

第一步：wget https://mirror.bit.edu.cn/apache/zookeeper/zookeeper‐3.5.8/apache‐zookeeper‐3.5.8‐bin.tar.gz
第二步：tar ‐zxvf apache‐zookeeper‐3.5.8‐bin.tar.gz
第三步：安装kafka
 wget https://mirror.bit.edu.cn/apache/kafka/2.4.1/kafka_2.11‐2.4.1.tgz 
1 # 2.11是scala的版本，2.4.1是kafka的版本
2 tar ‐xzf kafka_2.11‐2.4.1.tgz
3 cd kafka_2.11‐2.4.1
第四步：修改配置文件
修改配置文件config/server.properties:
#broker.id属性在kafka集群中必须要是唯一
broker.id=0
#kafka部署的机器ip和提供服务的端口号
listeners=PLAINTEXT://192.168.65.60:9092
#kafka的消息存储文件
log.dirs=/usr/local/kafka/data/kafka-logs
#kafka连接zookeeper的地址
zookeeper.connect=192.168.1.60:2181,192.168.1.61:2181,192.168.1.62:2181

第五步：启动kafka：
启动kafka，运行日志在logs目录的server.log文件里
bin/kafka-server-start.sh ‐daemon config/server.properties #后台启动，不会打印日志到控制台
或者用
bin/kafka-server-start.sh config/server.properties &

我们进入zookeeper目录通过zookeeper客户端查看下zookeeper的目录树
bin/zkCli.sh
ls / #查看zk的根目录kafka相关节点
ls /brokers/ids #查看kafka节点

停止kafka
bin/kafka-server-stop.sh


第六步：创建主题：
bin/kafka‐topics.sh ‐‐create ‐‐zookeeper 192.168.1.60:2181 ‐‐replication‐factor 1 ‐‐partitions 1 ‐‐topic test
查看存在的topic：
 bin/kafka‐topics.sh ‐‐list ‐‐zookeeper 192.168.1.60:2181
删除主题：
bin/kafka‐topics.sh ‐‐delete ‐‐topic test ‐‐zookeeper 192.168.1.60:2181

（4）单播和多播

（1）单播消息
一条消息只能被某一个消费者消费的模式，类似queue模式，只需让所有消费者在同一个消费组里即可（同一条消息，在同一个消费组里面，只能被消费一次）
（2）多播消费
一条消息能被多个消费者消费的模式，类似publish-subscribe模式费，针对Kafka同一条消息只能被同一个消费组下的某一个消费者消费的特性，要实现多播只要保证这些消费者属于不同的消费组即可。

（5）分区相关问题

Partition是一个有序的message序列，这些message按顺序添加到一个叫做commit log的文件中。每个partition中的消息都有一个唯一的编号，称之为offset，用来唯一标示某个分区中的message。
每个partition，都对应一个commit log文件。一个partition中的message的offset都是唯一的，但是不同的partition中的message的offset可能是相同的。
kafka一般不会删除消息，不管这些消息有没有被消费。只会根据配置的日志保留时间(log.retention.hours)确认消息多久被删除，默认保留最近一周的日志消息。kafka的性能与保留的消息数据量大小没有关系，因此保存大量的数据消息日志信息不会有什么影响。

消费offset由consumer自己来维护；一般情况下我们按照顺序逐条消费commit log中的消息，当然我可以通过指定offset来重复消费某些消息，或者跳过某些消息。
这意味kafka中的consumer对集群的影响是非常小的，添加一个或者减少一个consumer，对于集群或者其他consumer
来说，都是没有影响的，因为每个consumer维护各自的消费offset。

每个分区都有自己的副本

目前kafka支持增加分区，不支持减少

为什么要对Topic下数据进行分区存储？
1、commit log文件会受到所在机器的文件系统大小的限制，分区之后可以将不同的分区放在不同的机器上，相当于对
数据做了分布式存储，理论上一个topic可以处理任意数量的数据。
2、为了提高并行度。

（6）顺序消费问题

一个partition同一个时刻在一个consumer group中只能有一个consumer instance在消费，从而保证消费顺序。
consumer group中的consumer instance的数量不能比一个Topic中的partition的数量多，否则，多出来的
consumer消费不到消息。
Kafka只在partition的范围内保证消息消费的局部顺序性，不能在同一个topic中的多个partition中保证总的消费顺序性。
如果有在总体上保证消费顺序的需求，那么我们可以通过将topic的partition数量设置为1，将consumer group中的
consumer instance数量也设置为1，但是这样会影响性能，所以kafka的顺序消费很少用。

（7）kafka设计原理

Kafka核心总控制器Controller
在Kafka集群中会有一个或者多个broker，其中有一个broker会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态。
当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。
当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。
当使用kafka-topics.sh脚本为某个topic增加分区数量时，同样还是由控制器负责让新分区被其他节点感知
到。

Controller选举机制
在kafka集群启动的时候，会自动选举一台broker作为controller来管理整个集群，选举的过程是集群中每个broker都会尝试在zookeeper上创建一个 /controller 临时节点，zookeeper会保证有且仅有一个broker能创建成功，这个broker就会成为集群的总控器controller。
当这个controller角色的broker宕机了，此时zookeeper临时节点会消失，集群里其他broker会一直监听这个临时节点，发现临时节点消失了，就竞争再次创建临时节点，就是我们上面说的选举机制，zookeeper又会保证有一个broker
成为新的controller。

消费者Rebalance机制
如下情况可能会触发消费者rebalance
1. 消费组里的consumer增加或减少了
2. 动态给topic增加了分区
3. 消费组订阅了更多的topic
rebalance过程中，消费者无法从kafka消费消息，这对kafka的TPS会有影响，如果kafka集群内节点较多，比如数百
个，那重平衡可能会耗时极多，所以应尽量避免在系统高峰期的重平衡发生。

生产者发送消息流程
1. producer 先从 zookeeper 的 "/brokers/.../state" 节点找到该 partition 的 leader
2. producer 将消息发送给该 leader
3. leader 将消息写入本地 log
4. followers 从 leader pull 消息，写入本地 log 后 向leader 发送 ACK
5. leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向producer 发送 ACK