kafka概念

kafka与传统消息队列的比较

为什么业务系统用activeMQ：基于事务的保证

为什么大数据平台用kafka：吞吐量大，速度快（如何保证速度快？（1）顺序读写磁盘，（2）pageCache页缓存机制）

kafka的消费模型：

kafka数据消费快的原因
（1）顺序读写磁盘
（2）pageCache页缓存机制

kafka的架构模型

基于producer consumer topic broker 等的一个基本架构

kafka的组件介绍

producer

producer：消息的生产者，主要就是用于生产数据

topic

topic：消息的主题，可以理解为一类消息的高度抽象的集合

broker

broker：kafka服务器

partition

partition：一个topic下面有多个partition，分区，一个partition保存了一个topic的部分消息，为了防止消息不丢失，引入副本备份机制
partition究竟应该创建多少个合适？？？根据实际情况而定

segment

segment：一个partition下面有多个segement，把一个partiton当中的数据，切成了多个segment段，一个segment下面由两个文件构成

• .log
  .log：日志数据 hello world hadoop

• .index
  .index：索引数据 hello 1 world 2 hadoop 3 便于我们快速的查找 使用的是二分查找法
  0000000000.log
  0000000000.index

  0000000100.log
  0000000100.index

zookeeper

zookeeper：保存了我们topic的一些数据信息，比如说topic有多少个partition，partition有多少个副本等等

consumer

consumer：消费者，主要用于消费我们kafka当中的数据

offset

offset：记录消费的偏移量 2 也就是记录了我们下次的消费数据的条数

group

group：消费组的概念，设置不同的组，就是不同的消费者。如果A组消费了第一条数据，那么A组就再消费不到第一条数据了，但是B组还可以从第一条开始消费

启动kafka: (Jps会发现有个Kafka进程)

nohup bin/kafka-server-start.sh config/server.properties 2＞&1 &

kafka的命令行 的管理使用

创建topic

bin/kafka-topics.sh --create --partitions 3 --topic test --replication-factor 2 --zookeeper node01:2181,node02:2181,node03:2181/kafka

模拟消息的生产者：

bin/kafka-console-producer.sh --broker-list node01:9092,node02:9092,node03:9092 --topic test

模拟消息的消费者

bin/kafka-console-consumer.sh --bootstrap-server node01:9092,node02:9092,node03:9092 --from-beginning --topic test

查看topic列表

bin/kafka-topics.sh --list --zookeeper node01:2181/kafka

删除topic

bin/kafka-topics.sh --delete --topic wifidata --zookeeper node01:2181/kafka

delete.topic.enable，配置默认是false，意思是 是否允许kafka集群删除topic，只有为true的情况，kafka才会删除那些已经被标记为删除的topic。否则topic将不会被删除，仅仅被标记，所谓标记，也就是在zk上记录那些delete的topic。注意修改完后需要重启集群。

如果想手动删除topic，那么需要做两件事情

1. 删除zookeeper上topic的数据

     /brokers/ids/topics/xxx
   
     /config/topics/xxx
   

2. 删除该topic所有partition和replica的数据
   数据在所有broker的log.dirs目录下，文件夹结构是topic-partition的方式，直接将该topic的整个文件夹删除即可

kafka的数据的分区

探究的是kafka的数据生产出来之后究竟落到了哪一个分区里面去了
第一种分区策略：给定了分区号，直接将数据发送到指定的分区里面去
第二种分区策略：没有给定分区号，给定数据的key值，通过key取上hashCode进行分区
第三种分区策略：既没有给定分区号，也没有给定key值，直接轮循进行分区
第四种分区策略：自定义分区

kafka如何保证数据的不丢失

1) 生产者如何保证数据的不丢失：

消息的确认机制，使用ack机制我们可以配置我们的消息不丢失机制为-1，保证我们的partition的leader与follower都保存好了数据
1：表示partition的leader已经确认消息保存好了。
0：没有任务的确认反馈机制，不安全。
-1：需要leader与follower都确认保存好了，才会继续发送下一条数据

2) 消费者如何保证不重复消费数据：

offset偏移量，记录了我们的消息消费的偏移量，新版本偏移量记录在了一个topic里面

3) broker如何保证数据的不丢失：

partition的副本机制

消息传输保障

消息传输保障

一般来说，消息中间件的消息传输保障有3个层级，分别如下：
(1) at most once:至多一次。消息可能会丢失，但绝对不会重复传输。
(2) at least once:至少一次。消息绝不会丢失，但可能会重复传输。
(3) exactly once:恰好一次。每条消息肯定会被传输一次且仅传输一次。

对于kafka生产者

对生产者而言，当生产者向kafka发送消息时，一旦消息被成功提交到日志文件，由于多副本机制的存在，这条消息就不会丢失。如果生产者发送消息到kafka之后，遇到了网络问题造成通信中断，那么生产者就无法判断该消息是否已经提交，但生产者可以进行多次重试来确保消息已经写入kafka，这个重试的过程中有可能会造成消息的重复写入，所以这里kafka提供的消息传输保障为at least once。

对于kafka消费者

对消费者而言，消费者处理消息和提交消费位移的顺序在很大程度上决定了消费者提供哪一种消息传输保障。
如果消费者在拉取完消息之后，应用逻辑先处理消息后提交消息位移，那么在消息处理之后且在位移提交之前消费者宕机了，待它重新上线之后，会从上一次位移提交的位置拉取，这样就出现了重复消费，因为有部分消息已经处理过了只是还没来得及提交消费位移，此时就对应at least once。
如果消费者在拉取消息之后，应用逻辑先提交消费位移后进行消息处理，那么在位移提交之后且在消息处理完成之前消费者宕机了，待它重新上线之后，会从已经提交的位移处开始重新消费，但之前沿有部分消息未进行消费，如此就会发生消息丢失，此时就对应at most once。
kakfa从0.11.0.0版本开始引入了幂等和事务这两个我，以此来实现EOS（exactly once semantics ，精确一次处理语义）。

幂等

所谓的幂等，简单地说就是对接口的多次调用所产生的结果和调用一次是一致的。这个可以避免，生产者在进行重试的时候重复写入消息。

开启幂等性功能，将生产者客户端参数enable.idempotence设置为true（默认值为false）。

为了实现生产者的幂等性，kafka为此引入了producer id(以下简称为PID)和序列号（sequence number）这两个概念。每个新的生产者实例在初始化的时候都会被分配一个PID，这个PID对用户而言是完全透明的。对于每个PID，消息发送到的每一个分区都有对应的序列号，这些序列号从0 开始单调递增。生产者每发送一条消息就会将<PID,分区>对应的序列号的值加1。

broker端会在内存中为每一对<PID，分区>维护一个序列号。对于收到的每一条消息，只有当它的序列号的值（SN_new）比broker端中维护的对应的序列号的值（SN_old）大1（即SN_new=SN_old+1）时，broker才会接收它。如果SN_new<SN_old+1，那么说明消息被重复写入，broker可以直接将其丢弃。如果SN_new>SN_old+1，那么说明中间有数据尚未写入，出现了乱序，暗示可能有消息丢弃，对应的生产者会抛出OutOfOrderSequenceException，之后会连带一系列的异常。

引入 序列号来实现幂等也只是针对每一对<PID,分区>而言的，也就是说，kafka的幂等只能保证单个生产者会话（session）中单分区的幂等。

事务？

幂等性并不能跨多个分区运行，而事务可以弥补这个缺陷。事务可以保证对多个分区写入操作的原子性。
在再均衡发生期间，消费组内的消费者是无法读取消息的。