Kafka
1、Kafka介绍
Kafka是最初由linkedin公司开发的，使用scala语言编写，kafka是一个分布式，分区的，多副本的，多订阅者的消息队列系统。
2、Kafka相比其他消息队列的优势
常见的消息队列：RabbitMQ，Redis ，zeroMQ ,ActiveMQ
Kafka的优势：
- 可靠性：分布式的，分区，复制和容错的。
- 可扩展性：Kafka消息传递系统轻松缩放，无需停机。
- 耐用性：Kafka使用分布式提交日志，这意味着消息会尽可能快速的保存在磁盘上，因此它是持久的。
- 性能：Kafka对于发布和定于消息都具有高吞吐量。即使存储了许多TB的消息，他也爆出稳定的性能。
- Kafka非常快：保证零停机和零数据丢失。
3、Kafka的术语
3.1、Kafka中的术语名词
Broker：kafka集群中包含一个或者多个服务实例，这种服务实例被称为Broker
Topic：每条发布到kafka集群的消息都有一个类别，这个类别就叫做Topic
Partition：Partition是一个物理上的概念，每个Topic包含一个或者多个Partition
Producer：负责发布消息到kafka的Broker中。
Consumer：消息消费者,向kafka的broker中读取消息的客户端
Consumer Group：每一个Consumer属于一个特定的Consumer Group（可以为每个Consumer指定 groupName）
4、Kafka的架构
5、Kafka能做到消费的有序性吗
- 一个主题（topic）下面有一个分区（partition）即可
5.1、为什么topic下多个分区不能保证有序
- 生产者生产数据到borker的多个分区，每个分区的数据是相对有序的，但整体的数据就无序了。因为消费者在消费的时候是一个个的分区进行消费的，所以不能保证全局有序。
6、分区与消费者组间的关系
- 消费组： 由一个或者多个消费者组成，同一个组中的消费者对于同一条消息只消费一次。
- 某一个主题下的分区数，对于消费组来说，应该小于等于该主题下的分区数。
7、生产者分区策略
- 没有指定分区号、没指定key根据轮询的方式发送到不同的分区
- 没有指定分区号、指定了key，根据key.hashcode%numPartition
- 指定了分区号，则直接将数据写到指定的分区里面去
- 自定义分区策略
//可根据主题和内容发送
public ProducerRecord(String topic, V value)
//根据主题，key、内容发送
public ProducerRecord(String topic, K key, V value)
//根据主题、分区、key、内容发送
public ProducerRecord(String topic, Integer partition, K key, V value)
//根据主题、分区、时间戳、key，内容发送
public ProducerRecord(String topic, Integer partition, Long timestamp, K key, V value)
如果没有指定分区号，也没有指定具体的key（轮询）
如果没有指定分区号，指定了具体的key（hash）
前缀+date.getTime() fixlog_1564388581914
如果指定了具体的分区号，（按照分区号）
自定义分区
8、数据丢失
8.1、生产者保证数据不丢失
- 同步模式：配置=1 （只有Leader收到，-1 所有副本成功，0 不等待）Leader Partition挂了，数据就会丢失
解决：设置 -1 保证produce 写入所有副本算成功 producer.type = sync request.required.acks=-1/all
- 异步模式，当缓冲区满了，如果配置为0（没有收到确认，一满就丢弃），数据立刻丢弃
解决：不限制阻塞超时时间。就是一满生产者就阻
8.2、broker保证数据不丢失
broker采用分片副本机制，保证数据高可用。
8.3、customer保证数据不丢失
-
拿到数据后，存储到hbase中或者mysql中，如果hbase或者mysql在这个时候连接不上，就会抛出异常，如果在处理数据的时候已经进行了提交，那么kafka上的offset值已经进行了修改了，但是hbase或者mysql中没有数据，这个时候就会出现数据丢失。 主要是因为offset提交使用了异步提交。
-
解决方案
- Consumer将数据处理完成之后，再来进行offset的修改提交。默认情况下offset是 自动提交，需要修改为手动提交offset值。
- 流式计算。高级数据源以kafka为例，由2种方式：receiver (开启WAL，失败可恢复) director （checkpoint保证）
9、数据重复
- 落表（主键或者唯一索引的方式，避免重复数据）
业务逻辑处理（选择唯一主键存储到Redis或者mongdb中，先查询是否存在，若存在则不处理；若不存在，先插入Redis或Mongdb,再进行业务逻辑处理）
10、Kafka当中数据的查找过程
第一步：通过offset确定数据保存在哪一个segment里面了，
第二步：查找对应的segment里面的index文件 。index文件都是key/value对的。key表示数据在log文件里面的顺序是第几条。value记录了这一条数据在全局的标号。如果能够直接找到对应的offset直接去获取对应的数据即可
如果index文件里面没有存储offset，就会查找offset最近的那一个offset，例如查找offset为7的数据找不到，那么就会去查找offset为6对应的数据，找到之后，再取下一条数据就是offset为7的数据。
11、Kafka auto.offset.reset值详解
earliest
- 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从头开始消费
latest
- 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，消费新产生的该分区下的数据
none
-
topic各分区都存在已提交的offset时，从offset后开始消费；只要有一个分区不存在已提交的offset，则抛出异常
latest 这个设置容易丢失消息，假如Kafka出现问题，还有数据往topic中写，这个时候重启Kafka，这个设置会从最新的offset开始消费,中间出问题的哪些就不管了。
