恕我直言：你可能一直用错了 kafka 的重试机制

Apache Kafka 已成为跨微服务异步通信的主流平台。它有很多强大的特性，让我们能够构建健壮、有弹性的异步架构。

同时，我们在使用它的过程中也需要小心很多潜在的陷阱。如果未能提前发现可能发生（换句话说就是迟早会发生）的问题，我们就要面对一个容易出错和损坏数据的系统了。

在本文中，我们将重点介绍其中的一个陷阱：尝试处理消息时遭遇失败。首先，我们需要意识到消息消费可能会，而且迟早会遭遇失败。其次，我们需要确保在处理此类故障时不会引入更多问题。

Kafka 简介

阅读本文的读者应该都对 Kafka 有所了解。网上也有一些介绍 Kafka 及其使用方法的深度文章。话虽如此，我们这里还是先简要回顾一下对我们的讨论很重要的一些概念。

事件日志、发布者和消费者

Kafka 是用来处理数据流的系统。从概念上讲，我们可以认为 Kafka 包含三个基本组件：

• 一个 事件日志（Event Log） ，消息会发布到它这里
• 发布者（Publisher），将消息发布到事件日志
• 消费者（Consumer），消费（也就是使用）事件日志中的消息

 

与 RabbitMQ 之类的传统消息队列不同，Kafka 由消费者来决定何时读取消息（也就是说，Kafka 采用了拉取而非推送模式）。每条消息都有一个 偏移量（offset） ，每个消费者都跟踪（或提交）其最近消费消息的偏移量。这样，消费者就可以通过这条消息的偏移量请求下一条消息。

主题

事件日志分为几个 主题（topic） ，每个主题都定义了要发布给它的消息类型。定义主题是我们这些工程师的责任，所以我们应该记住一些经验法则：

• 每个主题都应描述一个其他服务可能需要了解的事件。
• 每个主题都应定义每条消息都将遵循的一个唯一模式（schema）。

分区和分区键

主题被进一步细分为多个 分区（partition） 。分区使消息可以被并行消费。Kafka 允许通过一个 分区键（partition key） 来确定性地将消息分配给各个分区。分区键是一段数据（通常是消息本身的某些属性，例如 ID），其上会应用一个算法以确定分区。

 

这里，我们将消息的 UUID 字段分配为分区键。生产者应用一种算法（例如按照分区数修改每个 UUID 值）来将每条消息分配给一个分区。

以这种方式使用分区键，使我们能够确保与给定 ID 关联的每条消息都会发布到单个分区上。

还需要注意的是，可以将一个消费者的多个实例部署为一个消费者组。Kafka 将确保给定分区中的任何消息将始终由组中的同一消费者实例读取。

在微服务中使用 Kafka

Kafka 非常强大。所以它可用于多种环境中，涵盖众多用例。在这里，我们将重点介绍微服务架构中最常见的用法。

跨有界上下文传递消息

当我们刚开始构建微服务时，我们许多人一开始采用的是某种中心化模式。每条数据都有一个主流的单一微服务（即单一真实来源）。如果其他任何微服务需要访问这份数据，它将发起一个同步调用以检索它。

这种方法导致了许多问题，包括同步调用链较长、单点故障、团队自主权下降等。

最后我们找到了更好的办法。在今天的成熟架构中，我们将通信分为命令处理和事件处理。

命令处理通常在单个有界上下文中执行，并且往往还是会包含同步通信。

另一方面，事件通常由一个有界上下文中的服务发出，并异步发布到 Kafka，以供其他有界上下文中的服务消费。

 

左侧是我们以前设计微服务通信的方式：一个有界上下文（由虚线框表示）中的服务从其他有界上下文中的服务接收同步调用。右边是我们如今的做法：一个有界上下文中的服务发布事件，其他有界上下文中的服务在自己空闲时消费它们。

例如，以一个 User 有界上下文为例。我们的 User 团队会构建负责启用新用户、更新现有用户帐