一、Kafka概念
Apache Kafka是由Apache开发的一种发布订阅消息系统，它是一个分布式的、分区的和重复的日志服务。
传统的消息传递方法：
排队：在队列中，一组用户可以从服务器中读取消息，每条消息都发送给其中一个人。
发布-订阅：在这个模型中，消息被广播给所有的用户
kafka的优势：
快速：单一的Kafka代理可以处理成千上万的客户端，每秒处理数兆字节的读写操作。
可伸缩：在一组机器上对数据进行分区和简化，以支持更大的数据
持久：消息是持久性的，并在集群中进行复制，以防止数据丢失。
设计：它提供了容错保证和持久性
kafka的缺陷：
没有完整的监控工具集
消息调整的问题
不支持通配符主题选择
速度问题
二、Kafka应用场景
1、日志收集：一个公司的各种应用都可以作为生产者将日志吐到kafka，再由hbase，solr，es等来消费kafka的日志作统计，查错。
2、消息系统：解耦和生产者和消费者、缓存消息等。
3、用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
4、运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告
三、Kafka相关组件
主题：Kafka主题是一堆或一组消息。
生产者：在Kafka，生产者发布通信以及向Kafka主题发布消息。
消费者：Kafka消费者订阅了一个主题，并且还从主题中读取和处理消息。
经纪人：在管理主题中的消息存储时，我们使用Kafka Brokers。
四、Kafka消息是采用Pull模式，还是Push模式？
Kafka采用Pull模式。
1、解决了当broker推送的速率远大于consumer消费的速率时的情况。
2、consumer可以自主决定是否批量的从broker拉取数据。避免了Push模式下为了避免consumer崩溃而采用较低的推送速率，造成资源浪费。
Pull有个缺点是，如果broker没有可供消费的消息，将导致consumer不断在循环中轮询，直到新消息到达。为了避免这点，Kafka有个参数可以让consumer阻塞知道新消息到达。
五、Zookeeper
Zookeeper是一个开放源码的、高性能的协调服务，它用于Kafka的分布式应用。
不可能越过Zookeeper，直接联系Kafka broker。一旦Zookeeper停止工作，它就不能服务客户端请求。
Zookeeper作用：
1、Zookeeper主要用于在集群中不同节点之间进行通信
2、在Kafka中，它被用于提交偏移量，因此如果节点在任何情况下都失败了，它都可以从之前提交的偏移量中获取
3、它还执行其他活动，如: leader检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。
六、解决kafka的数据丢失
Producer端：
宏观上看保证数据的可靠安全性，肯定是依据分区数做好数据备份，设立副本数。
Broker端：
topic设置多分区，分区自适应所在机器，为了让各分区均匀分布在所在的broker中，分区数要大于broker数。分区是kafka进行并行读写的单位，是提升kafka速度的关键。
Consumer端
consumer端丢失消息的情形比较简单：如果在消息处理完成前就提交了offset，那么就有可能造成数据的丢失。由于Kafka consumer默认是自动提交位移的，所以在后台提交位移前一定要保证消息被正常处理了，因此不建议采用很重的处理逻辑，如果处理耗时很长，则建议把逻辑放到另一个线程中去做。为了避免数据丢失，现给出两点建议：
1、enable.auto.commit=false 关闭自动提交位移
2、在消息被完整处理之后再手动提交位移