首先讨论下为什么要是用kafka：
什么是kafka
Kafka是由LinkedIn开发的一个分布式的消息系统，使用Scala编写，它以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如Storm，Spark，Flink都支持与Kafka集成。现在我们的数据实时处理平台也使用到了kafka。现在它已被多家不同类型的公司作为多种类型的数据管道和消息系统使用。
为什么使用消息系统
上面我们提到kafka是一个分布式的消息系统。那为什么要在我们的数据处理平台中使用这样的一个消息系统呢？消息系统能给我们带来什么样的好处呢？
(1) 解耦
在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
(2) 冗余
有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
(3) 扩展性
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
(4) 灵活性 & 峰值处理能力
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
(5) 顺序保证
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。
(6) 缓冲
在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。
(7)发布/订阅特性
异步的发布/订阅集成模式。
这是消息传输技术的关键特征之一
部署kafka：
1、首先在官网下载所需版本的安装包
$ tar -xzf kafka_2.13-3.5.0.tgz 解压
$ cd kafka_2.13-3.5.0
2、因为kafka依赖zookeeper，所以先配置zookeeper
vim ./config/zookeeper.properties
dataDir=/kafka/zookeeper #ZooKeeper的数据目录，主要目的是存储内存数据库序列化后的快照路径。如果没有配置事务日志(即dataLogDir配置项)的路径，那么ZooKeeper的事务日志也存放在数据目录中。
clientPort=2181 #向外提供服务的端口号
maxClientCnxns=0 #在套接字级别上限制同一客户端的并发连接数。默认值为60，设置为0表示不做任何限制。
minSessionTimeout =
maxSessionTimeout = #客户端和服务端会话保持的最小、最大超时时间。ZooKeeper的很多数据和状态都和会话绑定。假如客户端和服务端成功建立连接(会话)后，正常情况下，客户端会时不时地向服务端发送心跳，如果这个服务端或者客户端挂了，它们之间的会话要保持多长时间
admin.enableServer=false
tickTime=2000 基本的时间单元，如tickTime=2000,initLimit=2表示4秒
initLimit=10 followers启动时需要连接leader，并从Leader处获取它所缺失的那部分数据，以便它能和leader的数据保持同步。只有保持了同步，该follower才被标记为ONLINE，然后才能提供服务。这个配置项限定从follower启动到恢复完成的超时时间。一般情况下，ZooKeeper保存的都是协调数据，数据量不会很大，但如果要同步的数据很大，可以考虑增大这个选项的值。注意，这个值依赖于tickTime时间单元，例如tickTime=2000,initLimit=2表示4秒
syncLimit=5 #follower和leader之间数据延迟的最大时间长度。例如，有个节点的更新操作缓慢，它的数据已经严重落后于leader，ZooKeeper就会将它从ZooKeeper集群中踢出去。ZooKeeper使用时间来度量follower和leader之间数据的延迟，这个选项的值依赖于tickTime，例如tickTime=2000,syncLimit=2表示follower比leader延迟了4秒
server.0=10.157.5.19:2888:3888
server.1=10.157.5.20:2888:3888
server.2=10.157.5.21:2888:3888
指定ZooKeeper集群中的服务器节点。有几个server节点，就给几个这个配置项，所有节点上的这部分配置要一致。
X：整数。是ZooKeeper中服务器的一个简单标识。这个数值需要和dataDir下的myid文件内容一致。在启动ZooKeeper集群中的每个实例时，需要读取dataDir中的myid文件，并将该文件中的数值和配置文件中的server.X做匹配，匹配到哪个就表示是哪个ZooKeeper服务器节点
autopurge.snapRetainCount=5
新的快照生成后触发保留5个的删除策略
3、配置完成后启动zookeeper服务
bin/zookeeper-server-start.sh -daemon config/zookeeper.properties
配置kafka：
1、vim ./config/server.properties
必须的配置有三项：
broker.id=
每一个broker在集群中的唯一表示，要求是正数，kafka及其根据id来识别broker机器
log.dirs=
kafka数据的存放地址，多个地址的话用逗号分割/kafka/kafka-logs-1，/kafka/kafka-logs-2
zookeeper.connect=
zookeeper.connection.timeout.ms=6000 连接超时
num.partitions=1 默认分区
default.replication.factor =1 默认副本数
log.retention.hours=168
message.max.bytes =6525000
表示消息体的最大大小，单位是字节
num.network.threads =3 默认
broker处理消息的最大线程数，一般情况下不需要去修改
num.io.threads =8 默认
broker处理磁盘IO的线程数
queued.max.requests =500 默认
等待IO线程处理的请求队列最大数，若是等待IO的请求超过这个数值，那么会停止接受外部消息
socket.send.buffer.bytes=102400 默认
socket的发送缓冲区，socket的调优参数SO_SNDBUFF
socket.receive.buffer.bytes =102400 默认
socket的接受缓冲区，socket的调优参数SO_RCVBUFF
socket.request.max.bytes =104857600
socket请求的最大数值，防止serverOOM，message.max.bytes必然要小于socket.request.max.bytes
log.segment.bytes =104857600
topic的分区是以一堆segment文件存储的，这个控制每个segment的大小，会被topic创建时的指定参数覆盖
log.roll.hours =168
这个参数会在日志segment没有达到log.segment.bytes设置的大小，也会强制新建一个segment会被topic创建时的指定参数覆盖
num.recovery.threads.per.data.dir=1 启动时用于日志恢复和关闭时刷新的每个数据目录的线程数
replica.lag.time.max.ms =10000
replicas响应partition leader的最长等待时间，若是超过这个时间，就将replicas列入ISR(in-sync replicas)，并认为它是死的
启动kafka（可修改启动脚本里面的KAFKA_HEAP_OPTS jvm参数）
./kafka-server-start.sh -daemon …/config/server.properties
常见操作：
可使用kafka-manager工具管理kafka
./zookeeper-shell.sh 10.157.5.19:2181 连接zookeeper
./kafka-topics.sh --bootstrap-server 10.157.5.19:9092 --list 列出所有topic
./kafka-topics.sh --describe --bootstrap-server 10.157.5.19:9092 --topic mds_quotes 查看一个topic详情
kafka-consumer-groups.sh --bootstrap-server 10.1.1.1:9092 --list 查看由那些消费者组
/kafka-consumer-groups.sh --describe --bootstrap-server 10.1.1.1:9092 --group usercenter 查看改组具体的消费情况