消息中间件笔记 - 02

约定不等于承诺〃 2023-05-31 03:00 12阅读 0赞

> **如何保证消息队列消息不被重复消费**

正常情况下，消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。只是不同的消息队列发出的确认消息形式不同，RabbitMQ是发送一个ACK确认消息，RocketMQ是返回一个CONSUME\_SUCCESS成功标志，Kafka消费过消息后，需要提交offset，让消息队列知道自己已经消费过了。

造成重复消费的原因就是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道已经消费过该消息了，再次将消息分发给其他的消费者。

针对业务场景来答，分以下三种情况

*  拿到这个消息做数据库的新增操作时，给这个消息做一个唯一的主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
 *  拿到这个消息做redis的set的操作时，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。
 *  准备一个第三方介质，来做消费记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将<id,message>以K-V形式写入redis.那消费者开始消费前，先去redis中查询有没有消费记录即可。

> **如何保证消息的顺序性**

针对这个问题，通过某种算法，将需要保持先后顺序的消息放到同一个消息队列中(kafka中就是partition,rabbitMq中就是queue)。然后只用一个消费者去消费该队列。  
有的人会问:那如果为了吞吐量，有多个消费者去消费怎么办？

这个问题，没有固定回答的套路。比如我们有一个微博的操作，发微博、写评论、删除微博，这三个异步操作。如果是这样一个业务场景，那只要重试就行。比如你一个消费者先执行了写评论的操作，但是这时候，微博都还没发，写评论一定是失败的，等一段时间。等另一个消费者，先执行写评论的操作后，再执行，就可以成功。

总之，针对这个问题，我的观点是保证入队有序就行，出队以后的顺序交给消费者自己去保证，没有固定套路。

> **RabbitMQ**

**1、RabbitMQ ****有哪些重要的组件**

*  ConnectionFactory（连接管理器）：应用程序与Rabbit之间建立连接的管理器，程序代码中使用。
 *  Channel（信道）：消息推送使用的通道。
 *  Exchange（交换器）：用于接受、分配消息。
 *  Queue（队列）：用于存储生产者的消息。
 *  RoutingKey（路由键）：用于把生成者的数据分配到交换器上。
 *  BindingKey（绑定键）：用于把交换器的消息绑定到队列上。

**2、RabbitMQ 中 vhost 的作用是什么**

每个 RabbitMQ 都能创建很多 vhost，我们称之为虚拟主机，每个虚拟主机其实都是 mini 版的RabbitMQ，它拥有自己的队列，交换器和绑定，拥有自己的权限机制。

**3、RabbitMQ 的消息是怎么发送的**

首先客户端必须连接到 RabbitMQ 服务器才能发布和消费消息，客户端和 rabbit server 之间会创建一个 tcp 连接，一旦 tcp 打开并通过了认证（认证就是你发送给 rabbit 服务器的用户名和密码），你的客户端和 RabbitMQ 就创建了一条 amqp 信道（channel），信道是创建在“真实” tcp 上的虚拟连接，amqp 命令都是通过信道发送出去的，每个信道都会有一个唯一的 id，不论是发布消息，订阅队列都是通过这个信道完成的。

**4、RabbitMQ 怎么避免消息丢失**

1)、生产者弄丢了数据

RabbitMQ生产者将数据发送到rabbitmq的时候,可能数据在网络传输中搞丢了，这个时候RabbitMQ收不到消息，消息就丢了。

RabbitMQ提供了两种方式来解决这个问题：

事务方式：

在生产者发送消息之前，通过\`channel.txSelect\`开启一个事务，接着发送消息

如果消息没有成功被RabbitMQ接收到，生产者会收到异常，此时就可以进行事务回滚\`channel.txRollback\`然后重新发送。假如RabbitMQ收到了这个消息，就可以提交事务\`channel.txCommit\`。

但是这样一来，生产者的吞吐量和性能都会降低很多，现在一般不这么干。

通过confirm机制：

channel.addConfirmListener(new ConfirmListener() {  
        @Override  
        public void handleNack(long deliveryTag, boolean multiple) throws IOException {  
            System.out.println("nack: deliveryTag = "+deliveryTag+" multiple: "+multiple);  
        }  
    
        @Override  
        public void handleAck(long deliveryTag, boolean multiple) throws IOException {  
            System.out.println("ack: deliveryTag = "+deliveryTag+" multiple: "+multiple);  
        }  
    });

这个confirm模式是在生产者哪里设置的，就是每次写消息的时候会分配一个唯一的id，然后RabbitMQ收到之后会回传一个ack，告诉生产者这个消息ok了。

如果rabbitmq没有处理到这个消息，那么就回调一个nack的接口，这个时候生产者就可以重发。

事务机制和cnofirm机制最大的不同在于事务机制是同步的，提交一个事务之后会阻塞在那儿

但是confirm机制是异步的，发送一个消息之后就可以发送下一个消息，然后那个消息rabbitmq接收了之后会异步回调你一个接口通知你这个消息接收到了。

所以一般在生产者这块避免数据丢失，都是用confirm机制的。

2)、RabbitMQ弄丢了数据

处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。

这样哪怕是宕机了，恢复之后也会自动恢复之前存储的数据，这样的机制可以确保消息不会丢失。

设置持久化有两个步骤：

*  第一个是创建queue的时候将其设置为持久化的，这样就可以保证rabbitmq持久化queue的元数据，但是不会持久化queue里的数据
 *  第二个是发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化的，此时rabbitmq就会将消息持久化到磁盘上去。

但是这样一来可能会有人说：万一消息发送到RabbitMQ之后，还没来得及持久化到磁盘就挂掉了，数据也丢失了，怎么办？

对于这个问题，其实是配合上面的confirm机制一起来保证的，就是在消息持久化到磁盘之后才会给生产者发送ack消息。

万一真的遇到了那种极端的情况，生产者是可以感知到的，此时生产者可以通过重试发送消息给别的RabbitMQ节点

3)、消费端弄丢了数据

RabbitMQ消费端弄丢了数据的情况是这样的：在消费消息的时候，刚拿到消息，结果进程挂了，这个时候RabbitMQ就会认为你已经消费成功了，这条数据就丢了。

对于这个问题，要先说明一下RabbitMQ消费消息的机制：在消费者收到消息的时候，会发送一个ack给RabbitMQ，告诉RabbitMQ这条消息被消费到了，这样RabbitMQ就会把消息删除。

但是默认情况下这个发送ack的操作是自动提交的，也就是说消费者一收到这个消息就会自动返回ack给RabbitMQ，所以会出现丢消息的问题。

所以针对这个问题的解决方案就是：关闭RabbitMQ消费者的自动提交ack,在消费者处理完这条消息之后再手动提交ack。

这样即使遇到了上面的情况，RabbitMQ也不会把这条消息删除，会在你程序重启之后，重新下发这条消息过来。

**5、怎么保证RabbitMQ的高可用性**

**[Rabbitmq集群高可用部署步骤][Rabbitmq]**

Rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式

1)、单机模式

单机模式就是demo级别的，就是说只有一台机器部署了一个RabbitMQ程序。

这个会存在单点问题，宕机就玩完了，没什么高可用性可言。一般就是你本地启动了玩玩儿的，没人生产用单机模式。

2)、普通集群模式

这个模式的意思就是在多台机器上启动多个rabbitmq实例。类似的master-slave模式一样。

但是创建的queue，只会放在一个master rabbtimq实例上，其他实例都同步那个接收消息的RabbitMQ元数据。

在消费消息的时候，如果你连接到的RabbitMQ实例不是存放Queue数据的实例，这个时候RabbitMQ就会从存放Queue数据的实例上拉去数据，然后返回给客户端。

总的来说，这种方式有点麻烦，没有做到真正的分布式，每次消费者连接一个实例后拉取数据，如果连接到不是存放queue数据的实例，这个时候会造成额外的性能开销。如果从放Queue的实例拉取，会导致单实例性能瓶颈。

如果放queue的实例宕机了，会导致其他实例无法拉取数据，这个集群都无法消费消息了，没有做到真正的高可用。

所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。

3)、镜像集群模式

镜像集群模式才是真正的rabbitmq的高可用模式，跟普通集群模式不一样的是：创建的queue无论元数据还是queue里的消息都会存在于多个实例上，

每次写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。

这样的话任何一个机器宕机了别的实例都可以用提供服务，这样就做到了真正的高可用了。

但是也存在着不好之处：

*  性能开销过高，消息需要同步所有机器，会导致网络带宽压力和消耗很重
 *  扩展性低：无法解决某个queue数据量特别大的情况，导致queue无法线性拓展。就算加了机器，那个机器也会包含queue的所有数据，queue的数据没有做到分布式存储。

对于RabbitMQ的高可用一般的做法都是开启镜像集群模式，这样起码来说做到了高可用，一个节点宕机了，其他节点可以继续提供服务。

**6、RabbitMQ 有几种广播类型**

*  direct（默认方式）：最基础最简单的模式，发送方把消息发送给订阅方，如果有多个订阅者，默认采取轮询的方式进行消息发送。
 *  headers：与 direct 类似，只是性能很差，此类型几乎用不到。
 *  fanout：分发模式，把消费分发给所有订阅者。
 *  topic：匹配订阅模式，使用正则匹配到消息队列，能匹配到的都能接收到。

**7、RabbitMQ ****怎么实现延迟消息队列**

延迟队列的实现有两种方式：

*  通过消息过期后进入死信交换器，再由交换器转发到延迟消费队列，实现延迟功能；
 *  使用 RabbitMQ-delayed-message-exchange 插件实现延迟功能。

**8、RabbitMQ 节点的类型有哪些**

*  磁盘节点：消息会存储到磁盘。
 *  内存节点：消息都存储在内存中，重启服务器消息丢失，性能高于磁盘类型。

**9、RabbitMQ 每个节点是其他节点的完整拷贝吗**

不是，原因有以下两个：

*  存储空间的考虑：如果每个节点都拥有所有队列的完全拷贝，这样新增节点不但没有新增存储空间，反而增加了更多的冗余数据；
 *  性能的考虑：如果每条消息都需要完整拷贝到每一个集群节点，那新增节点并没有提升处理消息的能力，最多是保持和单节点相同的性能甚至是更糟。

**10、RabbitMQ 集群中唯一一个磁盘节点崩溃了会发生什么情况**

如果唯一磁盘的磁盘节点崩溃了，不能进行以下操作：

*  不能创建队列
 *  不能创建交换器
 *  不能创建绑定
 *  不能添加用户
 *  不能更改权限
 *  不能添加和删除集群节点

唯一磁盘节点崩溃了，集群是可以保持运行的，但你不能更改任何东西。

**11、RabbitMQ 对集群节点停止顺序有要求吗**

RabbitMQ 对集群的停止的顺序是有要求的，应该先关闭内存节点，最后再关闭磁盘节点。如果顺序恰好相反的话，可能会造成消息的丢失。

**12、RabbitMQ 集群搭建需要注意哪些问题**

*  各节点之间使用“--link”连接，此属性不能忽略。
 *  各节点使用的 erlang cookie 值必须相同，此值相当于“秘钥”的功能，用于各节点的认证。
 *  整个集群中必须包含一个磁盘节点。

**13、交换机**

交换机的功能主要是接收消息并且转发到绑定的队列，交换机不存储消息，在启用ack模式后，交换机找不到队列会返回错误。交换机有四种类型：Direct, topic, Headers and Fanout

*  Direct：direct 类型的行为是"先匹配, 再投送". 即在绑定时设定一个 **routing\_key**, 消息的**routing\_key** 匹配时, 才会被交换器投送到绑定的队列中去.
 *  Topic：按规则转发消息（最灵活）
 *  Headers：设置 header attribute 参数类型的交换机
 *  Fanout：转发消息到所有绑定队列

**1）、Direct Exchange**

Direct Exchange 是 RabbitMQ 默认的交换机模式，也是最简单的模式，根据key全文匹配去寻找队列。

![20191030164740577.png][]

第一个 X - Q1 就有一个 binding key，名字为 orange； X - Q2 就有 2 个 binding key，名字为 black 和 green。*当消息中的 路由键 和 这个 binding key 对应上的时候，那么就知道了该消息去到哪一个队列中。*

Ps：为什么 X 到 Q2 要有 black，green，2个 binding key呢，一个不就行了吗？ - 这个主要是因为可能又有 Q3，而Q3只接受 black 的信息，而Q2不仅接受black 的信息，还接受 green 的信息。

**2）、Topic Exchange**

*Topic Exchange 转发消息主要是根据通配符。* 在这种交换机下，队列和交换机的绑定会定义一种路由模式，那么，通配符就要在这种路由模式和路由键之间匹配后交换机才能转发消息。

在这种交换机模式下：

*  路由键必须是一串字符，用句号（`.`） 隔开，比如说 agreements.us，或者 agreements.eu.stockholm 等。
 *  路由模式必须包含一个 星号（`*`），主要用于匹配路由键指定位置的一个单词，比如说，一个路由模式是这样子：agreements..b.\*，那么就只能匹配路由键是这样子的：第一个单词是 agreements，第四个单词是 b。 井号（\#）就表示相当于一个或者多个单词，例如一个匹配模式是 agreements.eu.berlin.\#，那么，以agreements.eu.berlin 开头的路由键都是可以的。

具体代码发送的时候还是一样，第一个参数表示交换机，第二个参数表示 routing key，第三个参数即消息。如下：

rabbitTemplate.convertAndSend("testTopicExchange","key1.a.c.key2", " this is  RabbitMQ!");

opic 和 direct 类似, 只是匹配上支持了"模式", 在"点分"的 routing\_key 形式中, 可以使用两个通配符:

*  `*`表示一个词.
 *  `#`表示零个或多个词.

**3）、Headers Exchange**

headers 也是根据规则匹配, 相较于 direct 和 topic 固定地使用 routing\_key , headers 则是一个自定义匹配规则的类型.  
在队列与交换器绑定时, 会设定一组键值对规则, 消息中也包括一组键值对( headers 属性), 当这些键值对有一对, 或全部匹配时, 消息被投送到对应队列.

**4）、Fanout Exchange**

Fanout Exchange 消息广播的模式，不管路由键或者是路由模式，*会把消息发给绑定给它的全部队列*，如果配置了 routing\_key 会被忽略。

> **Kafka**

**1、Kafka ****可以脱离 zookeeper 单独使用吗**

Kafka 不能脱离 zookeeper 单独使用，因为 Kafka 使用 zookeeper 管理和协调 kafka 的节点服务器。

**2、Kafka 有几种数据保留的策略**

Kafka 有两种数据保存策略：按照过期时间保留和按照存储的消息大小保留。

**3、Kafka 同时设置了 7 天和 10G 清除数据，到第五天的时候消息达到了 10G，这个时候 Kafka 将如何处理**

这个时候 Kafka 会执行数据清除工作，时间和大小不论那个满足条件，都会清空数据。

**4、什么情况会导致 Kafka 运行变慢**

*  cpu 性能瓶颈
 *  磁盘读写瓶颈
 *  网络瓶颈

**5、使用 Kafka 集群需要注意什么**

集群的数量不是越多越好，最好不要超过 7 个，因为节点越多，消息复制需要的时间就越长，整个群组的吞吐量就越低。  
集群数量最好是单数，因为超过一半故障集群就不能用了，设置为单数容错率更高。

**6、怎么保证Kafka 的高可用性**

kafka一个最基本的架构认识：多个broker组成，每个broker是一个节点；你创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据。

这就是天然的分布式消息队列，就是说一个topic的数据，是分散放在多个机器上的，每个机器就放一部分数据。

实际上rabbitmq之类的，并不是分布式消息队列，他就是传统的消息队列，只不过提供了一些集群、HA的机制而已，因为无论怎么玩儿，rabbitmq一个queue的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个queue的完整数据。

kafka 0.8以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。

kafka 0.8以后，提供了HA机制，就是replica副本机制。每个partition的数据都会同步到吉他机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower。写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上数据即可。只能读写leader？很简单，要是你可以随意读写每个follower，那么就要care数据一致性的问题，系统复杂度太高，很容易出问题。kafka会均匀的将一个partition的所有replica分布在不同的机器上，这样才可以提高容错性。

这么搞，就有所谓的高可用性了，因为如果某个broker宕机了，没事儿，那个broker上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。这就有所谓的高可用性了。

写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）

消费的时候，只会从leader去读，但是只有一个消息已经被所有follower都同步成功返回ack的时候，这个消息才会被消费者读到。

实际上这块机制，讲深了，是可以非常之深入的，但是我还是回到我们这个课程的主题和定位，聚焦面试，至少你听到这里大致明白了kafka是如何保证高可用机制的了，对吧？不至于一无所知，现场还能给面试官画画图。要遇上面试官确实是kafka高手，深挖了问，那你只能说不好意思，太深入的你没研究过。

但是大家一定要明白，这个事情是要权衡的，你现在是要快速突击常见面试题体系，而不是要深入学习kafka，要深入学习kafka，你是没那么多时间的。你只能确保，你之前也许压根儿不知道这块，但是现在你知道了，面试被问到，你大概可以说一说。然后很多其他的候选人，也许还不如你，没看过这个，被问到了压根儿答不出来，相比之下，你还能说点出来，大概就是这个意思了。

> **Zookeeper**

**1、Zookeeper 是什么**

Zookeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 google chubby 的开源实现，是 hadoop 和 hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

**2、Zookeeper 都有哪些功能**

集群管理：监控节点存活状态、运行请求等。  
主节点选举：主节点挂掉了之后可以从备用的节点开始新一轮选主，主节点选举说的就是这个选举的过程，使用 Zookeeper 可以协助完成这个过程。  
分布式锁：Zookeeper 提供两种锁：独占锁、共享锁。独占锁即一次只能有一个线程使用资源，共享锁是读锁共享，读写互斥，即可以有多线线程同时读同一个资源，如果要使用写锁也只能有一个线程使用。Zookeeper可以对分布式锁进行控制。  
命名服务：在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。

**3、Zookeeper 有几种部署模式**

*  单机部署：一台集群上运行；
 *  集群部署：多台集群运行；
 *  伪集群部署：一台集群启动多个 Zookeeper 实例运行。

**4、Zookeeper 怎么保证主从节点的状态同步**

Zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 zab 协议。 zab 协议有两种模式，分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，zab 就进入了恢复模式，当领导者被选举出来，且大多数 server 完成了和 leader 的状态同步以后，恢复模式就结束了。状态同步保证了 leader 和 server 具有相同的系统状态。

**5、集群中为什么要有主节点**

在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，所以就需要主节点。

**6、集群中有 3 台服务器，其中一个节点宕机，这个时候 Zookeeper 还可以使用吗**

可以继续使用，单数服务器只要没超过一半的服务器宕机就可以继续使用。

**7、说一下 Zookeeper 的通知机制**

客户端端会对某个 znode 建立一个 watcher 事件，当该 znode 发生变化时，这些客户端会收到 Zookeeper 的通知，然后客户端可以根据 znode 变化来做出业务上的改变。

[Rabbitmq]: https://www.cnblogs.com/knowledgesea/p/6535766.html
[20191030164740577.png]: /images/20230531/865d7c34cd2f4777b9461ed110c6b0b2.png