kafka入坑指南–消息队列简介-一一网

这是我参与8月更文挑战的第13天，活动详情查看：8月更文挑战

消息队列

为什么要使用消息队列

解耦（类似Spring的IOC）

允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

冗余

有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。

可恢复性

系统的一部分组件失效时，不会影响到整个系统。
消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

缓冲

有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。

灵活性 & 峰值处理能力（削峰）

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

异步通信

很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

在这里插入图片描述

消息队列的两种模式

消息队列分为

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

（1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）

点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。

生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。

消息被消费后就从队列queue移除该消息，所以消费者不可能再消费到

每条消息由一个生产者生产，且只被一个消费者消费（即使该队列有多个消费者）。

生产者和消费者是一对一模式

在这里插入图片描述

（2）发布/订阅模式（一对多，数据生产后，推送给所有订阅者，消费者消费数据之后不会清除消息）

发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。

所有订阅了该主题的消费者都能收到同样的消息

在这里插入图片描述

Zookeeper 简介

Zookeeper是一个分布式协调服务

Zookeeper主要可以干哪些事情：配置管理、名字服务、分布式同步以及集群管理。

配置管理

把公用的配置文件提取出来放到一个地方，对这个地方（目录节点）进行监听，一旦配置信息发生变化，每个应用程序就会收到Zookeeper的通知，然后从Zookeeper获取新的配置信息应用到系统中。

命名服务

注册发现中心

其实从配置管理、命名服务的作用中可以看出，Zookeeper相当于一个文件系统（类似与linux文件系统），换句话说，zookeeper是分布式中的大脑。

分布式锁

在一个分布式环境里，为了提高可靠性，我们的集群中每台服务器上都部署着同样的服务。但是，一件事情如果集群中的每个服务器都进行的话，那相互之间就要协调，编程起来将非常复杂。而如果我们只让一个服务进行操作，那又存在单点。通常还有一种做法就是使用分布式锁，在某个时刻只让一个服务去干活，当这台服务出问题的时候锁释放，立即fail over到另外的服务。

集群管理

在一个分布式存储系统中，有一个中央控制节点负责存储的分配，当有新的存储进来的时候我们要根据现在集群目前的状态来分配存储节点。这个时候我们就需要动态感知到集群目前的状态。

kafka简介

Kafka三层消息架构

第一层是主题层，每个主题可以配置M个分区，而每个分区又可以配置N个副本。
第二层是分区层，每个分区的N个副本中只能有一个充当领导者角色，对外提供服务，其他N-1个副本是追随者副本，知识提供数据冗余之用。
第三层是消息层，分区中包含若干条消息，每条消息的位移从0开始，依次递增。

最后，客户端程序只能与分区的领导者副本进行交互。
在这里插入图片描述

基本概念

producer：生产者。
consumer：消费者。
topic: 主题(Topic)。
broker：节点;消费者可以订阅一个或多个主题(topic), 并从Broker拉数据,从而消费这些已发布的消息。
Consumer Offset(消费者位移)：表示消费者消费进度，每个消费者都有自己的消费者位移。
Consumer Group（消费者组）：多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。

在这里插入图片描述

在这里插入图片描述
规则：

一个topic的消息S 只能被同群中的一个人消费。
- 可以有多个群来消费。
- 但是一个群里面只能有一个人消费。

很好理解，群是集群，外面看是同一个人。

在这里插入图片描述

三种机制

Kafka producer的ack有3中机制，初始化producer时的producerconfig可以通过配置request.required.acks不同的值来实现。

0：这意味着生产者producer不等待来自broker同步完成的确认继续发送下一条（批）消息。此选项提供最低的延迟但最弱的耐久性保证（当服务器发生故障时某些数据会丢失，如leader已死，但producer并不知情，发出去的信息broker就收不到）。
1：这意味着producer在leader已成功收到的数据并得到确认后发送下一条message。此选项提供了更好的耐久性为客户等待服务器确认请求成功（被写入死亡leader但尚未复制将失去了唯一的消息）。
-1：这意味着producer在follower副本确认接收到数据后才算一次发送完成。

此选项提供最好的耐久性，我们保证没有信息将丢失，只要至少一个同步副本保持存活。

三种机制，性能依次递减 (producer吞吐量降低)，数据健壮性则依次递增。