kafka

原理
broker1(topic1/partition(leader),topic2/partition(follower)),borker2(topic1/partition(follower),topic2/partition(leader))
scala编写，分布式，支持partition分区，多副本replica，基于zk协调分布式消息系统

1. 每个topic可以分多个partition，consumergroup对partition进行消费，topic代表1个消息集合类别，每个topic可以有多个生产者向他发消息，也可以多个消费者去消费其中的消息，同一个topic下的不同partition的消息是不同的，每次发送到broker的消息，会根据同一个topic下的不同规则分到不同的partition中去，类似分库分表思想
2. 每个broker相当于一个机器，每个partion分区独立在一个broker上，topic与broker的关系在ZK中维护
3. PULL模式：消费者从broker中拉取数据，防止消费者循环空数据，消费者在消费数据时会传入一个timeout时长参数
4. 1个group多个consumer，每个customer对应一个或多个partition，1个partition只能被一个consumer消费，但是kafka只能保证同一个partition的消息有序性
5. 新注册ZK中一个consumer,consumers/{group_id}/ [ids,owners,offset],ids记录该组有几个消费者正在消费，owners记录该组的topic信息， offset记录topic每个分区中的每个offset
6. ZK细节：1.broker注册ZK会注册broker的Ip和端口，存储topics和partitions信息，2.consumer注册ZK保存consumergroup和订阅的topics信息；3.被订阅的partition包含1个owner registry存储订阅这个partition的consumerid,同时包含1个offset registry,内容为上次订阅的offset
7. kafka是0拷贝，直接从内核层发送到网络socket传输，未经过应用层内存
8. kafka消费者的确认机制是offset，消息消费偏移量，同一个partition中offset是有序的

集群
1）ZK实现，多个broker服务器组成，每个类型的消息被定义一个topic
2）同一个topic消息按照一定的key和算法被分区partition存储在不同的broker上，生产者和消费者可以在多个broker上生产和消费

可靠性

1. 每个partition可以有多个副本，分leader和follower，leader发送和消费数据，follower作为灾备存在
2. 木桶效应：HW-consumer能够消费的最大offset，LEO，AR，ISR，HW取所有节点中最小leader和follower中都包括HW，leader中包括自己和副本的，副本中只包含自己的，根据最新的LEO最小的那个更新HW LEO，leader和follower都包含，当新增消息log时自增分区中所有的副本统称AR，所有与leader保存一定程度同步的包括leader副本组成ISR，与leader副本有滞后的过多的（不包含leader副本）组成OSR，都是AR的一个子集，只有ISR中的副本可以选举为leader副本
3. acks=0/1/-1;0不等服务器相应；1默认值，只要leader节点收到消息，leader失效会返回一个错误信息，生产者会重发一次，不会丢数据，但是会重复数据；-1所有ISR中副本节点收到消息才确认

幂等
生产者开启参数配置即可：原理-发送消息时带上PID和sequencenumber绑定一起存起来，发送给broker,下次同样的过来就会拒绝接受。–这个只是对当前会话和当前的分区有效，跨区不行，且producer重启后重新分配

分区策略

1. range-默认平均分配
2. roundrobin轮询-按照c订阅的topic按字典排序
3. stickyAssignor-在保持平均的情况下尽量保持保持与上次分配相同

消息丢失处理：

producer 的acks参数值设置为‘0’或者‘1’，不等待服务器确认或者只让leader确认
解决方法：将acks的值设置为all或者-1，让leader和followers全部进行确认

producer 没有设置失败重试
根据实际场景将retries参数值设置为正整数
解决方法：根据实际场景将retries参数值设置为正整数

consumer poll到消息后还未来的及完全消费，便已经提交
解决方法：这种情况是在自动提交的情况下发生的，如果enable.auto.commit值为true，可以根据实际场景将auto.commit.interval.ms的值调大。如果enable.auto.commit值为false，就调用commitSync方法手动提交offset

消息重复消费
consumer 在 partition中的位置是通过提自己 offset+1 实现的，offset的提交方式有自动提交和手动提交两种。1-自动提交offset情况下，当消息消费完成，在提交之前（甚至是前一瞬间）consumer 宕机，那么 consumer 重启后的poll的offset依然是宕机前消费的那个offset ,因此造成重复消费。2-同样的，手动提交模式下，在提交代码调用之前， consumer 宕机也会造成消息重复消费
解决方法：consumer 关闭自动提交，使用手动提交。producer发送消息时对消息封装一个唯一标识ID。consumer消费消息前根据唯一标识查询Redis，存在就不消费，不存在就消费，在提交前向Redis set一条记录