急需降低系统复杂性，我们从 Kafka 迁移到了 Pulsar.docxVIP

急需降低系统简单性，我们从 Kafka 迁移到了 Pulsar 2021-02-20 要点总结 分布式消息系统支持流和队列两种语义，这两种语义最适合使用的场景有所不同。 Pulsar 的独特之处在于它同时支持流和队列使用场景。 Pulsar 接受多层架构，可以轻松扩展 topic 的数量和大小，比其他消息系统的操作更便捷。 Pulsar 实现可扩展性、牢靠性和其他特性之间的良好平衡。这有助于替换 Iterable 接受的 RabbitMQ 消息系统，并最终替换其他消息系统（如 Kafka 和 Amazon SQS）。 Iterable 公司每天代表客户发送大量营销消息，包括电子邮件、通知、短信、应用程序消息等，并且每天处理更多的用户数据更新、大事、自定义工作流形态。Iterable 日常处理的很多消息都可能触发系统中的其他操作，从而导致系统越来越简单，产品易用性越来越低。随着客户数量不断添加，降低系统简单性迫在眉睫。 Iterable 可以在架构的某些部分改用分布式消息系统，次要用于存储需要 consumer 处理的消息，追踪 consumer 处理消息时的形态，从而降低系统简单性，保证 consumer 专注于处理消息。 Iterable 使用工作队列执行客户指定的营销工作流、webhooks 和其他类型的工作支配或进展。其他组件（如提取用户和大事）使用流模型处理有序消息流。分布式消息系统通常支持流和队列两种语义，而最适合使用这两种语义的场景则有所不同。 流和队列 在流消息系统中，producer 追加数据到“仅追加”消息流中。在每个消息流中，必需按特定挨次处理消息，consumer 在消息流中标记消息的位置。我们可以实行某种策略（如对用户 ID 进行哈希处理）对消息进行分区，使分区成为单独的数据流，添加并行度。由于每个流中的数据不行变，且只保存偏移 entry，因而处理时不会遗漏消息。流适用于注重消息挨次（如提取数据）的场景。Kafka 和 Amazon Kinesis 都使用流语义处理消息。 在队列消息系统中，一个队列可能有多个 producer 和 ducer 向队列发送消息，consumer 从队列中接收消息。接收消息后，consumer 开头处理消息，并在处理完每条消息后向队列消息系统发送 ack。由于多个 consumer 共用一个队列，消息挨次并不重要，因而基于队列的系统很简约对 consumer 进行扩展。消息队列系统适用于不需要按特定挨次执行任务的队列，例如，发送同一封邮件给多个收件人。RabbitMQ 和 Amazon SQS 都是基于队列的消息系统。 通常情况下，消息队列系统可以简化消息级别错误的处理。例如，在发生错误后，RabbitMQ 可以轻松地将消息发送到特定队列，由该队列保留特定时间后，再将消息发送回到原始队列进行重试。RabbitMQ 还可以反馈 ack 失败，这样可以在消息发送失败后重新发送。大多数消息队列在收到 ack 后不会将消息存储在 backlog 中，因而系统无法找到需要新发送的消息，这就添加了调试和灾备的难度。 基于流的系统（如 Kafka）也可以用于队列使用场景，但使用起来有些麻烦。Kafka 支持多种特性，很多客户打算在队列中使用 Kafka。但是由于 Kafka 不能严格依据流指定的挨次处理消息，为开发人员添加很多额外工作。假如 consumer 无法消费消息，导致消息处理速度降低或需要重新消费消息，那么同一流上其他消息的处理速率也会遭到影响。常见的处理方案是将消息发布到另一个 topic 进行重试，但这会添加应用程序的形态管理，提高简单性。 为什么 Iterable 需要新消息系统 Iterable 一直使用 RabbitMQ 的特性，处理大量内部消息。我们自定义存活时间（Time-to-Live，TTL），用于指定重试次数，并实现消息处理中的显示延迟。例如，我们可能会延迟发送营销邮件（在收件人最可能查看邮件时，再发送营销邮件）。我们还需要查阅 ack 失败，来确定重新发送失败的队列消息。 Iterable 的架构简图如下： 在评估 Pulsar 时，我们使用 Kafka 提取消息，使用 RabbitMQ 处理上文提到的全部队列。Kafka 具备相应的功能和排序保证，格外适合提取消息，但由于缺少必要的队列语义，不适合其他使用场景。RabbitMQ 的特性（如延迟）对我们至关重要，这就添加了我们查找替代方案的难度。 在扩展系统时，RabbitMQ 消灭以下问题： 在高负载场景中，RabbitMQ 经常消灭流量把握问题。在内存或其他资源遭到限制时，broker 落后于 producer，流把握机制降低 producer 的速度。 但这会影响 producer，导