kafka入门学习

转自：https://mp.weixin.qq.com/s/_RIvZwK1sJJP8xnUDyAk1Q，讲的很好

https://www.cnblogs.com/cxuanBlog/p/11949238.html

1.介绍

消息队列是系统设计中一个最简单实用的技巧：加中间层。没有什么问题是加一个中间层服务解决不了的，如果真解决不了，那就加两层。

消费模型又分两种： 

• 1、点对点模式，也叫队列模式。即每条消息只会被一个消费者消费。
• 2、发布订阅（Pub/Sub）模式。发送到某个 Topic 的消息，会分发给所有订阅该 Topic 的消费者进行消费。（消费者群组）

一个成熟的消息队列应该同时支持上述两种消费模型。并且有自己的持久化存储系统，能够把消息存储下来，方便后续的回溯、分析等操作。

主要作用：

• 1、解耦。使得服务之间的拓扑关系简单了很多。
• 2、削峰/异步化。消息队列可以把大量不需要实时处理的数据暂存下来，等待消费者慢慢消费。

使用场景：

1. 活动跟踪：Kafka 可以用来跟踪用户行为。如登录淘宝时，你的登陆信息，登陆次数都会作为消息传输到 Kafka ，浏览商品、购物爱好等信息作为一个个消息传递给 Kafka ，这样就可以生成报告，可以做智能推荐，购买喜好等。
2. 传递消息，基本用途。
3. 度量指标，记录运营监控数据，用于报告和报警。
4. 日志记录。
5. 限流削峰：Kafka 多用于互联网领域某一时刻请求特别多的情况下，可以把请求写入Kafka 中，避免直接请求后端程序导致服务崩溃。

要求：

1. 高性能。不能成为系统瓶颈。
2. 高可用，单点坏了不能影响整个系统。
3. 数据可靠性。在各种极端情况下（比如突然断网、突然断电），要保证已经收到的消息成功储存（一般是指落到磁盘中）。
4. 可扩展。能对集群进行灵活的扩缩容。

2.架构

一些名词： broker、topic、partition、replica

producer 和 customer 可以选定 Kafka 的某些 topic 中投递和消费消息，但 topic 其实只是个逻辑概念，topic 下面分为多个 partition，消息是真正存在 partition 中的，每个 partition 会分配给一个 broker 节点管理：

所谓 broker 节点，就是一个服务进程。简单来说，把一个 broker 节点理解为一台服务器，把 partition 理解为这台服务器上的一个文件就行了。发到 topic 的消息实际上是发给了某个 broker 服务器，然后被持久化存储到一个文件里，我们一般称这个文件是 log file。

给一个 topic 分配多个 partition ，目的是可以把这个 topic 上的消息分配到多台 broker 的 partition 上，每个 broker 处理消息并将消息持久化存储到 log file 中，从而提高单 topic 的数据处理能力。一个独立的 Kafka 服务器就被称为 broker，broker 接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。

如何保证上述第二点，高可用？如果一个broker挂掉了，那么对应的 partition 上的数据就无法访问了吗？

一般都是通过「数据冗余」和「故障自动恢复」来保证高可用，Kafka 会对每个 partition 维护若干冗余副本Replica：

 若干个 partition 副本中，有一个 leader 副本（图中红色的），其余都是 follower 副本（也可称为 replica，图中橙色的）。【看起来像数据库的主从关系。】

leader负责向生产者和消费者提供订阅发布服务，负责持久化存储消息，同时还要把最新的消息同步给所有 follower，让 follower 小弟们和自己存储的数据尽可能相同。这样的话，如果 leader挂了，就能从 follower 中选取一个副本作为新的 leader，继续对外提供服务。

 push和pull分别用于向broker发送和订阅消息，Zookeeper集群管理broker集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance（？）。

Prodcuer举例：web前端产生的Page View，或者是服务器日志，系统CPU、Memory等；broker支持水平扩展，数量越多，说明集群吞吐率越高。

3.相关参数配置

3.1 broker端 

• broker.id：每个 kafka broker 都有一个唯一的标识来表示，这个唯一的标识符即是 broker.id，它的默认值是 0。这个值在 kafka 集群中必须是唯一的，值可以任意设定。
• port：默认监听9092端口。【意思是producer和consumer都和这个端口连接？那不会乱吗？有send区和receive区两者分开？】
• zookeeper.connect：表示用于保存 broker 元数据的 Zookeeper 地址，格式是hostname:port/path，hostname 是 Zookeeper 服务器的机器名或者 ip 地址，port 是 Zookeeper 客户端的端口号，/path 是可选择的 Zookeeper 路径。
• log.dirs：用于指定消息保存在磁盘上的位置。如/home/kafka1,/home/kafka2,/home/kafka3。【也就是存topic的所有partition的数据？】
• num.recovery.threads.per.data.dir：默认情况下，每个日志目录（log.dirs）只使用一个线程。主要在启动和崩溃重启时，用于打开和保存log.dirs的数据。如果 num.recovery.threads.per.data.dir 被设为 8，并且 log.dir 指定了 3 个路径，那么总共需要 24 个线程。

3.2 topic端

• num.partitions：指定了新创建的主题需要包含多少个分区，默认是1。【那么如何确定partitions都在哪个broker上呢？】
• default.replication.factor：表示 kafka保存消息的副本数，如果一个副本失效了，另一个还可以继续提供服务，默认是1。
• log.retention.ms：通常根据时间来决定数据可以保留多久，决定消息多久以后被删除，默认是 168 个小时，也就是一周。
• log.retention.bytes：表示一个主题单个分区partition日志的最大限制，如果有一个包含 8 个分区的主题，并且 log.retention.bytes 被设置为 1GB，那么这个主题最多可以保留 8GB 数据。
• log.segment.bytes：同样是作用在单个分区partition日志上，当消息到达 broker 时，它们被追加到分区的当前日志片段上，当日志片段大小到达 log.segment.bytes 指定上限（默认为 1GB）时，当前日志片段就会被关闭，一个新的日志片段被打开。如果一个日志片段被关闭，就开始等待过期。这个参数的值越小，就越会频繁的关闭和分配新文件，从而降低磁盘写入的整体效率。