Kafka的消息队列服务 下载 kafka实现消息队列

目录

• 一.什么是Kafka

• 1.定义
• 2.什么是MQ

• MQ的好处

• 二.消息队列两种模式

• 点对点模式
• 发布/订阅模式

• 三.消息队列基础架构

• 概念解释
• 概念总结：

一.什么是Kafka

1.定义

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

特征:

1. Kafka作为一个集群，运行在一台或者多台服务器上.
2. Kafka 通过 topic 对存储的流数据进行分类。
3. 每条记录中包含一个key，一个value和一个timestamp（时间戳）。

2.什么是MQ

“消息队列”是在消息的传输过程中保存消息的容器。

实际上MQ跟字面意思一样，就是一个队列，其中的内容是各种消息/信息（数据）。

典型应用场景之异步处理：

• 同步和异步概念：同步就是需要一直等着收到回复，异步就是发出一个请求，等待对方回调/通知自己。

MQ的好处

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

二.消息队列两种模式

点对点模式

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

• 问题：无法复用消息，消息消费完就被删掉了

发布/订阅模式

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

问题:

1. 不同消费者的消费速度（处理能力）不一样，有可能浪费或者扛不住数据量
2. 分为两种：

• 消费者主动拉取
• 队列主动推送

Kafka是基于消费者主动拉取模式的，由消费者根据自己的处理能力主动拉取。 但是这样涉及大量的消费者和队列的通信连接，浪费资源，维护长轮询

三.消息队列基础架构

概念解释

1. Kafka Cluster集群里面是多个Broker，Broker可以理解为Kafka的服务器
2. Broker中有多个Topic，Topic可以理解为对消息进行分类，这样可以选择性获取不同的数据，不能把所有数据都堆在一个地方
3. 不同的Topic在不同的分区Partition，一个Topic可能对应多个分区。这样通过负载均衡，可以提高某一个Topic的承载能力和并发能力
4. Leader和Follower的角色是分别在不同的Broker中，是用来备份的，可以提高系统的可用性。Leader和Follower一定不在一个机器（Broker）里面，Follower只提供备份，消费只用leader
5. 一个分区Partition的数据，只能被一个消费者组（consumer group）中的某一个消费者消费

• 同一个消费者组（consumer group）之间的consumer不能消费同一个分区数据。举例：consumer A消费了TopicA Partition0的数据，此时consumer C可以消费，但是consumer B就不能消费了

6. consumer还要存储一个数据：比如consumer消费了5条数据后宕机，恢复之后要能记住自己需要从第六条开始消费，也就是偏移量offset，这个数据保存在zookeeper中（0.9版本之前）。0.9版本之后存储在kafka中。

概念总结：

1. Producer :消息生产者，就是向 kafka broker 发消息的客户端;
2. Consumer :消息消费者，向 kafka broker 取消息的客户端;
3. Consumer Group (CG):消费者组，由多个 consumer 组成。消费者组内每个消费者负 责消费不同分区的数据，一个分区只能由一个组内消费者消费;消费者组之间互不影响。所 有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
4. Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。
5. Topic :可以理解为一个队列，生产者和消费者面向的都是一个 topic;
6. Partition:为了实现扩展性，一个非常大的 topic 可以分布到多个 broker(即服务器)上， 一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列;
7. Replica:副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失，且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本， 一个 leader 和若干个 follower。
8. leader:每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对 象都是 leader。
9. follower:每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据 的同步。leader 发生故障时，某个 follower 会成为新的 follower。

为什么Kafka不像MySQL那样允许追随者副本对外提供读服务？

原因一：读数据压力方面：

• Kafka 的 Partition 分布在多个broker，当 Comsuer 消费数据的Partiton
  是被分配到不同的Broker上，已经是负载均衡之后的请求。
• Mysql读写数据都在主DB上，主DB请求压力太大，所以需要读写分离进行负载均衡。

原因二：数据一致性问题：

• Kafka 的副本机制是异步消息拉取，因此就存在 Leader 和 Follwer 之间的不一致性。并且Kafka保存的数据具有消费的概念，是流数据，具有严格的顺序要求，所以消费需要 Offset。如果从Kafka的多个Follwer进行读，Offset无法保证正确性。
• Mysql主从数据同步在处理得当的情况下，在读数据的情况下是很少感受不到主从数据不一致。

原因三：应用场景：

• Mysql在针对就是读频繁，写较少的的场景下，所以采用读写分离是很不错的方案。
• Kafka的使用场景更多情况是消息引擎而不是作为数据存储对外提供读服务，通常涉及到频繁的生产消息和消费消息，不属于读多写少的场景，因此读写分离不适用这个Kafka。