目录
Kafka快速回顾
消息队列：
发布/订阅模式：
Kafka 重要概念：
常用命令
整合说明
两种方式
两个版本API
在实际项目中，无论使用Storm还是SparkStreaming与Flink，主要从Kafka实时消费数据进行处理分析，流式数据实时处理技术架构大致如下：
技术栈：Flume/SDK/Kafka Producer API -> KafKa —> SparkStreaming/Flink/Storm（Hadoop YARN） -> Redis -> UI
1）、阿里工具Canal：监控MySQL数据库binlog文件，将数据同步发送到Kafka Topic中/alibaba/canal/alibaba/canal/wiki/QuickStart2）、Maxwell：实时读取MySQL二进制日志binlog，并生成 JSON 格式的消息，作为生产者发送给 Kafka，Kinesis、RabbitMQ、Redis、Google Cloud Pub/Sub、文件或其它平台的应用程序。http://maxwells-daemon.io//zendesk/maxwell
扩展：Kafka 相关常见面试题：
1）、Kafka 集群大小（规模），Topic分区函数名及集群配置？2）、Topic中数据如何管理？数据删除策略是什么？3）、如何消费Kafka数据？4）、发送数据Kafka Topic中时，如何保证数据发送成功？
Apache Kafka： 最原始功能【消息队列】，缓冲数据，具有发布订阅功能（类似微信公众号）。
Kafka快速回顾
Kafka 是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用与大数据实时处理领域。
消息队列：
Kafka 本质上是一个 MQ（Message Queue），使用消息队列的好处？（面试会问）
解耦：允许我们独立的扩展或修改队列两边的处理过程；可恢复性：即使一个处理消息的进程挂掉，加入队列中的消息仍可以在系统恢复后被处理；缓冲：有助于解决生产消息和消费消息的处理速度不一致的情况；灵活性&峰值处理能力：不会因为突发的超负荷的请求而完全崩溃，消息队列能够使关键组件顶住突发的访问压力；异步通信：消息队列允许用户把消息放入队列但不立即处理它；
发布/订阅模式：
一对多，生产者将消息发布到 Topic 中，有多个消费者订阅该主题，发布到 Topic 的消息会被所有订阅者消费，被消费的数据不会立即从 Topic 清除。
Kafka 框架架构图如下所示：
Kafka 存储的消息来自任意多被称为 Producer 生产者的进程，数据从而可以被发布到不同的 Topic 主题下的不同 Partition 分区。在一个分区内，这些消息被索引并连同时间戳存储在一起。其它被称为 Consumer 消费者的进程可以从分区订阅消息。Kafka 运行在一个由一台或多台服务器组成的集群上，并且分区可以跨集群结点分布。
Kafka 重要概念：
1）、Producer： 消息生产者，向 Kafka Broker 发消息的客户端；
2）、Consumer：消息消费者，从 Kafka Broker 取消息的客户端；
3）、Consumer Group：消费者组（CG），消费者组内每个消费者负责消费不同分区的数据，提高消费能力。一个分区只能由组内一个消费者消费，消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者；
4）、Broker：一台 Kafka 机器就是一个 Broker。一个集群由多个 Broker 组成。一个 Broker 可以容纳多个 Topic；
5）、Topic：可以理解为一个队列，Topic 将消息分类，生产者和消费者面向的是同一个 Topic；
6）、Partition：为了实现扩展性，提高并发能力，一个非常大的 Topic 可以分布到多个 Broker （即服务器）上，一个 Topic 可以分为多个 Partition，每个 Partition 是一个 有序的队列；
7）、Replica：副本，为实现备份的功能，保证集群中的某个节点发生故障时，该节点上的 Partition 数据不丢失，且 Kafka 仍然能够继续工作，Kafka 提供了副本机制，一个 Topic 的每个分区都有若干个副本，一个 Leader 和若干个 Follower；
8）、Leader：每个分区多个副本的“主”副本，生产者发送数据的对象，以及消费者消费数据的对象，都是 Leader；
9）、Follower：每个分区多个副本的“从”副本，实时从 Leader 中同步数据，保持和 Leader 数据的同步。Leader 发生故障时，某个 Follower 还会成为新的 Leader；
10）、Offset：消费者消费的位置信息，监控数据消费到什么位置，当消费者挂掉再重新恢复的时候，可以从消费位置继续消费；
11）、Zookeeper：Kafka 集群能够正常工作，需要依赖于 Zookeeper，Zookeeper 帮助 Kafka 存储和管理集群信息；
常用命令
#启动kafka/export/server/kafka/bin/kafka-server-start.sh -daemon /export/server/kafka/config/server.properties #停止kafka/export/server/kafka/bin/kafka-server-stop.sh #查看topic信息/export/server/kafka/bin/kafka-topics.sh --list --zookeeper node1:2181#创建topic/export/server/kafka/bin/kafka-topics.sh --create --zookeeper node1:2181 --replication-factor 1--partitions 3 --topic test#查看某个topic信息/export/server/kafka/bin/kafka-topics.sh --describe --zookeeper node1:2181 --topic test#删除topic/export/server/kafka/bin/kafka-topics.sh --zookeeper node1:2181 --delete --topic test#启动生产者--控制台的生产者--一般用于测试/export/server/kafka/bin/kafka-console-producer.sh --broker-list node1:9092 --topic spark_kafka# 启动消费者--控制台的消费者/export/server/kafka/bin/kafka-console-consumer.sh --bootstrap-server node1:9092 --topic spark_kafka --from-beginning
整合说明
两种方式
Receiver-based Approach：
1.KafkaUtils.createDstream基于接收器方式，消费Kafka数据，已淘汰，企业中不再使用；
2.Receiver作为常驻的Task运行在Executor等待数据，但是一个Receiver效率低，需要开启多个，再手动合并数据(union)，再进行处理，很麻烦；
3.Receiver那台机器挂了，可能会丢失数据，所以需要开启WAL(预写日志)保证数据安全，那么效率又会降低；
4.Receiver方式是通过zookeeper来连接kafka队列，调用Kafka高阶API，offset存储在zookeeper，由Receiver维护；
5.Spark在消费的时候为了保证数据不丢也会在Checkpoint中存一份offset，可能会出现数据不一致；
Direct Approach (No Receivers)：
1.KafkaUtils.createDirectStream直连方式，Streaming中每批次的每个job直接调用Simple Consumer API获取对应Topic数据，此种方式使用最多，面试时被问的最多；
2.Direct方式是直接连接kafka分区来获取数据，从每个分区直接读取数据大大提高并行能力
3.Direct方式调用Kafka低阶API(底层API)，offset自己存储和维护，默认由Spark维护在checkpoint中，消除了与zk不一致的情况 ；
4.当然也可以自己手动维护，把offset存在MySQL/Redis中；
两个版本API
Spark Streaming与Kafka集成，有两套API，原因在于Kafka Consumer API有两套，文档：
/docs/2.4.5/streaming-kafka-integration.html
1.Kafka 0.8.x版本-早已淘汰
底层使用老的KafkaAPI:Old Kafka ConsumerAPI支持Receiver(已淘汰)和Direct模式：
2.Kafka 0.10.x版本-开发中使用
底层使用新的KafkaAPI: New Kafka Consumer API只支持Direct模式
