一、概述
一个分布式消息中间件，基于zookeeper的分布式日志系统。
简单来讲，就是一个存储系统，起一个缓冲作用。
所谓的消息系统，就是将数据从一个地方传递到另一个地方。消息传递模式有两种：点对点传递模式，发
布-订阅模式。Kafka是一种发布-订阅模式。
二、特点
1.解耦：
消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
2.异步：
支持用户将消息放入队列中，不立刻处理，需要的时候再去处理。
3.削峰：
使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
举个例子：A系统高并发状态下，可能会出现连接异常甚至崩溃的情况，这个时候我们能选择一个中间件，将所有客户的请求都放入消息队列中，A系统只需要从消息队列中拉取消息再做处理即可。
三、角色
1.Topic消息队列：
发布到Kafka集群的消息的类别。（就看作是一个个的消息队列名，用来找到对应的消息队列）。
（1）Partition：topic中数据的具体管理单元。
一个topic 可以划分为多个partition，分布到多个 broker上管理；
partition 中的每条信息都会被分配一个递增的id（offset）；
每个 partition 是一个有序的队列，各个 partition 间是无序的。换句话讲，如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将
partition数目设为1。
每个partition都可以有多个副本；
分区对于 kafka 集群的好处是：实现topic数据的负载均衡。分区对于消费者来说，可以提高并发度，提高效率。
（2）Broker：
Kafka集群包含一个或多个服务器，服务器节点称为Broker。容纳多个topic的多个Partition。
（3）Offset：
消息在这底层存储中的索引位置，看作一个游标，通过它来确定消息的位置。
2.Producer生产者：
数据的发布者，发送消息给Broker。
3.Consumer消费者：
消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。
4.Leader和Follower：
每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个
Follower。
四、数据丢失和数据重复问题：
在处理这两个问题之前，先来了解两个机制：ACK应答机制和RETIRES延迟重发机制。
ACK应答机制：
在生产者端：broker往内存中写数据时，同时也会进行数据持久化操作，并根据你有多少个Leader和Follower，生成副本。内存先向Leader传输，完成后由leader向Follower进行备份。
此时就要考虑到备份的副本是否完成的问题。这里ACK应答机制可设三个参数：
* 设 0 ：不等broker同步完成的确认，继续发送下一条信息。不管数据的持久化，只要内存已处理完，直接传输下一条 （速度快 但不稳定）
* 设 1 ：等broker同步完成1次，就继续发送下一条信息。数据持久化只要Leade一完成，就进行下一次传输，不管Leader向Follower的备份 （速度较快 但如果落盘位置挂掉，没有备份数据）
* 设 -1 ：等broker全部同步完成，再发送下一条信息。等到数据持久化全部完成（包括备份的），才进行下一次的传输 （稳定，全部落盘才进行下一次的数据传输）
注意：ACK机制只保证写入端的数据安全问题（不丢失），不会去管你数据是否重复等等。
RETIRES延迟重发机制：
ACK应答机制（即便选择-1完全同步）只能保证数据全部备份下来，但不能确定备份数据的节点是否活跃，假如某台机器宕机，这时就需要重复机制，隔段时间再次重新发送一遍。
注意：这里虽避免了数据丢失，但可能会造成数据重复。而且，如果重发后还无
响应，就会跳过这条数据继续下一次的发送，造成该数据丢失
所以，总结如下：
造成数据丢失的原因：
1. ACK应答机制设置为0，数据没有落盘保存，只是在内存中走了一遭，此时内存中的数据一旦没了，那就会造成数据丢失。
设置为1，那么数据只会落盘保存到Leader上，Leader还没向Follower中同步时，此时Leader挂掉，数据丢失。
2. Offset设置为自动提交，他的机制是定时自动提交，如果提交时，数据还没处理完，但数据偏移量已经改变，下次读取的是下一个位置处的数据，而这部分未处理的数据所在节点一旦出现故障，数据也会丢失。
解决办法：
ACK应答机制设为-1（或者all），并且关闭手动提交，提交时采用同步模式
prop.put( ProducerConfig.ACKS_CONFIG, "all"); prop.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG,"false");
consumer.commitSync();
造成数据重复的原因：
1.延迟重发机制下，节点出现故障导致主从数据同步未完成，他会重新发送一遍
2.已经消费完成，但是offset还未提交，此时节点挂掉，下一次还是会从之前的offset处里数据，重复消费。
解决办法：
1.手动维护offset（但仍有风险）；
2.加大kafka.consumer.session.timeout参数，避免错误关闭的情况。
3.在下游选择Hbase或者Hive等进行去重。