java八股文-消息中间件面试题-参考回答

要开心吖ZSH

已于 2024-07-15 23:59:03 修改

阅读量912

点赞数 14

分类专栏： java面试八股文文章标签： java 开发语言面试

于 2024-07-15 23:57:23 首次发布

本文链接：https://blog.csdn.net/ZhShH0413/article/details/140452212

版权

java面试八股文专栏收录该内容

2 篇文章 0 订阅

订阅专栏

消息中间件面试题-参考回答

面试官：RabbitMQ-如何保证消息不丢失

在这里插入图片描述

候选人：

嗯！我们当时MYSQL和Redis的数据双写一致性就是采用RabbitMQ实现同步的，这里面就要求了消息的高可用性，我们要保证消息的不丢失。主要从三个层面考虑

第一个是开启生产者确认机制，确保生产者的消息能到达队列，如果报错可以先记录到日志中，再去修复数据

第二个是开启持久化功能，确保消息未消费前在队列中不会丢失，其中的交换机、队列、和消息都要做持久化

第三个是开启消费者确认机制为auto，由spring确认消息处理成功后完成ack，当然也需要设置一定的重试次数，我们当时设置了3次，如果重试3次还没有收到消息，就将失败后的消息投递到异常交换机，交由人工处理

面试官：RabbitMQ消息的重复消费问题如何解决的

候选人：

嗯，这个我们还真遇到过，是这样的，我们当时消费者是设置了自动确认机制，当服务还没来得及给MQ确认的时候，服务宕机了，导致服务重启之后，又消费了一次消息。这样就重复消费了

因为我们当时处理的支付（订单|业务唯一标识），它有一个业务的唯一标识，我们再处理消息时，先到数据库查询一下，这个数据是否存在，如果不存在，说明没有处理过，这个时候就可以正常处理这个消息了。如果已经存在这个数据了，就说明消息重复消费了，我们就不需要再消费了

面试官：那你还知道其他的解决方案吗？

候选人：

嗯，我想想~

其实这个就是典型的幂等的问题，比如，redis分布式锁、数据库的锁都是可以的

幂等性设计是解决消息队列（MQ）重复消费问题的关键策略之一，确保同一个消息被多次消费时，其结果与消费一次的效果相同。下面分别通过Redis分布式锁和数据库乐观锁/悲观锁两种方式来说明如何实现幂等性处理。

### Redis分布式锁

#### 实现思路：

1. **获取锁**：在消息消费处理逻辑开始之前，尝试在Redis中获取一个锁。锁的键可以由消息ID生成，确保每个消息对应一个唯一的锁。
   
2. **执行业务逻辑**：如果成功获取锁，则执行具体的业务处理逻辑。处理完成后，需要确保释放锁。

3. **失败重试与锁超时**：如果获取锁失败，可以根据情况选择直接放弃本次消费（适用于非关键业务）、等待一段时间后重试，或者记录失败重新入队。同时，设置合理的锁超时时间，防止因异常导致锁无法自动释放。

#### 代码示例（伪代码）：

```python
import redis
r = redis.Redis(host='localhost', port=6379, db=0)

def consume_message(message_id):
    lock_key = f"lock:message:{message_id}"
    acquired_lock = r.set(lock_key, 1, nx=True, ex=60)  # 尝试获取锁，设置过期时间为60秒
    
    if not acquired_lock:
        print("Lock already exists, skipping message.")
        return
    
    try:
        # 执行业务逻辑
        process_message(message_id)
    finally:
        r.delete(lock_key)  # 无论成功还是失败，都要确保释放锁
```

### 数据库乐观锁/悲观锁

#### 乐观锁：

乐观锁不直接锁定记录，而是在更新时检查数据是否被其他事务修改过。通常通过在表中添加一个版本字段（version）来实现。

#### 实现思路：

1. **读取数据时获取版本号**：在消息消费开始时，先从数据库读取待处理记录及其版本号。

2. **更新数据时校验版本**：执行更新操作时，同时在SQL中包含版本号的条件判断，只有当版本号未变时才允许更新。

#### 代码示例（SQL）：

假设有一个订单表`orders`，包含`id`, `status`, `version`等字段。

```sql
-- 假设这是消费消息时执行的SQL更新语句
UPDATE orders 
SET status = 'processed', version = version + 1 
WHERE id = ? AND version = ?;
```

如果更新影响的行数为0，说明该记录已经被其他事务修改过，此时可以选择重试或者记录错误并忽略这次消费。

#### 悲观锁：

悲观锁直接在查询时锁定数据，假定会发生并发冲突，适用于写操作远多于读操作的场景。

#### 实现思路：

1. **获取锁**：在查询数据时使用`SELECT ... FOR UPDATE`语句锁定记录。

2. **执行业务逻辑**：处理业务逻辑后提交事务，解锁数据。

#### 注意：

- **适用场景**：乐观锁适用于并发竞争不太激烈，大部分情况下不会发生并发冲突的场景；悲观锁适用于并发写入频繁，冲突较多的场景。
- **资源消耗**：乐观锁相对轻量级，不会阻塞其他读操作；悲观锁可能会造成更多的阻塞，影响系统吞吐量。

通过上述两种方法，可以在消息队列消费过程中有效地解决重复消费导致的数据不一致问题，实现幂等性处理。

MySQL中的乐观锁和悲观锁各有其适用场景，具体选择取决于业务需求和并发情况：

乐观锁：

适用场景：乐观锁适合读多写少的场景。在这样的场景中，数据冲突相对较少，通过版本控制或其他机制来判断数据在读取后是否被修改，可以在大多数情况下避免不必要的加锁开销，从而提高系统的吞吐量和响应速度。乐观锁常见于那些并发访问不是非常激烈，且追求高读性能的系统中，如社交网络的好友关系更新、商品库存查询多于修改的情况。
特点：乐观锁在操作数据时并不会立即进行加锁，而是在数据提交更新时检查在此期间是否有其他事务修改过该数据。若数据未被修改，则更新成功；若已被修改，则通常会进行重试或返回错误。

悲观锁：

适用场景：悲观锁适用于写多读少或者并发写入频繁、竞争激烈的场景。当系统预计数据会发生较高的并发冲突时，悲观锁通过在事务开始时立即锁定数据，确保数据的一致性和完整性，避免了脏读问题。这种机制适用于银行交易、库存管理等对数据准确性要求极高的系统。
特点：悲观锁采取了一种保守策略，认为每次数据操作都可能产生并发冲突，因此在数据被读取时就立即加锁，阻止其他事务对数据的访问直至当前事务结束。这虽然能有效防止并发冲突，但可能增加锁等待的时间，降低系统的并发性能。

总之，乐观锁适用于并发冲突较少、读操作远多于写操作的场景，以减少加锁带来的性能损耗；而悲观锁适用于并发冲突频繁、对数据一致性和完整性的要求高于系统吞吐量的场景。正确选择和应用锁机制，可以有效地平衡数据安全与系统性能之间的关系。

面试官：RabbitMQ中死信交换机 ? （RabbitMQ延迟队列有了解过嘛）

候选人：

嗯！了解过！

我们当时的xx项目有一个xx业务，需要用到延迟队列，其中就是使用RabbitMQ来实现的。

延迟队列就是用到了死信交换机和TTL（消息存活时间）实现的。

如果消息超时未消费就会变成死信，在RabbitMQ中如果消息成为死信，队列可以绑定一个死信交换机，在死信交换机上可以绑定其他队列，在我们发消息的时候可以按照需求指定TTL的时间，这样就实现了延迟队列的功能了。

我记得RabbitMQ还有一种方式可以实现延迟队列，在RabbitMQ中安装一个死信插件，这样更方便一些，我们只需要在声明交互机的时候，指定这个就是死信交换机，然后在发送消息的时候直接指定超时时间就行了，相对于死信交换机+TTL要省略了一些步骤

面试官：如果有100万消息堆积在MQ , 如何解决 ?

候选人：

我在实际的开发中，没遇到过这种情况，不过，如果发生了堆积的问题，解决方案也所有很多的

第一:提高消费者的消费能力 ,可以使用多线程消费任务

第二：增加更多消费者，提高消费速度

使用工作队列模式, 设置多个消费者消费消费同一个队列中的消息

第三：扩大队列容积，提高堆积上限

可以使用RabbitMQ惰性队列，惰性队列的好处主要是

①接收到消息后直接存入磁盘而非内存

②消费者要消费消息时才会从磁盘中读取并加载到内存

③支持数百万条的消息存储

面试官：RabbitMQ的高可用机制有了解过嘛

候选人：

嗯，熟悉的~

我们当时项目在生产环境下，使用的集群，当时搭建是镜像模式集群，使用了3台机器。

镜像队列结构是一主多从，所有操作都是主节点完成，然后同步给镜像节点，如果主节点宕机后，镜像节点会替代成新的主节点，不过在主从同步完成前，主节点就已经宕机，可能出现数据丢失

面试官：那出现丢数据怎么解决呢？

候选人：

我们可以采用仲裁队列，与镜像队列一样，都是主从模式，支持主从数据同步，主从同步基于Raft协议，强一致。

并且使用起来也非常简单，不需要额外的配置，在声明队列的时候只要指定这个是仲裁队列即可

面试官：Kafka是如何保证消息不丢失

候选人：

嗯，这个保证机制很多，在发送消息到消费者接收消息，在每个阶段都有可能会丢失消息，所以我们解决的话也是从多个方面考虑

第一个是生产者发送消息的时候，可以使用异步回调发送，如果消息发送失败，我们可以通过回调获取失败后的消息信息，可以考虑重试或记录日志，后边再做补偿都是可以的。同时在生产者这边还可以设置消息重试，有的时候是由于网络抖动的原因导致发送不成功，就可以使用重试机制来解决

第二个在broker中消息有可能会丢失，我们可以通过kafka的复制机制来确保消息不丢失，在生产者发送消息的时候，可以设置一个acks，就是确认机制。我们可以设置参数为all，这样的话，当生产者发送消息到了分区之后，不仅仅只在leader分区保存确认，在follwer分区也会保存确认，只有当所有的副本都保存确认以后才算是成功发送了消息，所以，这样设置就很大程度了保证了消息不会在broker丢失

第三个有可能是在消费者端丢失消息，kafka消费消息都是按照offset进行标记消费的，消费者默认是自动按期提交已经消费的偏移量，默认是每隔5s提交一次，如果出现重平衡的情况，可能会重复消费或丢失数据。我们一般都会禁用掉自动提价偏移量，改为手动提交，当消费成功以后再报告给broker消费的位置，这样就可以避免消息丢失和重复消费了

生产端：ack设置为-1，保证消息同步到follower副本。发送消息方式设置为同步或者异步，做好失败回滚措施

broker端：页缓存pagecache设置直接刷盘模式，确保不会有消息在页缓存中的时候宕机。

消费端：关闭消息自动提交，改为手动提交。避免消息没消费完就提交了offset导致消息丢失

acks=0:
这种设置意味着生产者在消息发送后不会等待任何来自服务器的确认。这意味着生产者无法确定消息是否已经到达任何一个broker，甚至是否已经离开生产者的网络栈。这种方式提供了最低的延迟，但同时消息丢失的风险最高，因为它不保证消息的持久化。

acks=1:
当设置为1时，生产者会等待leader分区的副本确认接收到消息。一旦leader副本确认接收，生产者就会认为消息发送成功，而不管其他follower副本是否已经接收。这种方式相比acks=0提供了更好的可靠性，因为至少保证了消息被leader存储，但仍然存在leader故障后数据丢失的风险。

acks=all 或 acks=-1:
这是最强的确认模式，也是你提到的设置。在这种模式下，生产者会等待所有参与复制的副本（包括leader和所有follower）确认接收到消息。只有当所有副本都确认消息被接收后，生产者才会认为消息发送成功。这种方式提供了最高的消息可靠性，因为即使leader失败，也有follower可以接替成为新的leader，保证数据不丢失。但这也是延迟最高的设置，因为它需要等待所有副本的响应

面试官：Kafka中消息的重复消费问题如何解决的

候选人：

kafka消费消息都是按照offset进行标记消费的，消费者默认是自动按期提交已经消费的偏移量，默认是每隔5s提交一次，如果出现重平衡的情况，可能会重复消费或丢失数据。我们一般都会禁用掉自动提价偏移量，改为手动提交，当消费成功以后再报告给broker消费的位置，这样就可以避免消息丢失和重复消费了

为了消息的幂等，我们也可以设置唯一主键来进行区分，或者是加锁，数据库的锁，或者是redis分布式锁，都能解决幂等的问题

面试官：Kafka是如何保证消费的顺序性

候选人：

kafka默认存储和消费消息，是不能保证顺序性的，因为一个topic数据可能存储在不同的分区中，每个分区都有一个按照顺序的存储的偏移量，如果消费者关联了多个分区不能保证顺序性

如果有这样的需求的话，我们是可以解决的，把消息都存储同一个分区下就行了，有两种方式都可以进行设置，第一个是发送消息时指定分区号，第二个是发送消息时按照相同的业务设置相同的key，因为默认情况下分区也是通过key的hashcode值来选择分区的，hash值如果一样的话，分区肯定也是一样的

面试官：Kafka的高可用机制有了解过嘛

候选人：

嗯，主要是有两个层面，第一个是集群，第二个是提供了复制机制

kafka集群指的是由多个broker实例组成，即使某一台宕机，也不耽误其他broker继续对外提供服务

复制机制是可以保证kafka的高可用的，一个topic有多个分区，每个分区有多个副本，有一个leader，其余的是follower，副本存储在不同的broker中；所有的分区副本的内容是都是相同的，如果leader发生故障时，会自动将其中一个follower提升为leader，保证了系统的容错性、高可用性