kafka简介
- kafka 通过zookeeper对元数据进行管理，包括集群，broker，主题，分区等内容 ，消息存储在磁盘，用途 消息系统，存储系统，流式处理平台数据供应，旧的生产消费客户端是scala开发的，0.9.x后改为java.
- kafka从2.0版本开始不支持jdk 7 ，配置文件 conf/server.properties ，主要配置
- kafka启动
**
最新版本：
Scala 2.12 - kafka_2.12-2.7.0.tgz (asc, sha512)
Scala 2.13 - kafka_2.13-2.7.0.tgz (asc, sha512)
zookeeper简介
**
zookeeper中包含leader,follower,observe,分布式应用可以基于zookeeper实现诸如数据 发布订阅，负载均衡，命名服务，分布式协调通知，集群管理，master选举，配置维护等功能，配置文件zoo.cfg.启动 》 zkServer.sh start . 集群中每台服务的myid文件值不同。
生产者，broker集群，消费者结构
主题和分区
在kafka中，每个主题可以有多个分区，每个分区又可以有多个副本。这多个副本中，只有一个是leader，而其他的都是follower副本。仅有leader副本可以对外提供服务。建立主题时可指定分区数量，副本数量，一个主题可以有多个分区，每个分区有一个offset，offset是消息在分区的唯一标志，消息顺序追加到分区尾部。副本机制(一主多从），leader副本负责处理读写请求，follower负责与leader副本的消息同步，副本处于不同的broker中，当leader出现故障，会从follower副本中重新选举一个leader. 默认follower都在isr集合中，当副本同步落后太多，就会被剔除到osr集合中，等进度赶上时再恢复到isr集合。只有isr集合中的follower可以参与leader选举。
当消息在isr集合中所有副本存储后才能被消费（HW位置之前的数据）。这里就有了 HW（高水位），LEO
如果follwer 还没复制完而落后leader,这时leader突然宕机，则可能造成数据丢失
用命令新建topic
在创建主题的时候，该主题的分区及副本会尽量可能均匀地分到不同的broker节点上，从0.10.x版本开始支持指定broker的机架信息（必须全指定或全不指定），如果指定了，会尽可能让分区副本分配到不同的机架上。kafka目前只支持增加分区而不支持减少分区（涉及到已有数据的处理，比较复杂），注意增加分区会改变消息key所计算的分区值，导致和以前的消息分区规则不一致。
topic的名字不能重复，（. 在kafka内部会转成_）,创建topic首先会在zookeeper /brokers/topics 节点下创建与该主题对应的子节点并写入主题相关的配置信息。创建节点记录配置信息，然后异步的创建主题和分区。
kafka 内部包含两个主题，分别为 __consumer_offsets 和 __transaction_state。
KafkaAdminClient 可以管理主题（增删改查）
当集群中新增broker节点时，只有新建的主题分区才有可能分配到这个节点上，而之前的分区并不会自动分配到这个新加入的节点。可以分区重分配，分区重分配很消耗性能，复制限流；
调大 ulimit -n 65535 增加文件描述符，否则建分区数量过多会报错（打开文件数过多）
生产者
同一个key的消息会被划分到同一分区中，有key的消息还可以支持日志压缩功能。也可以发消息时直接指定分区。如果key为null,消息会轮询发到可用分区。
发送消息有三种模式： 发后既忘，同步，异步。
同步是send方法返回future对象，通过调用get()方法阻塞等待响应，通过get（timeout）实现可超时的阻塞，可配置异常后重试次数，也可以自己代码处理，同步发送的可靠性高，性能差一些。
异步方式使用callback实现，对同一分区，record1先发，record2后发，callback1会在callback2之前调用。（这个特性没啥用，仍然存在record1发送失败，而record2发送成功的可能，造成 1,2在分区的顺序不一样，需要消费者自行处理纠正）
同时发送多条消息，最后调用close（）回收资源
生产者和消费者必须用同一系列化器
可以设置生产者拦截器，对消息发送前后进行一些处理
发送消息 内部有个双端队列，缓存消息，默认32M，
重要参数acks, acks=1只要分区的leader写入成功，就会收到服务端的成功响应。acks = 0,生产者发送消息不需要等待服务端的响应。acks = -1 或 acks =all ,生产者需要等待isr中所有副本都写入成功才能够收到服务端的响应。这个可靠性最强。但是isr集合中也可能只有leader副本。需要配合min.insync.replicas参数的联动。
重试可以解决因为leader选举，网络抖动等发生的异常问题。retires,retry.backoff.ms
生产请求的超时时间由参数request.timeout.ms配置，默认是 30000，即30秒。将消息写入leader后，会启用一个延时的生产操作（DelayedProduce)，处理消息正常的写入所有副本或超时的情况。
消费者
kafka中的消费是基于拉模式的。消费组，同一消费组的不同消费者会分别消费主题的不同分区，一个分区只能被一个消费组中的一个消费者消费，一个消费者可以消费多个分区。不同消费组，是分别消费，每个消费组可独立消费一份消息。
步骤：1，配置消费者客户端，创建消费者实例 2，订阅主题 3，拉取消息并消费，4，提交消费位移，5关闭消费者实例
设置 goup.id , subcribe 订阅可以主题具有消费者自动再均衡的功能，而assign 方法订阅不具备自动均衡功能。
为了保证消费的可靠性，要设置 enable.auto.commit参数为 false,然后业务处理完后手动提交offset 。这个默认是5秒自动提交一次。
手动提交分为 同步提交和异步提交两个。
auto.offset.reset 对新消费组来说，latest 从分区末尾开始消费； earliest 从起始处消费。还有一个none 值，当分区没有offset时会报错（nooffsetforpartitionException）。
从特定位置开始消费：
consumerRebalanceListener 再均衡监听器 ，消费者拦截器 consumerinterceptor
正常情况下，消费者数量应该小于等于分区数量，如果大于，会有空闲的消费者。
日志存储
一个分区对应一个日志（Log），为了防止Log 过大，kafka又引入了日志分段 LogSegment,Log 在物理上只能以文件夹形式存储，而每个Logsegmeng 对应磁盘上的一个日志文件和两个索引文件，以及可能的其他文件。单个日志分段的大小由broker端参数log.segment.bytes来限制，默认值为1GB.
kafka实现的压缩方式是讲多条消息一起进行压缩，这样可以保证较好的压缩效果。消费者从服务端获取的也是压缩的消息，消费者在处理消息之前才会解压消息，这样保持了端到端的压缩。
保留策略：基于日志大小，基于时间，基于offset(日志起始偏移量）。
kafka使用磁盘存储；rabbitMQ使用内存作为默认的存储介质，磁盘作为备选，以此实现高吞吐低延迟。kafka是追加日志，顺序写盘，速度很快，raid5的顺序写入可达600M/s, （随机写入只有100k/s）,顺序写盘的速度比随机写内存的速度快。
除了消息顺序追加，页缓存，kafka还使用零拷贝技术来提升性能。，依赖底层的sendfile(),对应java的FileChannal.transferTo()方法。零拷贝从磁盘直接到网卡设备，将原来的4次复制减少到2次，去除了内核的两次拷贝。
其他
当前版本的kafka还引入了事务的概念，默认隔离级别是 read_uncommitted.
Kafka集群中会有一个或多个broker，其中有一个会被选举为控制器（kafka controller)，负责管理整个集群中所有分区和副本的状态，负责选举分区的leader，异常恢复,更新元数据，增加分区操作时间负责重新分配分区。 控制器的选举通过创建 /controller节点，创建成功的会记录brokerId 的值。kafka的控制器使用单线程处理事件，事件被封装后存到LinkedBlockingQueue中，由一个专用线程按先入先出处理事件。
优雅关闭：kill -s TERM pid 或kill -15 pid ，千万不要使用kill -9 的方式。