【Kafka】大数据实时框架_kafka

大数据实时框架_kafka

https://www.orchome.com/kafka/index kafka中文教程

1. 消息队列的介绍

​ 消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。

​ 消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在

1.1 常见的消息队列产品

• 1. RabbitMQ

  ​ RabbitMQ 2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

• 2. activeMQ:

  ​ ActiveMQ是由Apache出品，ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现。它非常快速，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能,目前市场的活跃度比较低, 在java领域正在被RabbitMQ替代

• 3. RocketMQ

  ​ RocketMQ出自 阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更好。RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理等

• 4. kafka

  ​ Apache Kafka是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log)，之后成为Apache项目的一部分。Kafka系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。

---

各种消息队列产品的对比图:

1.2 消息队列的应用场景

消息队列在实际应用中包括如下四个场景：

• 1. 应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；
• 2. 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；
• 3. 限流削峰：广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；
• 4. 消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理

下面详细介绍上述四个场景以及消息队列如何在上述四个场景中使用

1.2.1 异步处理

​ 具体场景：用户为了使用某个应用，进行注册，系统需要发送注册邮件并验证短信。对这两个操作的处理方式有两种：串行及并行。

• 1）串行方式：新注册信息生成后，先发送注册邮件，再发送验证短信；

  

  在这种方式下，需要最终发送验证短信后再返回给客户端

• 2. 并行处理：新注册信息写入后，由发短信和发邮件并行处理

  

  在这种方式下，发短信和发邮件 需处理完成后再返回给客户端。

---

假设以上三个子系统处理的时间均为50ms，且不考虑网络延迟，则总的处理时间：

​ 串行：50+50+50=150ms
​ 并行：50+50 = 100ms

如果引入消息队列, 在来看整体的执行效率:

​ 在写入消息队列后立即返回成功给客户端，则总的响应时间依赖于写入消息队列的时间，而写入消息队列的时间本身是可以很快的，基本可以忽略不计，因此总的处理时间相比串行提高了2倍，相比并行提高了一倍；

1.2.2 应用耦合

​ 具体场景：用户使用QQ相册上传一张图片，人脸识别系统会对该图片进行人脸识别，一般的做法是，服务器接收到图片后，图片上传系统立即调用人脸识别系统，调用完成后再返回成功，如下图所示:

该方法有如下缺点:

1) 人脸识别系统被调失败，导致图片上传失败；
2) 延迟高，需要人脸识别系统处理完成后，再返回给客户端，即使用户并不需要立即知道结果；
3) 图片上传系统与人脸识别系统之间互相调用，需要做耦合；

若使用消息队列:

​ 客户端上传图片后，图片上传系统将图片信息如uin、批次写入消息队列，直接返回成功；而人脸识别系统则定时从消息队列中取数据，完成对新增图片的识别。
​ 此时图片上传系统并不需要关心人脸识别系统是否对这些图片信息的处理、以及何时对这些图片信息进行处理。事实上，由于用户并不需要立即知道人脸识别结果，人脸识别系统可以选择不同的调度策略，按照闲时、忙时、正常时间，对队列中的图片信息进行处理。

1.2.3 限流削峰

​ 具体场景：购物网站开展秒杀活动，一般由于瞬时访问量过大，服务器接收过大，会导致流量暴增，相关系统无法处理请求甚至崩溃。而加入消息队列后，系统可以从消息队列中取数据，相当于消息队列做了一次缓冲。

该方法有如下优点：

​ 请求先入消息队列，而不是由业务处理系统直接处理，做了一次缓冲,极大地减少了业务处理系统的压力；

​ 队列长度可以做限制，事实上，秒杀时，后入队列的用户无法秒杀到商品，这些请求可以直接被抛弃，返回活动已结束或商品已售完信息；

1.2.4 消息驱动的系统

​ 具体场景：用户新上传了一批照片， 人脸识别系统需要对这个用户的所有照片进行聚类，聚类完成后由对账系统重新生成用户的人脸索引(加快查询)。这三个子系统间由消息队列连接起来，前一个阶段的处理结果放入队列中，后一个阶段从队列中获取消息继续处理。

该方法有如下优点：

​ 避免了直接调用下一个系统导致当前系统失败；

​ 每个子系统对于消息的处理方式可以更为灵活，可以选择收到消息时就处理，可以选择定时处理，也可以划分时间段按不同处理速度处理；

1.3 消息队列的两种模式

​ 消息队列包括两种模式，点对点模式（point to point， queue）和发布/订阅模式（publish/subscribe，topic）

1.3.1 点对点模式

点对点模式下包括三个角色

• 消息队列

• 发送者 (生产者)

• 接收者（消费者）

​ 消息发送者生产消息发送到queue中，然后消息接收者从queue中取出并且消费消息。消息被消费以后，queue中不再有存储，所以消息接收者不可能消费到已经被消费的消息。

点对点模式特点：

• 每个消息只有一个接收者（Consumer）(即一旦被消费，消息就不再在消息队列中)；

• 发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运行，都不会影响到发送者下次发送消息；

• 接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息；

1.3.2 发布/订阅模式

发布/订阅模式下包括三个角色：

• 角色主题（Topic）

• 发布者(Publisher)

• 订阅者(Subscriber)

​ 发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。

发布/订阅模式特点：

• 每个消息可以有多个订阅者；

• 发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。

• 为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行；

2. kafka的基本介绍

​ 官网：http://kafka.apache.org/

​ kafka是最初由linkedin公司开发的，使用scala语言编写，kafka是一个分布式，分区的，多副本的，多订阅者的日志系统（分布式MQ系统），可以用于搜索日志，监控日志，访问日志等

​ Kafka is a distributed,partitioned,replicated commit logservice。它提供了类似于JMS的特性，但是在设计实现上完全不同，此外它并不是JMS规范的完整实现。kafka对消息保存时根据Topic进行归类，发送消息者成为Producer,消息接受者成为Consumer,此外kafka集群有多个kafka实例组成，每个实例(server)成为broker。无论是kafka集群，还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息

kakfa的特点:

• 可靠性: 分布式, 分区 , 复制 和容错等
• 可扩展性: kakfa消息传递系统轻松缩放, 无需停机
• 耐用性: kafka使用分布式提交日志, 这个意味着消息会尽可能快速的保存在磁盘上, 因此它是持久的
• 性能: kafka对于发布和订阅消息都具有高吞吐量, 即使存储了许多TB的消息, 他也爆出稳定的性能
• kafka非常快: 保证零停机和零数据丢失

​ apache kafka是一个分布式发布-订阅消息系统和一个强大的队列，可以处理大量的数据，并使能够将消息从一个端点传递到另一个端点，kafka适合离线和在线消息消费。kafka消息保留在磁盘上，并在集群内复制以防止数据丢失。kafka构建在zookeeper同步服务之上。它与apache和spark非常好的集成，应用于实时流式数据分析。

---

kafka的主要应用场景:

• 1. 指标分析: kafka通常用于操作监控数据, 这设计聚合来自分布式应用程序和统计信息, 以产生操作的数据集中反馈
• 2. 日志聚合解决方法: kafka可用于跨组织从多个服务器收集日志, 并使他们一标准的合适提供给多个服务器
• 3. 流式处理: 流式的处理框架(spark, storm , flink) 从主题中读取数据, 对其进行处理, 并将处理后的结果数据写入新的主题, 供用户和应用程序使用, kafka的强耐久性在流处理的上下文中也非常的有用

2.1 弱一致性

3. kafka的架构

Kafka Cluster：由多个服务器组成。每个服务器单独的名字broker（掮客）。

kafka broker：kafka集群中包含的服务器

Kafka Producer：消息生产者、发布消息到 kafka 集群的终端或服务。

Kafka consumer：消息消费者、负责消费数据。

Kafka Topic: 主题，一类消息的名称。存储数据时将一类数据存放在某个topci下，消费数据也是消费一类数据。

​ 订单系统：创建一个topic，叫做order。

​ 用户系统：创建一个topic，叫做user。

​ 商品系统：创建一个topic，叫做product。

com.jiankunking.stormkafka.topologies.CustomCounterTopology

注意：Kafka的元数据都是存放在zookeeper中。

---

kafka架构的内部细节剖析:

​ 说明：kafka支持消息持久化，消费端为拉模型来拉取数据，消费状态和订阅关系有客户端负责维护，消息消费完 后，不会立即删除，会保留历史消息。因此支持多订阅时，消息只会存储一份就可以了。

• Broker：kafka集群中包含一个或者多个服务实例，这种服务实例被称为Broker

• Topic：每条发布到kafka集群的消息都有一个类别，这个类别就叫做Topic

• Partition：Partition是一个物理上的概念，每个Topic包含一个或者多个Partition

• segment：一个partition当中存在多个segment文件段，每个segment分为两部分，.log文件和.index文件，其中.index文件是索引文件，主要用于快速查询.log文件当中数据的偏移量位置

• Producer：负责发布消息到kafka的Broker中。

• Consumer：消息消费者,向kafka的broker中读取消息的客户端

• Consumer Group：每一个Consumer属于一个特定的Consumer Group（可以为每个Consumer指定 groupName）

• .log:存放数据文件

• .index：存放.log文件的索引数据

4. kafka集群环境搭建

4.1 准备工作

• 1. 准备三台服务器, 安装jdk1.8 ,其中每一台虚拟机的hosts文件中都需要配置如下的内容

192.168.72.141 node01
192.168.72.142 node02
192.168.72.143 node03

• 2. 安装目录

安装包存放的目录：/export/software
安装程序存放的目录：/export/servers
数据目录：/export/data
日志目录：/export/logs

创建各级目录命令:
mkdir -p /export/servers/
mkdir -p /export/software/
mkdir -p /export/data/
mkdir -p /export/logs/ 

• 3)zookeeper集群已经安装好并启动

4.2 下载安装包

​ 中文网站: http://kafka.apachecn.org/

​ 英文网站: http://kafka.apache.org/

由于kafka是scala语言编写的，基于scala的多个版本，kafka发布了多个版本。

其中2.11是推荐版本.

• 推荐直接使用资料中的版本即可:

4.3 上传安装包并解压

使用 rz 命令将安装包上传至  /export/software
1)  切换目录上传安装包
cd /export/software
rz   # 选择对应安装包上传即可

2) 解压安装包到指定目录下
tar -zxvf kafka_2.11-1.0.0.tgz -C /export/servers/
cd /export/servers/

3) 重命名(由于名称太长)
mv kafka_2.11-1.0.0 kafka

4.4 修改kafka的核心配置文件

cd /export/servers/kafka/config/
vi server.properties

主要修改以下三个地方:
1) broker.id 需要保证每一台kafka都有一个独立的broker
2) log.dirs 数据存放的目录
3) zookeeper.connect zookeeper的连接地址信息
4) delete.topic.enable 是否直接删除topic
5) host.name 主机的名称
6) 修改: listeners=PLAINTEXT://node01:9092

#broker.id 标识了kafka集群中一个唯一broker。   
broker.id=0   
num.network.threads=3   
num.io.threads=8   
socket.send.buffer.bytes=102400   
socket.receive.buffer.bytes=102400   
socket.request.max.bytes=104857600  

# 存放生产者生产的数据 数据一般以topic的方式存放    
log.dirs=/home/soft/kafka/data       
num.partitions=1   
num.recovery.threads.per.data.dir=1   
offsets.topic.replication.factor=1   
transaction.state.log.replication.factor=1   
transaction.state.log.min.isr=1   
log.retention.hours=168   
log.segment.bytes=1073741824   
log.retention.check.interval.ms=300000     

# zk的信息   
zookeeper.connect=nimbus:2181,zookeeper1:2181,zookeeper2:2181
zookeeper.connection.timeout.ms=6000   
group.initial.rebalance.delay.ms=0  

delete.topic.enable=true
host.name=nimbus

4.5 将配置好的kafka分发到其他二台主机

cd /export/servers
scp -r kafka/ zookeeper1:$PWD  
scp -r kafka/ zookeeper2:$PWD

• 拷贝后, 需要修改每一台的broker.id 和 host.name和listeners

nimbus: broker.id=0 , host.name=nimbus
zookeeper1: broker.id=1 , host.name=zookeeper1
zookeeper2: broker.id=2 , host.name=zookeeper2

4.6 启动集群

注意事项：在kafka启动前，一定要让zookeeper启动起来

cd /home/soft/kafka/bin
 
#前端启动
./kafka-server-start.sh /export/servers/kafka/config/server.properties

#后台启动:
nohup ./kafka-server-start.sh /home/soft/kafka/config/server.properties  2>&1 &


注意：可以启动一台broker，单机版。也可以同时启动三台broker，组成一个kafka集群版


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

可以通过 jps 查看 kafka进程是否已经启动了

登录的前提是, 通过jps是可以看到kafka的进程
登录zookeeper: zkCli.sh
执行: ls /brokers/ids

4.7 查看集群

由于kafka集群并没有UI界面可以查看。

所以我们可以通过查看zookeeper, 来判断, kafka集群是否正常运行

• 1. 使用zookeeper的可视化工具查看

nohup /opt/module/kafka-manager-1.3.3.18/bin/kafka-manager -Dconfig.file=/opt/module/kafka-manager-1.3.3.18/conf/application.conf -Dhttp.port=8888 >/opt/module/kafka-manager-1.3.3.18/kafka-manager.log 2>&1 &

5. kafka的基本操作

• 1. 创建topic

  创建一个名字为test的主题， 有三个分区，有两个副本

  cd /export/servers/kafka_2.11-1.0.0
  bin/kafka-topics.sh --create --zookeeper node01:2181 --replication-factor 2 --partitions 3 --topic test
  

• 2. 查看主题命令

  查看kafka当中存在的主题

  cd /export/servers/kafka_2.11-1.0.0
  bin/kafka-topics.sh  --list --zookeeper node01:2181,node02:2181,node03:2181
  

• 3. 生产者生产数据

  模拟生产者来生产数据

  cd /export/servers/kafka_2.11-1.0.0
  bin/kafka-console-producer.sh --broker-list node01:9092,node02:9092,node03:9092 --topic test
  

• 4. 消费者消费数据

  cd /export/servers/kafka_2.11-1.0.0
  bin/kafka-console-consumer.sh --from-beginning --topic test  --zookeeper node01:2181,node02:2181,node03:2181
  

• 5. 运行describe的命令

  运行describe查看topic的相关详细信息

  cd /export/servers/kafka_2.11-1.0.0
  bin/kafka-topics.sh --describe --zookeeper node01:2181 --topic test
  

  结果说明：

  ​ 这是输出的解释。第一行给出了所有分区的摘要，每个附加行提供有关一个分区的信息。由于我们只有一个分 区用于此主题，因此只有一行。

  ​ “leader”是负责给定分区的所有读取和写入的节点。每个节点将成为随机选择的分区部分的领导者。（因为在kafka中 如果有多个副本的话，就会存在leader和follower的关系，表示当前这个副本为leader所在的broker是哪一个）

  ​ “replicas”是复制此分区日志的节点列表，无论它们是否为领导者，或者即使它们当前处于活动状态。（所有副本列表 0 ，1,2）

  ​ “isr”是“同步”复制品的集合。这是副本列表的子集，该列表当前处于活跃状态并且已经被领导者捕获。（可用的列表 数）

• 6. 增加topic分区数

  任意kafka服务器执行以下命令可以增加topic分区数

  cd /export/servers/kafka_2.11-1.0.0
  bin/kafka-topics.sh --zookeeper zkhost:port --alter --topic topicName --partitions 8
  

• 7. 增加配置

  动态修改kakfa的配置

  cd /export/servers/kafka_2.11-1.0.0
  bin/kafka-topics.sh --zookeeper node01:2181 --alter --topic test --config flush.messages=1
  

• 8. 删除配置

  动态删除kafka集群配置

  cd /export/servers/kafka_2.11-1.0.0
  bin/kafka-topics.sh --zookeeper node01:2181 --alter --topic test --delete-config flush.messages
  

• 9. 删除topic

  目前删除topic在默认情况下知识打上一个删除的标记，在重新启动kafka后才删除。如果需要立即删除，则需要在

  server.properties中配置：

  delete.topic.enable=true

  然后执行以下命令进行删除topic

  kafka-topics.sh --zookeeper zkhost:port --delete --topic topicName
  

6. kafka的javaAPI的操作

• 创建maven的工程, 导入kafka相关的依赖

<dependencies>
	<!-- https://mvnrepository.com/artifact/org.apache.kafka/kafka-clients -->
    <dependency>
        <groupId>org.apache.kafka</groupId>
        <artifactId>kafka-clients</artifactId>
        <version>1.0.0</version>
    </dependency>    
    <dependency>
        <groupId>org.apache.kafka</groupId>
        <artifactId>kafka-streams</artifactId>
        <version>1.0.0</version>
    </dependency>

</dependencies>

<build>
    <plugins>
        <!-- java编译插件 -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.2</version>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
                <encoding>UTF-8</encoding>
            </configuration>
        </plugin>
    </plugins>
</build>

6.1 生产者代码

/**
 * 订单的生产者代码
 */
public class OrderProducer {
    public static void main(String[] args) throws InterruptedException {
        /* 1、连接集群，通过配置文件的方式
         * 2、发送数据-topic:order，value
         */
        Properties props = new Properties();
        props.put("bootstrap.servers", "node01:9092");
        props.put("acks", "all");
        props.put("retries", 0);
        props.put("batch.size", 16384);
        props.put("linger.ms", 1);
        props.put("buffer.memory", 33554432);
        props.put("key.serializer",
                  "org.apache.kafka.common.serialization.StringSerializer");
        props.put("value.serializer",
                  "org.apache.kafka.common.serialization.StringSerializer");
        KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(props);
        for (int i = 0; i < 1000; i++) {
            // 发送数据 ,需要一个producerRecord对象,最少参数 String topic, V value
            kafkaProducer.send(new ProducerRecord<String, String>("order", "订单信息！"+i));
            Thread.sleep(100);
        }
        kafkaProducer.close();
    }
}

6.2 消费者代码

• 自动提交消费偏移量的消费者

/**
 * 消费订单数据--- javaben.tojson
 */
public class OrderConsumer {
    public static void main(String[] args) {
        // 1、连接集群
        Properties props = new Properties();
        props.put("bootstrap.servers", "node01:9092");
        props.put("group.id", "test");
        //以下两行代码 ---消费者自动提交offset值 
        props.put("enable.auto.commit", "true");
        props.put("auto.commit.interval.ms", "1000");
        
        props.put("key.deserializer",
                  "org.apache.kafka.common.serialization.StringDeserializer");
        props.put("value.deserializer",
                  "org.apache.kafka.common.serialization.StringDeserializer");
        KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<String, String>(props);
        //2、发送数据 发送数据需要，订阅下要消费的topic。  order
        kafkaConsumer.subscribe(Arrays.asList("order"));
        while (true) {
            ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(100);// jdk queue offer插入、poll获取元素。 blockingqueue put插入原生，take获取元素
            for (ConsumerRecord<String, String> record : consumerRecords) {
                System.out.println("消费的数据为：" + record.value());
            }
        }
    }
}    

• 手动提交消费的偏移量

public class OrderConsumer {
	public static void main(String[] args) {
        Properties props = new Properties(); 
        props.put("bootstrap.servers", "localhost:9092"); 
        props.put("group.id", "test");
        //关闭自动提交确认选项
        props.put("enable.auto.commit", "false"); 
        
        props.put("key.deserializer",
        "org.apache.kafka.common.serialization.StringDeserializer"); 
        props.put("value.deserializer",
        "org.apache.kafka.common.serialization.StringDeserializer"); 
        KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props); consumer.subscribe(Arrays.asList("test"));
        final int minBatchSize = 200;
        List<ConsumerRecord<String, String>> buffer = new ArrayList<>(); 
        while (true) {
            ConsumerRecords<String, String> records = consumer.poll(100);
            for (ConsumerRecord<String, String> record : records) {
           		buffer.add(record);
            }
            if (buffer.size() >= minBatchSize) { 
                // 可以执行一些业务处理的工作
            	insertIntoDb(buffer);
                // 手动提交offset值
                consumer.commitSync(); 
                buffer.clear();
        	}
        }
    }
}

6.3 kafka StreamsAPI开发

​ 需求：使用StreamAPI获取test这个topic当中的数据，然后将数据全部转为大写，写入到test2这个topic当中去

实现步骤:

• 1. 创建一个topic

  node01服务器使用以下命令来常见一个topic 名称为test2

  cd /export/servers/kafka_2.11-1.0.0/
  bin/kafka-topics.sh --create  --partitions 3 --replication-factor 2 --topic test2 --zookeeper node01:2181,node02:2181,node03:2181
  

• 2. 开发streamAPI

  public class StreamAPI {
      public static void main(String[] args) {
          Properties props = new Properties();
          props.put(StreamsConfig.APPLICATION_ID_CONFIG, "wordcount-application");
          props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "node01:9092");
          props.put(StreamsConfig.KEY_SERDE_CLASS_CONFIG, Serdes.String().getClass());
          props.put(StreamsConfig.VALUE_SERDE_CLASS_CONFIG, Serdes.String().getClass());
          KStreamBuilder builder = new KStreamBuilder();
          builder.stream("test").mapValues(line -> line.toString().toUpperCase()).to("test2");
          KafkaStreams streams = new KafkaStreams(builder, props);
          streams.start();
      }
  }
  
  

• 3. 生产数据

  执行以下命令，向test这个topic当中生产数据

  cd /export/servers/kafka_2.11-1.0.0
  bin/kafka-console-producer.sh --broker-list node01:9092,node02:9092,node03:9092 --topic test
  

• 4. 消费数据

  node02执行一下命令消费test2这个topic当中的数据

  cd /export/servers/kafka_2.11-1.0.0
  bin/kafka-console-consumer.sh --from-beginning  --topic test2 --zookeeper node01:2181,node02:2181,node03:2181
  

7. Apache kafka原理

7.1 分片与副本机制

​ 分片机制：主要解决了单台服务器存储容量有限的问题

​ 当数据量非常大的时候，一个服务器存放不了，就将数据分成两个或者多个部分，存放在多台服务器上。每个服务器上的数据，叫做一个分片

​ 副本：副本备份机制解决了数据存储的高可用问题

​ 当数据只保存一份的时候，有丢失的风险。为了更好的容错和容灾，将数据拷贝几份，保存到不同的机器上。

7.2 kafka保证数据不丢失机制

7.2.1 保证生产者端不丢失

1） 消息生产分为同步模式和异步模式

2） 消息确认分为三个状态

​ a) 0：生产者只负责发送数据

​ b) 1：某个partition的leader收到数据给出响应

​ c) -1：某个partition的所有副本都收到数据后给出响应

3） 在同步模式下

​ a) 生产者等待10S，如果broker没有给出ack响应，就认为失败。

​ b) 生产者重试3次，如果还没有响应，就报错。

4） 在异步模式下

​ a) 先将数据保存在生产者端的buffer中。Buffer大小是2万条。

​ b) 满足数据阈值或者时间阈值其中的一个条件就可以发送数据。

​ c) 发送一批数据的大小是500条。

如果broker迟迟不给ack，而buffer又满了。

开发者可以设置是否直接清空buffer中的数据。

7.2.2 broker端消息不丢失

broker端的消息不丢失，其实就是用partition副本机制来保证。

Producer ack -1(all). 能够保证所有的副本都同步好了数据。其中一台机器挂了，并不影响数据的完整性。

7.2.3 消费端消息不丢失

​ 通过offset commit 来保证数据的不丢失，kafka自己记录了每次消费的offset数值，下次继续消费的时候，会接着上次的offset进行消费。

而offset的信息在kafka0.8版本之前保存在zookeeper中，在0.8版本之后保存到topic中，即使消费者在运行过程中挂掉了，再次启动的时候会找到offset的值，找到之前消费消息的位置，接着消费，由于offset的信息写入的时候并不是每条消息消费完成后都写入的，所以这种情况有可能会造成重复消费，但是不会丢失消息。

7.3 消息存储及查询机制

7.3.1 文件存储机制

​ segment段中有两个核心的文件一个是log,一个是index。 当log文件等于1G时，新的会写入到下一个segment中。

通过下图中的数据，可以看到一个segment段差不多会存储70万条数据。

7.3.2 文件查询机制

需求: 读取 offset=368776 的message消息数据

7.4 生产者数据分发策略

​ kafka在数据生产的时候，有一个数据分发策略。默认的情况使用DefaultPartitioner.class类。

这个类中就定义数据分发的策略。

1） 如果是用户制定了partition，生产就不会调用DefaultPartitioner.partition()方法

​ 数据分发策略的时候，可以指定数据发往哪个partition。

​ 当ProducerRecord 的构造参数中有partition的时候，就可以发送到对应partition上

/**
 * Creates a record to be sent to a specified topic and partition
 *
 * @param topic The topic the record will be appended to
 * @param partition The partition to which the record should be sent
 * @param key The key that will be included in the record
 * @param value The record contents
 */
public ProducerRecord(String topic, Integer partition, K key, V value) {
    this(topic, partition, null, key, value, null);
}

2） 当用户指定key，使用hash算法。如果key一直不变，同一个key算出来的hash值是个固定值。如果是固定值，这种hash取模就没有意义。

Utils.toPositive(Utils.murmur2(keyBytes)) % numPartitions

​ 如果生产者没有指定partition，但是发送消息中有key，就key的hash值。

/**
 * Create a record to be sent to Kafka
 * 
 * @param topic The topic the record will be appended to
 * @param key The key that will be included in the record
 * @param value The record contents
 */
public ProducerRecord(String topic, K key, V value) {
    this(topic, null, null, key, value, null);
}      

3） 当用户既没有指定partition也没有key。

​ 使用轮询的方式发送数据。

/**
 * Create a record with no key
 * 
 * @param topic The topic this record should be sent to
 * @param value The record contents
 */
public ProducerRecord(String topic, V value) {
    this(topic, null, null, null, value, null);
}

7.5 消费者负载均衡机制

​ 一个partition只能被一个组中的成员消费。

​ 所以如果消费组中有多于partition数量的消费者，那么一定会有消费者无法消费数据。

8. 附录_kakfa的配置文件说明

Server.properties配置文件说明

#broker的全局唯一编号，不能重复
broker.id=0

#用来监听链接的端口，producer或consumer将在此端口建立连接
port=9092

#处理网络请求的线程数量
num.network.threads=3

#用来处理磁盘IO的线程数量
num.io.threads=8

#发送套接字的缓冲区大小
socket.send.buffer.bytes=102400

#接受套接字的缓冲区大小
socket.receive.buffer.bytes=102400

#请求套接字的缓冲区大小
socket.request.max.bytes=104857600

#kafka运行日志存放的路径
log.dirs=/export/data/kafka/

#topic在当前broker上的分片个数
num.partitions=2

#用来恢复和清理data下数据的线程数量
num.recovery.threads.per.data.dir=1

#segment文件保留的最长时间，超时将被删除
log.retention.hours=1

#滚动生成新的segment文件的最大时间
log.roll.hours=1

#日志文件中每个segment的大小，默认为1G
log.segment.bytes=1073741824

#周期性检查文件大小的时间
log.retention.check.interval.ms=300000

#日志清理是否打开
log.cleaner.enable=true

#broker需要使用zookeeper保存meta数据
zookeeper.connect=zk01:2181,zk02:2181,zk03:2181

#zookeeper链接超时时间
zookeeper.connection.timeout.ms=6000

#partion buffer中，消息的条数达到阈值，将触发flush到磁盘
log.flush.interval.messages=10000

#消息buffer的时间，达到阈值，将触发flush到磁盘
log.flush.interval.ms=3000

#删除topic需要server.properties中设置delete.topic.enable=true否则只是标记删除
delete.topic.enable=true

#此处的host.name为本机IP(重要),如果不改,则客户端会抛出:Producer connection to localhost:9092 unsuccessful 错误!
host.name=kafka01

advertised.host.name=192.168.140.128

producer生产者配置文件说明

#指定kafka节点列表，用于获取metadata，不必全部指定
metadata.broker.list=node01:9092,node02:9092,node03:9092
# 指定分区处理类。默认kafka.producer.DefaultPartitioner，表通过key哈希到对应分区
#partitioner.class=kafka.producer.DefaultPartitioner
# 是否压缩，默认0表示不压缩，1表示用gzip压缩，2表示用snappy压缩。压缩后消息中会有头来指明消息压缩类型，故在消费者端消息解压是透明的无需指定。
compression.codec=none
# 指定序列化处理类
serializer.class=kafka.serializer.DefaultEncoder
# 如果要压缩消息，这里指定哪些topic要压缩消息，默认empty，表示不压缩。
#compressed.topics=

# 设置发送数据是否需要服务端的反馈,有三个值0,1,-1
# 0: producer不会等待broker发送ack 
# 1: 当leader接收到消息之后发送ack 
# -1: 当所有的follower都同步消息成功后发送ack. 
request.required.acks=0 

# 在向producer发送ack之前,broker允许等待的最大时间 ，如果超时,broker将会向producer发送一个error ACK.意味着上一次消息因为某种原因未能成功(比如follower未能同步成功) 
request.timeout.ms=10000

# 同步还是异步发送消息，默认“sync”表同步，"async"表异步。异步可以提高发送吞吐量,
也意味着消息将会在本地buffer中,并适时批量发送，但是也可能导致丢失未发送过去的消息
producer.type=sync

# 在async模式下,当message被缓存的时间超过此值后,将会批量发送给broker,默认为5000ms
# 此值和batch.num.messages协同工作.
queue.buffering.max.ms = 5000

# 在async模式下,producer端允许buffer的最大消息量
# 无论如何,producer都无法尽快的将消息发送给broker,从而导致消息在producer端大量沉积
# 此时,如果消息的条数达到阀值,将会导致producer端阻塞或者消息被抛弃，默认为10000
queue.buffering.max.messages=20000

# 如果是异步，指定每次批量发送数据量，默认为200
batch.num.messages=500

# 当消息在producer端沉积的条数达到"queue.buffering.max.meesages"后 
# 阻塞一定时间后,队列仍然没有enqueue(producer仍然没有发送出任何消息) 
# 此时producer可以继续阻塞或者将消息抛弃,此timeout值用于控制"阻塞"的时间 
# -1: 无阻塞超时限制,消息不会被抛弃 
# 0:立即清空队列,消息被抛弃 
queue.enqueue.timeout.ms=-1


# 当producer接收到error ACK,或者没有接收到ACK时,允许消息重发的次数 
# 因为broker并没有完整的机制来避免消息重复,所以当网络异常时(比如ACK丢失) 
# 有可能导致broker接收到重复的消息,默认值为3.
message.send.max.retries=3

# producer刷新topic metada的时间间隔,producer需要知道partition leader的位置,以及当前topic的情况 
# 因此producer需要一个机制来获取最新的metadata,当producer遇到特定错误时,将会立即刷新 
# (比如topic失效,partition丢失,leader失效等),此外也可以通过此参数来配置额外的刷新机制，默认值600000 
topic.metadata.refresh.interval.ms=60000

consumer消费者配置详细说明

# zookeeper连接服务器地址
zookeeper.connect=zk01:2181,zk02:2181,zk03:2181
# zookeeper的session过期时间，默认5000ms，用于检测消费者是否挂掉
zookeeper.session.timeout.ms=5000
#当消费者挂掉，其他消费者要等该指定时间才能检查到并且触发重新负载均衡
zookeeper.connection.timeout.ms=10000
# 指定多久消费者更新offset到zookeeper中。注意offset更新时基于time而不是每次获得的消息。一旦在更新zookeeper发生异常并重启，将可能拿到已拿到过的消息
zookeeper.sync.time.ms=2000
#指定消费 
group.id=itcast
# 当consumer消费一定量的消息之后,将会自动向zookeeper提交offset信息 
# 注意offset信息并不是每消费一次消息就向zk提交一次,而是现在本地保存(内存),并定期提交,默认为true
auto.commit.enable=true
# 自动更新时间。默认60 * 1000
auto.commit.interval.ms=1000
# 当前consumer的标识,可以设定,也可以有系统生成,主要用来跟踪消息消费情况,便于观察
conusmer.id=xxx 
# 消费者客户端编号，用于区分不同客户端，默认客户端程序自动产生
client.id=xxxx
# 最大取多少块缓存到消费者(默认10)
queued.max.message.chunks=50
# 当有新的consumer加入到group时,将会reblance,此后将会有partitions的消费端迁移到新  的consumer上,如果一个consumer获得了某个partition的消费权限,那么它将会向zk注册 "Partition Owner registry"节点信息,但是有可能此时旧的consumer尚没有释放此节点, 此值用于控制,注册节点的重试次数. 
rebalance.max.retries=5

# 获取消息的最大尺寸,broker不会像consumer输出大于此值的消息chunk 每次feth将得到多条消息,此值为总大小,提升此值,将会消耗更多的consumer端内存
fetch.min.bytes=6553600

# 当消息的尺寸不足时,server阻塞的时间,如果超时,消息将立即发送给consumer
fetch.wait.max.ms=5000
socket.receive.buffer.bytes=655360
# 如果zookeeper没有offset值或offset值超出范围。那么就给个初始的offset。有smallest、largest、anything可选，分别表示给当前最小的offset、当前最大的offset、抛异常。默认largest
auto.offset.reset=smallest
# 指定序列化处理类
derializer.class=kafka.serializer.DefaultDecoder