Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、Storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。
一、Kafka的使用场景
- 日志收集：一个公司可以用Kafka收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。
- 消息系统：解耦和生产者和消费者、缓存消息等。
- 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
- 运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
二、Kafka基本概念
kafka是一个分布式的，分区的消息(官方称之为commit log)服务。它提供一个消息系统应该具备的功能，但是确有着独特的设计。可以这样来说，Kafka借鉴了JMS规范的思想，但是确并没有完全遵循JMS规范。
首先，让我们来看一下基础的消息(Message)相关术语：
因此，从一个较高的层面上来看，producer通过网络发送消息到Kafka集群，然后consumer来进行消费，如下图：
服务端(brokers)和客户端(producer、consumer)之间通信通过TCP协议来完成。
三、kafka基本使用
安装前的环境准备
由于Kafka是用Scala语言开发的，运行在JVM上，因此在安装Kafka之前需要先安装JDK。
yum install java-1.8.0-openjdk* -y
我这里之前安装的是jdk1.8.0_11(jdk-8u11), 结果报错Uninitialized object exists on backward branch 152。随后更换了jdk版本为1.8.0_302后正常启动了。
kafka依赖zookeeper，所以需要先安装zookeeper：
wget https://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.5.8/apache-zookeeper-3.5.8-bin.tar.gz
tar -zxvf apache-zookeeper-3.5.8-bin.tar.gz
cd apache-zookeeper-3.5.8-bin
cp conf/zoo_sample.cfg conf/zoo.cfg
# 启动zookeeper
bin/zkServer.sh start
bin/zkCli.sh
ls / #查看zk的根目录相关节点
1 下载安装包
下载2.4.1 release版本，并解压：
wget https://mirror.bit.edu.cn/apache/kafka/2.6.2/kafka_2.12-2.6.2.tgz # 2.12是scala的版本，2.6.2是kafka的版本
tar -xzf kafka_2.12-2.6.2.tgz
cd kafka_2.12-2.6.2
2 修改配置
修改配置文件config/server.properties:
#broker.id属性在kafka集群中必须要是唯一
broker.id=0
#kafka部署的机器ip和提供服务的端口号
listeners=PLAINTEXT://192.168.131.171:9092
#kafka的消息存储文件
log.dir=/usr/local/data/kafka-logs
#kafka连接zookeeper的地址
zookeeper.connect=192.168.131.171:2181
3 启动/停止服务
现在来启动kafka服务：
启动脚本语法：
kafka-server-start.sh [-daemon] server.properties
# 示例
/usr/local/kafka/kafka_2.12-2.6.2/bin/kafka-server-start.sh -daemon /usr/local/kafka/kafka_2.12-2.6.2/config/server.properties
可以看到，server.properties的配置路径是一个强制的参数，-daemon表示以后台进程运行，否则ssh客户端退出后，就会停止服务。(注意，在启动kafka时会使用linux主机名关联的ip地址，所以需要把主机名和linux的ip映射配置到本地host里，用vim /etc/hosts)
# 启动kafka，运行日志在logs目录的server.log文件里
bin/kafka-server-start.sh -daemon config/server.properties #后台启动，不会打印日志到控制台
# 或者用如下命令，控制台会打印出日志
bin/kafka-server-start.sh config/server.properties &
# 我们进入zookeeper目录通过zookeeper客户端查看下zookeeper的目录树
bin/zkCli.sh
ls / #查看zk的根目录kafka相关节点
ls /brokers/ids #查看kafka节点
停止kafka
bin/kafka-server-stop.sh
3.1 server.properties核心配置详解：
4 创建主题
现在我们来创建一个名字为“test”的Topic，这个topic只有一个partition，并且备份因子也设置为1：
bin/kafka-topics.sh --create --zookeeper 192.168.131.171:2181 --replication-factor 1 --partitions 1 --topic test
现在我们可以通过以下命令来查看kafka中目前存在的topic：
bin/kafka-topics.sh --list --zookeeper 192.168.131.171:2181
除了我们通过手工的方式创建Topic，当producer发布一个消息到某个指定的Topic，这个Topic如果不存在，就自动创建。
4.1 删除主题
bin/kafka-topics.sh --delete --topic test --zookeeper 192.168.131.171:2181
5 发送消息
kafka自带了一个producer命令客户端，可以从本地文件中读取内容，或者我们也可以以命令行中直接输入内容，并将这些内容以消息的形式发送到kafka集群中。在默认情况下，每一个行会被当做成一个独立的消息。
首先我们要运行发布消息的脚本，然后在命令中输入要发送的消息的内容：
# 注意--broker-list是连在一起的
bin/kafka-console-producer.sh --broker-list 192.168.131.171:9092 --topic test
>this is a message!
>this is a another message!
6 消费消息
对于consumer，kafka同样也携带了一个命令行客户端，会将获取到内容在命令中进行输出，默认是消费最新的消息：
bin/kafka-console-consumer.sh --bootstrap-server 192.168.131.171:9092 --topic test
此时consumer在监听test这个topic了，我们来发送一条消息看能否收到：
可以看到，已经成功接收到新消息了！
如果想要消费之前的消息可以通过–from-beginning参数指定，如下命令：
bin/kafka-console-consumer.sh --bootstrap-server 192.168.131.171:9092 --from-beginning --topic test
如果你是通过不同的终端窗口来运行以上的命令，你将会看到在producer终端输入的内容，很快就会在consumer的终端窗口上显示出来。
以上所有的命令都有一些附加的选项；当我们不携带任何参数运行命令的时候，将会显示出这个命令的详细用法。
6.1 消费多主题
bin/kafka-console-consumer.sh --bootstrap-server 192.168.131.171:9092 --whitelist "test|test-2"
6.2 单播消费
一条消息只能被某一个消费者消费的模式，类似queue模式，只需让所有消费者在同一个消费组里即可。
分别在两个客户端执行如下消费命令，然后往主题里发送消息，结果只有一个客户端能收到消息：
bin/kafka-console-consumer.sh --bootstrap-server 192.168.131.171:9092 --consumer-property group.id=testGroup --topic test
我们发现，只有一个消费者客户端接收到了单播消息。
6.3 多播消费
一条消息能被多个消费者消费的模式，类似publish-subscribe模式费，针对Kafka同一条消息只能被同一个消费组下的某一个消费者消费的特性，要实现多播只要保证这些消费者属于不同的消费组即可。我们再增加一个消费者，该消费者属于testGroup-2消费组，结果两个客户端都能收到消息。
bin/kafka-console-consumer.sh --bootstrap-server 192.168.131.171:9092 --consumer-property group.id=testGroup-2 --topic test
6.4 查看消费组名
bin/kafka-consumer-groups.sh --bootstrap-server 192.168.131.171:9092 --list
6.5 查看消费组的消费偏移量
bin/kafka-consumer-groups.sh --bootstrap-server 192.168.131.171:9092 --describe --group testGroup
- current-offset：当前消费组的已消费偏移量
- log-end-offset：主题对应分区消息的结束偏移量(HW)
- lag：当前消费组未消费的消息数
注意，消费偏移量是以消费组为单位计算的，这也是为什么一个组内的多个消费组中只有一个消费者能消费到某一条消息的原因。因为被消费完之后，偏移量变了，所以同组内的其他消费者自然无法消费到。那么如果让多个消费者消费到同一条消息呢？自然是让多个消费者组去消费，我们可以将消费者分布在不同的消费者组中，从而达到类似于发布订阅的功能。
四、主题Topic和消息日志Log
可以理解Topic是一个类别的名称，同类消息发送到同一个Topic下面。对于每一个Topic，下面可以有多个分区(Partition)日志文件:
Partition是一个有序的message序列，这些message按顺序添加到一个叫做commit log的文件中。每个partition中的消息都有一个唯一的编号，称之为offset，用来唯一标示某个分区中的message。
每个partition，都对应一个commit log文件。一个partition中的message的offset都是唯一的，但是不同的partition中的message的offset可能是相同的。
kafka一般不会删除消息，不管这些消息有没有被消费。只会根据配置的日志保留时间(log.retention.hours)确认消息多久被删除，默认保留最近一周的日志消息。kafka的性能与保留的消息数据量大小没有关系，因此保存大量的数据消息日志信息不会有什么影响。
每个consumer是基于自己在commit log中的消费进度(offset)来进行工作的。在kafka中，消费offset由consumer自己来维护；一般情况下我们按照顺序逐条消费commit log中的消息，当然我可以通过指定offset来重复消费某些消息，或者跳过某些消息。
这意味kafka中的consumer对集群的影响是非常小的，添加一个或者减少一个consumer，对于集群或者其他consumer来说，都是没有影响的，因为每个consumer维护各自的消费offset。
1 创建多个分区的主题
bin/kafka-topics.sh --create --zookeeper 192.168.131.171:2181 --replication-factor 1 --partitions 2 --topic test1
2 查看下topic的情况
bin/kafka-topics.sh --describe --zookeeper 192.168.131.171:2181 --topic test1
以下是输出内容的解释，第一行是所有分区的概要信息，之后的每一行表示每一个partition的信息。
- leader节点负责给定partition的所有读写请求，这里的数字是broker的id。
- replicas 表示某个partition在哪几个broker上存在备份。不管这个几点是不是”leader“，甚至这个节点挂了，也会列出。
- isr 是replicas的一个子集，它只列出当前还存活着的，并且已同步备份了该partition的节点。
我们可以运行相同的命令查看之前创建的名称为”test“的topic。
之前设置了topic的partition数量为1，备份因子为1，因此显示就如上所示了。
可以进入kafka的数据文件存储目录查看test和test1主题的消息日志文件：
消息日志文件主要存放在分区文件夹里的以log结尾的日志文件里，如下是test1主题对应的分区0的消息日志：
当然我们也可以通过如下命令增加topic的分区数量(目前kafka不支持减少分区)：
bin/kafka-topics.sh -alter --partitions 3 --zookeeper 192.168.131.171:2181 --topic test
2.1 Topic，Partition和Broker总结理解
可以这么来理解Topic，Partition和Broker。
一个topic，代表逻辑上的一个业务数据集，比如按数据库里不同表的数据操作消息区分放入不同topic，订单相关操作消息放入订单topic，用户相关操作消息放入用户topic，对于大型网站来说，后端数据都是海量的，订单消息很可能是非常巨量的，比如有几百个G甚至达到TB级别，如果把这么多数据都放在一台机器上可定会有容量限制问题，那么就可以在topic内部划分多个partition来分片存储数据，不同的partition可以位于不同的机器上，每台机器上都运行一个Kafka的进程Broker。
为什么要对Topic下数据进行分区存储？
1、commit log文件会受到所在机器的文件系统大小的限制，分区之后可以将不同的分区放在不同的机器上，相当于对数据做了分布式存储，理论上一个topic可以处理任意数量的数据。
2、为了提高并行度。