NestJS Kafka消费者相互等待回复时失败的解决方案咨询

使用NestJS微服务结合Kafka时，出现两个消费者处理消息时互相依赖对方数据，最终导致死锁挂起的问题：

用户微服务代码 #

@EventPattern('get_user')
async getUser() {
  const user = { id: 1, name: 'John' };
  const booksByUser = await firstValueFrom(
    this.userClient.send('get_books_by_user', '')
  );

  return { user, books: booksByUser };
}

@MessagePattern('get_author')
getAuthor() {
  return { id: 1, name: 'John' };
}

书籍微服务代码 #

@EventPattern('get_book')
async getBook() {
  const book = { id: 99, name: 'Lorem ipsum' };
  const author = await firstValueFrom(
    this.paymentClient.send('get_author', '')
  );

  return { book, author };
}

@MessagePattern('get_books_by_user')
getBooksByUser() {
  return [{ id: 99, name: 'Lorem ipsum' }];
}

当同时触发以下事件时：

this.kafkaClient.emit('get_user', '');
this.kafkaClient.emit('get_book', '');

两个消费者会互相等待对方的回复，进入永久挂起状态，停止发送心跳后被Kafka协调器标记为失败。目前设置了5秒超时，但会导致分区长时间阻塞，寻求更优解决方案：是否改用HTTP/gRPC替代消费者间通信？或优化超时机制？还是增加更多消费者？

针对这类循环依赖导致的死锁问题，以下是不同方案的分析和建议：

1. 从业务逻辑消除同步阻塞 #

死锁的核心是同步循环依赖：get_user阻塞等待书籍服务的响应，get_book阻塞等待用户服务的响应，两个请求同时触发时形成闭环。

• 拆分接口职责：比如get_user只返回用户基础信息，用户关联的书籍列表通过单独的接口或异步事件返回，避免在事件处理中同步调用依赖服务。
• 改用异步事件驱动：将同步的send调用改为异步emit，消费者处理完数据后通过独立主题推送结果，调用方监听对应主题获取后续数据，而非原地等待回复。

2. 优化Kafka消费者配置 #

如果必须保留同步调用逻辑，可以通过配置避免分区阻塞：

• 给跨服务调用的MessagePattern接口设置独立消费者组：默认情况下同微服务的消费者共享一个组，单个消费者阻塞会导致同分区消息无法处理。给get_author、get_books_by_user这类接口单独配置消费者组，并增加消费者实例数量，确保即使某个消费者被阻塞，其他实例仍能处理请求。
  示例配置：

  @MessagePattern('get_books_by_user', { consumer: { groupId: 'books-by-user-request-group' } })
  getBooksByUser() {
    return [{ id: 99, name: 'Lorem ipsum' }];
  }
  

3. 改用gRPC/HTTP进行跨服务同步调用 #

如果业务逻辑必须依赖强一致性的同步响应，改用gRPC或HTTP更适配：

• Kafka的核心定位是异步事件流处理，并不擅长同步请求/响应场景，尤其是循环依赖的同步调用。gRPC/HTTP专为同步请求设计，内置成熟的超时、重试机制，不会出现Kafka消费者组的分区阻塞问题。
• 注意：改用HTTP/gRPC会提升服务间耦合度，需要配合服务发现、熔断器等机制保障容错性。

最佳实践建议 #

优先选择方案1，从业务逻辑层面消除循环依赖和同步阻塞，契合Kafka的事件驱动设计理念。若必须保留同步调用，优先用方案2优化消费者配置，最后再考虑切换到gRPC/HTTP。

内容的提问来源于stack exchange，提问作者Đoàn Ngọc Sơn