一.安装
本文采用的安装方式是Ubuntu:16.04 版本的Linux安装。
先找个目录准备wget下载kafka的安装包 kafka下载地址是这http://kafka.apache.org/downloads.html
cd /home
wget http://mirrors.tuna.tsinghua.edu.cn/apache/kafka/2.3.0/kafka_2.11-2.3.0.tgz //直接wget拿压缩包了。
mkdir kafka //把压缩包解压到这里了。为啥要解压到这里，或许只是强迫症。
当前目录执行 tar -zxvf kafka_2.11-2.3.0.tgz -C kafka 解压到 kafka目录下了。
cd /home/kafka/kafka_2.11-2.3.0/bin //接下来就是执行可执行文件来运行kafka的消费者和生产者。
sh zookeeper-server-start.sh ../config/zookeeper.properties & //kafka必须有zookeeper调度。
sh kafka-server-start.sh ../config/server.properties & //起kafka 注意这个properties不同版本的位置可能不一样
netstat -tunlp|egrep "(2181|9092)" 看是否启动成功了。
像下面这样就行了。端口号是默认的。要改就改配置文件。可以改但没必要。
二.运行
下面创建一个生产者。
sh kafka-console-producer.sh --broker-list localhost:9092 --topic testKafka 创建生产者。此时你的界面是让你输入的界面。如下所示，随便写点啥。
然后再创建一个消费者。这时需要注意的是重建一个窗口(如果你是xshell这种远程连的也重建一个连接)，这个窗口也不要关。在新建的窗口的bin文件夹下 /home/kafka/kafka_2.11-2.3.0/bin 执行下面这句命令。
sh kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic testKafka --from-beginning
接下来就会看到testKafka的topic被我消费掉了。
如上就是安装及运行测试需要的整个过程。
三. 爬坑
其实网上有的教程是有一些细节没说明白的。
在创建消费者时，有的教程可能是像下面这么让你执行的。
sh kafka-console-consumer.sh --topic test --zookeeper localhost:2181 --from-beginning
然后你会得到下面的这个错误。zookeeper 不认识这个执行选项、
zookeeper is not a recognized option
那是因为你的kafka下载的版本与网上某些博主不同。下载最新的稳定版执行下面这个命令就ok了。旧版本我就不探究了。
sh kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning
四. 学习kafka设想的几个问题
0.为什么使用消息队列?消息队列的作用是什么?
1.kafka里面都使用的啥对象？
2.kafka数据如何存储的？
3.kafka有topic为啥还要引入partition ？
4.消息消费完是删掉还是怎么滴？
5.消息存在哪？
6.kafka如何实现分布式存储，还能正确消费？
7.kafka为啥高效，高吞吐？
8.kafka配置文件怎么配置？
9.kafka与其他消息队列相比的优劣。
0.为什么使用消息队列?消息队列的作用是什么?
答：参考了这篇文章。https://blog.csdn.net/cws1214/article/details/52922267
消息队列的特性: 容灾，业务无关，提高性能。
这两个问题也可以合成一个: 消息队列的使用场景
1.异步处理2.应用解耦3.流量削峰4.日志处理5.消息通讯(websocket)
1.异步处理是将重要级相对低的操作写入队列。有消费者常驻进程不停的消费这个消息。这样系统就能快速响应了。
消息写入到队列中，常驻进程拿消息调一些发短信，发邮件之类的接口。
2.应用解耦
如果有订单模块和库存模块。
用户下单后，订单系统将消息写到消息队列里。返回用户处理中。然后此时库存系统从消息队列拿消息进而处理返回给显示界面处理结果。
如果没有消息队列的存在。 订单调库存系统时，库存系统宕机了。那么此时页面返回的就是500这种了。
首先消息队列肯定是没问题的。即使单节点宕机，也会有副本再变成主节点。 那么当你库存系统恢复了就可以正常消费了。
3.流量削峰
秒杀和抢购活动中。防止流量过大导致应用程序down掉。
用户请求会写入消息队列的对应topic中。 假如消息队列长度超过了最大数量，就直接抛弃用户请求或跳转错误页面。
然后对应逻辑系统根据消息队列中顺序来执行秒杀数量的请求。
当然你程序里面写一个值来控制秒杀数量从而解决并发请求也是可以的。
4.日志处理
解决大量日志传输的问题
日志写到kafka logstash做日志解析，统一成JSON 输出到 ElasticSearch
在用kibana可视化查看ES日志就行了。
5.消息通讯(这个就用websocket就行了)
1.kafka里面使用的对象。
答：摘自文章：https://blog.csdn.net/tflasd1157/article/details/81985722
消息记录(record): 由一个key，一个value和一个时间戳构成，消息最终存储在主题下的分区中, 记录在生产者中称为生产者记录(ProducerRecord), 在消费者中称为消费者记录(ConsumerRecord)，Kafka集群保持所有的消息，直到它们过期， 无论消息是否被消费了，在一个可配置的时间段内，Kafka集群保留所有发布的消息，不管这些消息有没有被消费。比如，如果消息的保存策略被设置为2天，那么在一个消息被发布的两天时间内，它都是可以被消费的。之后它将被丢弃以释放空间。Kafka的性能是和数据量无关的常量级的，所以保留太多的数据并不是问题。
生产者(producer): 生产者用于发布(send)消息
消费者(consumer): 消费者用于订阅(subscribe)消息
消费者组(consumer group): 相同的group.id的消费者将视为同一个消费者组, 每个消费者都需要设置一个组id, 每条消息只能被 consumer group 中的一个 Consumer 消费,但可以被多个 consumer group 消费
主题(topic): 消息的一种逻辑分组，用于对消息分门别类，每一类消息称之为一个主题，相同主题的消息放在一个队列中
分区(partition): 消息的一种物理分组， 一个主题被拆成多个分区，每一个分区就是一个顺序的、不可变的消息队列，并且可以持续添加，分区中的每个消息都被分配了一个唯一的id，称之为偏移量(offset),在每个分区中偏移量都是唯一的。每个分区对应一个逻辑log，有多个segment组成。
偏移量(offset): 分区中的每个消息都一个一个唯一id，称之为偏移量，它代表已经消费的位置。可以自动或者手动提交偏移量(即自动或者手动控制一条消息是否已经被成功消费)
代理(broker): 一台kafka服务器称之为一个broker
副本(replica)：副本只是一个分区(partition)的备份。 副本从不读取或写入数据。 它们用于防止数据丢失。
领导者(leader)：Leader 是负责给定分区的所有读取和写入的节点。 每个分区都有一个服务器充当Leader， producer 和 consumer 只跟 leader 交互
追随者(follower)：跟随领导者指令的节点被称为Follower。 如果领导失败，一个追随者将自动成为新的领导者。 跟随者作为正常消费者，拉取消息并更新其自己的数据存储。replica 中的一个角色，从 leader 中复制数据。
zookeeper：Kafka代理是无状态的，所以他们使用ZooKeeper来维护它们的集群状态。ZooKeeper用于管理和协调Kafka代理
kafka功能
发布订阅：生产者(producer)生产消息(数据流), 将消息发送到到kafka指定的主题队列(topic)中，也可以发送到topic中的指定分区(partition)中，消费者(consumer)从kafka的指定队列中获取消息，然后来处理消息。
流处理(Stream Process): 将输入topic转换数据流到输出topic
连接器(Connector) : 将数据从应用程序(源系统)中导入到kafka，或者从kafka导出数据到应用程序(宿主系统sink system), 例如：将文件中的数据导入到kafka，从kafka中将数据导出到文件中
kafka中的消息模型
队列：同名的消费者组员瓜分消息
发布订阅：广播消息给多个消费者组(不同名)
消费模型。消费模型有两种，push和pull 这个push是适用消息代理，将消息从kafka(broker)主动推给消费者进程。消费时标记为已消费，并将消息处理掉、
如果消费者进程挂掉会导致消息永久丢失。很一些问题，所以不采用。
还有一种消费类型是pull 这种是消费者进程主动从broker中拉消息。 由消费者自己控制消费的进度，可以按照offset任意获取消息。采用这种。
网络模型。 kafka的客户端(producer/consumer)可以使用单线程的selector还可以使用多线程的selector
2.kafka数据如何存储的？
答：摘自简书：https://www.jianshu.com/p/4bf007885116
高性能的分布式存储模型
在kafka中保证高可靠模型依靠的是副本机制，有了副本机制之后，计算机器宕机也不会发生数据丢失。
高性能的日志存储。 (一股jdk7的concurrentHashMap气息)
每一个partition都会对应一个日志目录。一个目录下有多个logSegement 一个logSegement分为三部分: xxx.index xxxxx.log xxx.timeindex
两个文件的命名规则为：每个partition的第一个全局segement 从0开始。后续每个segement文件名为上一个segement文件最后一条消息的Offset值。
没有数字用0填充。 下面白话文补充说明一下、
索引和存储数据的log文件名称是一样的，只是拓展名不一样。 00000100.index 00000100.log 这种。 为key:value
其中 00000000.index 存储的是本分区offset的稀疏索引。例如 100条消息，index里面可能只存了7条 这7条消息根据算法为步增很高的值。例 7,20,34,55,77,100
然后查找 00000000.index这个索引文件(文件存储类似步增的真实消息位置) 比如111 111-100=11 通过二分法查找index中key为小于等于最接近11的、也就是7 然后找log文件中 offset等于107的开始往后找，直到找到111 遍历log文件就不是O(n)了，向后直到找到111的key。此时就获取到了 111的offset值。
上述是一个查找到指定offset处消息的过程。 正常情况就是顺序读的，顺序读就很快了，不用这么费劲，就从0开始往后读
3.kafka有topic为啥还要引入partition ？
topic是逻辑的概念，partition是物理的概念，对用户来说是透明的。
producer只需要关心消息发往哪个topic，而consumer只关心自己订阅哪个topic，并不关心每条消息存于整个集群的哪个broker。
若没有分区，一个topic对应的消息集在分布式集群服务组中，就会分布不均匀。
即可能导致某台服务器A记录当前topic的消息集很多，若此topic的消息压力很大的情况下，服务器A就可能导致压力很大，吞吐也容易导致瓶颈。
有了分区后，假设一个topic可能分为10个分区，kafka内部会根据一定的算法把10分区尽可能均匀分布到不同的服务器上。
比如：A服务器负责topic的分区1，B服务器负责topic的分区2，在此情况下，Producer发消息时若没指定发送到哪个分区的时候，kafka就会根据一定算法上个消息可能分区1，下个消息可能在分区2。
4.消息消费完是删掉还是怎么滴？
答：摘自：https://blog.csdn.net/gdkyxy2013/article/details/86644919
跟配置文件有关，消息会过期自动删除，消费者消费消息超时也会导致消息堆积。
消费者进程消费一个消息后，消息所在分区的offset会进行位移。
由于分区segement中记录的是真实消息的物理地址。这样下次消费就从另一个offset指定的物理地址进行寻址了。
使用消费者组会增加消息消费的速度。
启动多个组，相同的数据会被不同组的消费者消费多次。 因此多个消费者组消费同一个topic消息没必要
5.消息存在哪？
消息存储在了 000000xxxxx.log文件中。 首先找到server.properties文件 看日志要往哪写。默认是/tmp/kafka-logs/
然后可以使用下面这条命令来查看消息。在kafka的bin目录下执行。 testzy-0根据你的topic来调整。
sh kafka-run-class.sh kafka.tools.DumpLogSegments --files /tmp/kafka-logs/testzy-0/00000000000000000000.log --print-data-log
6.kafka如何实现分布式存储，还能正确消费？
答：参考：https://blog.csdn.net/lizhitao/article/details/51718185 & https://www.jianshu.com/p/4bf007885116
副本机制
kafka的副本机制是多个服务端节点对其他节点的主题分区的日志进行复制。
当集群中的某个节点发生故障时，访问故障节点的请求会被转移到其他正常节点。(reblance) 也就是多个broker使用zookeeper的意义。
kafka每个主题的每个分区都有一个主副本和多个副本。 副本保持与主副本同步，当主副本出现故障时就会被替换。
kafka中也不是所有的副本都可以成为主副本。 维护这两个集合 ISR(In Sync Replicas)同步中集合，包括主副本(leader)和没有落后太多的副本
replica.lag.max.messages : 4 就是落后主副本4个消息才从ISR移除。 replica.lag.time.max : 500ms follow向leader发送请求超时时间间隔
副本机制与zookeeper也有通信。
需要满足两个条件1.节点必须要与zookeeper保持连接。2.在同步的过程中这个副本不能落后主副本太多。
AR(Assigned Replicas)副本的集合 AR = ISR + 落后太多的副本。
HW(高水位)是consumer能够看到的此partition的位置，LEO是每个partition的log最后一条message的位置。
HW能保证leader所在的broker宕机，该消息仍然可以从新选举的leader中获取，不会造成信息丢失。
当 Producer 向 Leader 发送数据时，可以通过 request.required.acks 参数来设置数据可靠性的级别：
• 1(默认)：这意味着 Producer 在 ISR 中的 Leader 已成功收到的数据并得到确认后发送下一条 Message。如果 Leader 宕机了，则会丢失数据。
• 0：这意味着 Producer 无需等待来自 Broker 的确认而继续发送下一批消息。这种情况下数据传输效率最高，但是数据可靠性却是最低的。
• -1：Producer 需要等待 ISR 中的所有 Follower 都确认接收到数据后才算一次发送完成，可靠性最高。
1.是正常情况下的，属于一个适中的可靠级别。 -1是非常可靠的，但是可想而知，效率比较低。 0 是效率高，但是没有可靠性、
高可用模型及幂等
幂等：就是多次执行，结果是一样的。
使用事务来保证幂等。
exactly-once语义
刚好一次，即使 Producer 重试发送消息，消息也会保证最多一次地传递给 Consumer。该语义是最理想的，也是最难实现的。
保证操作的原子性，要么全部成功，要么全部失败。
7.kafka为啥高效，高吞吐？
(1)顺序读写
kafka的消息是不断追加到文件中的，这个特性使kafka可以充分利用磁盘的顺序读写性能
顺序读写不需要硬盘磁头的寻道时间，只需很少的扇区旋转时间，所以速度远快于随机读写
Kafka官方给出了测试数据( Raid-5，7200rpm )：
顺序 I/O: 600MB/s
随机 I/O: 100KB/s
(2)零拷贝
没有用户缓冲区。减少上下文切换
"零拷贝(zero-copy)"系统调用机制，就是跳过“用户缓冲区”的拷贝，建立一个磁盘空间和内存的直接映射，数据不再复制到“用户态缓冲区”
(3)文件分段
topic分为多个partition partition 分为多个logsegment
(4)批量发送
Kafka允许进行批量发送消息，先将消息缓存在内存中，然后一次请求批量发送出去
比如可以指定缓存的消息达到某个量的时候就发出去，或者缓存了固定的时间后就发送出去
如100条消息就发送，或者每5秒发送一次
这种策略将大大减少服务端的I/O次数
(5)数据压缩
Kafka还支持对消息集合进行压缩，Producer可以通过GZIP或Snappy格式对消息集合进行压缩
压缩的好处就是减少传输的数据量，减轻对网络传输的压力
Producer压缩之后，在Consumer需进行解压，虽然增加了CPU的工作，但在对大数据处理上，瓶颈在网络上而不是CPU，所以这个成本很值得。
8.kafka配置文件怎么配置？
答：参考：https://www.cnblogs.com/ashaff/p/11446267.html 太多了。
9.kafka与其他消息队列相比的优劣
https://blog.csdn.net/u013939918/article/details/70947669
https://blog.csdn.net/ChenRui_yz/article/details/86154132
https://blog.csdn.net/lifaming15/article/details/79942793