https://my.oschina.net/u/3995125
本章重点：
1.Kafka产生背景
2.Kafka的架构
3.Kafka安装部署及集群部署
4.Kafka的基本操作
5.Kafka的应用Kafka的简介：
高性能、高吞吐量，广泛应用在大数据传输场景，使用Scala语言编写，是Apache的顶级项目。
Kafka产生的背景：
作为消息系统，早期作为活动流和数据处理管道。活动流是所有网站对用户的使用情况做分析的时候要用到的最常规部分，活动数据包括页面的访问量（pv）,被查看内容方面的信息以及搜索内容，这种数据通常处理方式是先以日志写入，再周期性分析。运营数据指的是服务器的性能数据（CPU、IO使用率、请求时间、服务日志等）。
Kafka的应用场景：
由于Kafka具有更好的吞吐量、内置分区、冗余及容错性的特点（Kafka每秒可以处理几十万的消息），让Kafka成为了一个很好的大规模消息处理应用的解决方案，所有在企业级应用上，主要会有如下几个方面：
1.行为跟踪：Kafka可以用来跟踪用户浏览页面，搜索及其它行为，通过发布订阅模式实时记录到对应的Topic中，通过后端大数据平台接入处理分析，并做进一步的处理和监控。
2.日志搜集：Kafka代理日志聚合，日志聚合表示从服务器上收集日志文件，然后放到一个集中的平台（文件服务器）进行处理。在实际应用开发中，我们应用程序的log都会输出到本地磁盘上，排查问题的化通过Linux命令搞定，如果应用程序组成了负载均衡集群，并且集群的机器有几十台以上，那么想通过日志快速定位问题，就很麻烦。所有都会做日志的统一搜集平台管理log日志文件。公司大多套路就是把应用日志文件集中到Kafka上，然后分别导入到ES和HDFS上，用来做实时检索分析和离线统计数据备份。而另外一方面，Kafka本身提供了很好的API来集成日志并且做日志收集。
Kafka本身的架构：
一个典型的Kafka集群包含若干个Producer（可以是应用节点产生的消息，也可以是通过Flume搜集日志产生的事件），若干个Broker（Kafka支持水平扩展），若干个Consumer Group，以及一个Zookeeper集群，Kafka通过Zookeeper管理集群配置及服务协同。Producer使用push模式将消息发送到Broker。Consumer通过监听使用pull模式从Broker订阅并消费消息。
多个Broker协同工作，Producer与Consumer部署在各个业务逻辑中，三者通过Zookeeper管理协调请求转发，这样就组成了一个高性能的分布式消息发布和订阅系统。
Kafka的安装部署：
下载安装包
https://www.apache.org/dyn/closer.cgi?path=/kafka/1.1.0/kafka_2.11-1.1.0.tgz 安装过程
1. tar -zxvf 解压安装包 Kafka目录介绍：
1. /bin 操作 kafka 的可执行脚本
2. /config 配置文件
3. /libs 依赖库目录
4. /logs 日志数据目录 启动/停止Kafka
1. 需要先启动 zookeeper，如果没有搭建 zookeeper 环境，可以直接运行kafka 内嵌的 zookeeper
启动命令： bin/zookeeper-server-start.sh config/zookeeper.properties &
2. 进入 kafka 目录，运行 bin/kafka-server-start.sh ｛-daemon 后台启动｝config/server.properties &
3. 进入 kafka 目录，运行 bin/kafka-server-stop.sh config/server.propertieKafka的基本操作：
创建topic
./kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 -partitions 1 --topic test
Replication-factor 表示该 topic 需要在不同的 broker 中保存几份，这里设置成 1，表示在两个 broker 中保存两份
Partitions 分区数
查看topic
./kafka-topics.sh --list --zookeeper localhost:2181 查看topic属性
./kafka-topics.sh --describe --zookeeper localhost:2181 --topic test 消费消息
./kafka-console-consumer.sh –bootstrap-server localhost:9092 --topic test
--from-beginning 发送消息
./kafka-console-producer.sh --broker-list localhost:9092 --topic test 安装集群环境：
修改server.properties配置
1. 修改 server.properties. broker.id=0 / 1
2. 修改 server.properties 修改成本机 IP
advertised.listeners=PLAINTEXT://192.168.11.153:9092
当 Kafka broker 启动时，它会在 ZK 上注册自己的 IP 和端口号，客户端就通过这个 IP 和端口号来连接 配置信息分析：
发送端可选配置信息分析
acks
ack配置表示producer发送消息到broker上以后的确认值，有以下三个可选项：
0：表示producer不需要等待broker的消息确认，这个选项时延最小但同时风险最大（因为当server宕机时，数据将会丢失）
1：表示producer只需要获得Kafka集群中的leader节点确认即可，这个选择时延较小，同时确保leader节点确认接收成功。
all(-1):需要ISR中所有的Replica给予接收确认，速度最慢，安全性最高，但是由于ISR可能会缩小到仅包含一个Replica，所以设置参数为all并不能一定避免数据丢失。batch.size
生产者发送多个消息到broker上的同一个分区时，为了减少网络请求带来的性能开销，通过批量方式来提交消息，可以通过这个参数来控制批量提交的字节数大小，默认大小是16384byte，也就是16kb,意味着当一大批消息大小达到指定的batch.size的时候会统一发送。linger.ms
producer默认会把两次发送时间间隔内收集到的消息进行一次聚合，然后再发送，以此提高吞吐量，而linger.ms就是为每次发送到broker的请求增加一些delay,以此来聚合更多的Message请求。这个有点像TCP里面的Nagle算法，在TCP协议传输中，为了减少大量小数据包的发送，采用了Nagle算法，也就是基于小包的停等协议。
batch.size和linger.ms这两个参数是Kafka性能优化的关键参数，其实这两个参数作用是一样的，当两者结合使用，只要满足其中一个要求，就会发送请求到broker上。max.request.size
设置请求的数据的最大字节数，为了防止发生较大的数据包影响到吞吐量，默认值为1MB消费端的可选配置
group.id
consumer group是Kafka提供的可扩展且具有容错性的消费者机制，既然是一个组，那么组内必然可以有多个消费者或者消费实例（consumer instance），他们共享一个公共的group id，组内的所有消费者协调在一起来消费订阅主题（subscribed topics）的所有分区（partition）.当然，每个分区只能由同一个消费组内的一个consumer来消费。
.如下图所示，分别有三个消费者，属于两个不同的 group，那么对于 firstTopic 这个 topic 来说，这两个组的消费者都能同时消费这个 topic 中的消息，对于此事的架构来说，这个 firstTopic 就类似于 ActiveMQ 中的 topic 概念。如右图所示，如果 3 个消费者都属于同一个group，那么此事 firstTopic 就是一个 Queue 的概念 
enable.auto.commit
消费组消费消息之后自动提交，只要当消息提交以后，该消息才不会被再次接受到，还可以配合auto.commit.interval.ms控制自动提交的频率。
当然，我们也可以通过consumer.commitSync()的方式实现手动提交auto.offset.reset
这个参数是针对新的groupid中的消费组而言的，当有新的groupid的消费者来消费指定的topic时，对于该参数的配置，会有不同的语义：
auto.offset.reset=latest情况下，新的消费者将会从其它消费者最后消费的offset处开始消费Topic下的消息。
auto.offset.reset=earliest情况下，新的消费者会从该topic最早的消息开始消费。
auto.offset.reset=none情况下，新的消费组加入以后，由于之前不存在offset,则会直接抛出异常。
max.poll.records
此设置限制每次调用pull返回的消息数，这样更好预测每次pull间隔要处理的最大值，通过调整此值，可以减少pull间隔。