Note Cove

深浅模式

Kafka集群及副本的概念 ​

1.搭建kafka集群， 3 个broker ​

准备 3 个server.properties文件

每个文件中的这些内容要调整

  • server.properties
shell
broker.id= 0
listeners=PLAINTEXT://192.168.65.60:
log.dir=/usr/local/data/kafka-logs
  • server1.properties
shell
broker.id= 1
listeners=PLAINTEXT://192.168.65.60:
log.dir=/usr/local/data/kafka-logs-
  • server2.properties
shell
broker.id= 2
listeners=PLAINTEXT://192.168.65.60:
log.dir=/usr/local/data/kafka-logs-

使用如下命令来启动 3 台服务器 ​

shell
./kafka-server-start.sh -daemon../config/server0.properties
./kafka-server-start.sh -daemon../config/server1.properties
./kafka-server-start.sh -daemon../config/server2.properties

搭建完后通过查看zk中的/brokers/ids 看是否启动成功

2.副本的概念 ​

副本是对分区的备份。在集群中，不同的副本会被部署在不同的broker上。下面例子：创建 1个主题， 2 个分区、 3 个副本。

shell
./kafka-topics.sh --create --zookeeper 172.16.253.35:2181 --replication-factor 3 --partitions 2 --topic my-replicated-topic

输入图片说明

通过查看主题信息，其中的关键数据：

  • replicas：当前副本存在的broker节点
  • leader：副本里的概念
    • 每个partition都有一个broker作为leader。
    • 消息发送方要把消息发给哪个broker？就看副本的leader是在哪个broker上面。副本里的leader专⻔用来接收消息。
    • 接收到消息，其他follower通过poll的方式来同步数据。
  • follower：leader处理所有针对这个partition的读写请求，而follower被动复制leader，不提供读写（主要是为了保证多副本数据与消费的一致性），如果leader所在的broker挂掉，那么就会进行新leader的选举，至于怎么选，在之后的controller的概念中介绍。

通过kill掉leader后再查看主题情况

shell
# kill掉leader
ps -aux | grep server.properties
kill 17631
# 查看topic情况
./kafka-topics.sh --describe --zookeeper 172.16.253.35:2181 --topic my-replicated-topic

isr： 可以同步的broker节点和已同步的broker节点，存放在isr集合中。

3.broker、主题、分区、副本 ​

  • kafka集群中由多个broker组成
  • 一个broker中存放一个topic的不同partition——副本

输入图片说明

4.kafka集群消息的发送 ​

shell
./kafka-console-producer.sh --broker-list 172.16.253.38:9092,172.16.253.38:9093,172.16.253.38:9094 --topic my-replicated-topic

5.kafka集群消息的消费 ​

shell
./kafka-console-consumer.sh --bootstrap-server 172.16.253.38:9092,172.16.253.38:9093,172.16.253.38:9094 --from-beginning --topic my-replicated-topic

6.关于分区消费组消费者的细节 ​

输入图片说明

图中Kafka集群有两个broker，每个broker中有多个partition。一个partition只能被一个消费组里的某一个消费者消费，从而保证消费顺序。Kafka只在partition的范围内保证消息消费的局部顺序性，不能在同一个topic中的多个partition中保证总的消费顺序性。一个消费者可以消费多个partition。

消费组中消费者的数量不能比一个topic中的partition数量多，否则多出来的消费者消费不到消息。