原文如下；作者 Sean Ryan 肖恩·瑞安；翻译 ChatGPT
How we improved performance and scalability by migrating to Apache Pulsar
我们最近在平台的可扩展性和性能方面进行了重大投资，采用了Apache Pulsar作为驱动我们核心功能的流引擎。由于我们在这个项目上花费了时间和精力，我们的关键服务现在基于更灵活、可扩展和可靠的数据管道。
每个企业软件应用程序背后都有一个复杂而动态的服务架构，而使用这些软件的人们大多不关心。理想情况下，他们不应该关心。最终用户通常只关心软件是否能够实现其所宣称的功能。最好的软件后端就像潜伏在水下的巨大冰山一样，不可见、不可检测，但却悄然地保持着可见部分的浮力。
每个月，mParticle 处理 1080 亿个 API 调用，并接收和转发超过 6860 亿个事件，以帮助像 CKE Restaurants、Airbnb 和 Venmo 这样的全球公司规模化地管理其客户数据。要始终如一地执行这项任务，并具有极高的容错率，这意味着我们后端中的每个组件都必须完全针对其执行的过程进行优化。因此，当我们在 2020 年发现我们的受众服务由于支持它的消息队列（当时为 Amazon SQS）而出现了一些数据退化时，我们的工程团队知道他们必须寻找另一个解决方案。
在mParticle的后端，流引擎参与了将数据从被摄取的位置（如客户端SDK和服务器到服务器的数据源）移动到将消费数据的服务（如受众）的过程中。由于mParticle从多个来源摄取数据并实时将其传递到多个服务中，因此需要多个队列来处理客户端和服务之间的消息传递操作。
在采用Apache Pulsar之前，Amazon SQS负责mParticle受众服务内部组件之间的数据传输。虽然SQS在当时满足了我们大部分用例的需求（并且在我们架构中的其他服务上仍然如此），但它缺乏将传入消息序列化的能力，以防止在驱动受众的读/修改/写循环中发生覆盖。
使用Amazon SQS时，当多个服务（例如客户端SDK和S2S源）同时对共同的数据库执行读/修改/写入任务时，它们可能会重叠，导致竞争条件，如下所示：
总体而言，这些情况并未以非常高的频率发生。然而，在像Audiences这样广泛使用的核心服务中，这种并发问题可能会导致随着时间的推移出现不可接受的大量不准确的条目。这在我们开发计算属性功能时尤为明显，该功能允许客户对特定的用户或事件属性运行计算。当创建计算属性时，mParticle会使用用户和事件数据的原始数据流自动连续更新此属性的值。这个功能的需求意味着SQS引起的不需要的数据覆盖是不可接受的。
为了解决并发挑战，我们的工程师寻找了一种解决方案，可以使我们对受众以及其他服务中的传入消息进行序列化，并确保在任何给定时间只能运行一个读/修改/写任务。我们的团队探索了许多数据流服务，提供了这种功能，并确定了两个领先者，都来自Apache：Kafka和Pulsar。
这些解决方案脱颖而出，因为它们都允许用户提供一个关键字，用于分离传入的数据流。通过使用mParticle ID（MPID）作为此标识符，我们可以确保来自同一用户的数据流被顺序处理而不是并发处理。这将防止我们在处理同一用户的同时请求时遇到的错误和数据一致性问题，而使用SQS。
在下面的图表中，我们可以看到如何根据标识符将批次进行分区，从而避免了我们之前遇到的读取/修改/写入任务中的竞争条件
图表左侧的灰色框代表我们的上游服务。这些是在像Audiences这样的服务中使用用户和事件数据之前需要发生的转换过程。这些过程包括数据质量保证、个人资料丰富、身份解析等。如果没有统一和准确的数据，构建和转发受众到下游服务将不可能，这就是为什么这些上游服务对于客户从mParticle获得的价值至关重要的原因。