Kafka概述

kafka学习目录：kafka目录

---

一、kafka概述和基础架构

Kafka官网主页

Kafka官方文档

1.1、定义

Kafka 是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。

1.2、先来看一下消息队列

1.2.1、传统消息队列的应用场景

使用消息队列的好处

1. 解耦（类似Spring的IOC）
   • 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
2. 可恢复性
   • 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
3. 缓冲
   • 有助于控制和优化数据流经过系统的速度， 解决生产消息和消费消息的处理速度不一致的情况。（一般情况下多是生产的速度大于消费的速度）
4. 灵活性 & 峰值处理能力（削峰）
   • 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
5. 异步通信
   • 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

1.2.2、消息队列的两种模式

点对点模式

一对一，消费者主动拉取数据，消息收到后消息清除

消息生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。消息被消费以后， queue 中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue 支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

缺陷：不能复用，消息如果要给多个消费者用（要有多个队列），就会很麻烦。

发布/订阅模式

一对多，消费者消费数据之后不会清除消息

消息生产者（发布）将消息发布到 topic 中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到 topic 的消息会被所有订阅者消费。

消息队列会保存消息，但是有时间限制（可配置的），不能一直保存的。

优点：消息可以传给多个消费者使用。

该种模式下有几个关键点：生产者的速度，队列的推送速度，消费者的消费速度，如果这三者的速度相差很大，是很容易出问题的，所以发布订阅模式下又有两种模式：

• 消费者主动拉取消息，这个模式下，消费者要维护一个长轮询不断地去询问队列中是否有消息，不管里面有没有消息，所有可能会造成资源浪费。（kafka采用的模式）
• 队列主动推送数据，这个模式下要注意，如果各个消费者的消费速率不一样，比较小的会出现系统崩溃的情况，速率比较大的会造成资源浪费。（公众号采用的模式）

1.3、基础架构

1. Producer ： 消息生产者，就是向 kafka broker 发消息的客户端 ；
2. Consumer ： 消息消费者，向 Kafka broker 取消息的客户端；
3. Consumer Group （CG）： 消费者组，由多个 consumer 组成。 消费者组内每个消费者负责消费不同分区的数据，同一个分区同时只能由一个组内消费者消费；消费者组之间互不影响。 所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。 （消费者组可以提高消费能力，一般情况下，一个组内的消费者个数应该和一个topic内的分区数相同，这样才是最合适，不会浪费资源，也不会出现消费不过来的情况）。
4. Broker ：经纪人（服务器），一台 Kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker可以容纳多个 topic。
5. Topic ： 话题，可以理解为一个队列， 生产者和消费者面向的都是一个 topic；
6. Partition： 分区，为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列；
   1. （一个主题，多个分区，并放在多个服务器上，提高了kafka集群的负载均衡能力，同时也提高了并发读写能力）。
   2. （对于生产者推消息和消费者用消息和分区之间都有对应的分区策略）。
   3. topic是逻辑上的概念，Partition是物理上的概念。
7. Replica： 副本（Replication），为保证集群中的某个节点发生故障时， 该节点上的 partition 数据不丢失，且 Kafka仍然能够继续工作， Kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。
8. Leader： 每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。
9. Follower： 每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。 leader 发生故障时，某个 Follower 会成为新的 leader。（起到备份作用，为了在分布式系统下满足高可靠，高可用）。
10. zookeeper：存储kafka集群（集群信息）、消费者的信息（记录消费位置）。但是0.9版本之前信息存储在zookeeper中；0.9之后，存储在kafka中，一个系统的topic中（磁盘中），该topic是由系统维护的。为什么要改呢？消费者本身是由kafka中的分区leader通信的，消费者在kafka获取消息的同时还要维护者与zookeeper的连接，消费者拉取消息是很频繁的，每一次都要去访问zookeeper，对zookeeper造成了很大的压力。