这篇博文介绍了 MemQ，这是一种为 Pinterest 的云开发的高效、可扩展的 PubSub 系统，自 2020 年中期以来一直为我们提供近实时数据传输用例，并补充了 Kafka，同时成本效率提高了 90%。
Kafka问题
近十年来，Pinterest 一直依赖 Apache Kafka作为唯一的 PubSub 系统。随着 Pinterest 的发展，数据量和运营超大规模分布式 PubSub 平台的挑战也随之增加。大规模运行 Apache Kafka 让我们对如何构建可扩展的 PubSub 系统有了很多了解。在对我们的 PubSub 环境的操作和可扩展性挑战进行深入调查后，我们得出了以下关键要点：
- 不是每个数据集都需要亚秒级延迟服务，延迟和成本应该成反比（较低的延迟应该花费更多）
- PubSub 系统的 Storage 和 Serving 组件需要分离，以实现基于资源的独立可扩展性。
- 读取而不是写入的排序为特定的消费者用例提供了所需的灵活性（不同的应用程序对于相同的数据集可以有不同的）
- 在大多数情况下，Pinterest 不需要严格的分区排序，并且通常会导致可扩展性挑战。
- Kafka 中的重新平衡代价高昂，通常会导致性能下降，并对饱和集群上的客户产生负面影响。
- 在云环境中运行自定义复制的成本很高。
2018 年，我们试验了一种新型的 PubSub 系统，它可以原生地利用云。2019 年，我们开始正式探索如何解决我们的 PubSub 可扩展性挑战的选项，并根据运营成本以及现有技术的再造成本评估了多种 PubSub 技术以满足 Pinterest 的需求。我们最终得出的结论是，我们需要一种 PubSub 技术，该技术建立在 Apache Kafka、Apache Pulsar 和 Facebook LogDevice 的学习基础上，并且是为云而构建的。
MemQ出世
MemQ 是一个新的 PubSub 系统，它增强了 Pinterest 上的 Kafka。它使用类似于Apache Pulsar和Facebook Logdevice的解耦存储和服务架构；然而，它依赖于一个可插拔的复制存储层，即对象存储/DFS/NFS 来存储数据。最终结果是一个 PubSub 系统：
- 处理 GB/s 流量
- 独立缩放、写入和读取
- 不需要昂贵的重新平衡来处理流量增长
- 比我们的 Kafka 足迹高 90% 的成本效益
特点
MemQ 的秘诀在于它利用微批处理和不可变写入来创建一个架构，其中存储层上所需的每秒输入/输出操作 (IOPS) 数量显着减少，从而可以经济高效地使用云原生对象像 Amazon S3 一样存储。这种方法类似于网络的分组交换（vs 电路交换，即单个大型连续数据存储，例如 kafka 分区）。
MemQ 将连续的日志流分解为块（对象），类似于 Pulsar 中的账本，但不同之处在于它们被写为对象并且是不可变的。这些“数据包”/“对象”的大小，在 MemQ 内部称为 Batch，在确定端到端 (E2E) 延迟方面发挥作用。数据包越小，以更高的 IOPS 为代价写入的速度就越快。因此，MemQ 允许以更高的 IOP 为代价实现可调整的 E2E 延迟。这种架构的一个关键性能优势是实现依赖于底层存储层的读写硬件的分离，允许写入和读取作为可以跨存储层传播的数据包独立扩展。
这也消除了在 Kafka 中遇到的限制，为了恢复副本，必须从一开始就重新复制分区。在MemQ的情况下，底层复制存储只需要在存储失败的情况下恢复由于故障而减少副本计数的特定Batch。但是，由于 Pinterest 的 MemQ 在 Amazon S3 上运行，因此存储的恢复、分片和扩展由 AWS 处理，无需 Pinterest 的任何手动干预。
....
结论
MemQ 为 PubSub 提供了一种灵活、低成本的云原生方法。MemQ 如今为 Pinterest 的所有 ML 训练数据的收集和传输提供支持。我们正在积极研究将其扩展到其他数据集并进一步优化延迟。除了解决 PubSub 之外，MemQ 存储还可以公开使用 PubSub 数据进行批处理的能力，而不会对性能产生重大影响，从而实现低延迟批处理。