Netflix 采用 RAW Hollow 内存对象存储对 Tudum 的 CQRS 架构进行了重新设计

Netflix用内部开发的RAW Hollow内存对象存储替换了基于Kafka和Cassandra的CQRS实现。Tudum 的新架构在编辑过程中提供了更快的内容预览，并为访问者提供更快的页面渲染。

Netflix 在 2021 年底推出了其官方粉丝网站 Tudum，为对该公司节目相关内容感兴趣的 Netflix 用户提供了一个集合点。网站架构最初基于命令查询责任分离（Command Query Responsibility Segregation，CQRS）模式，以优化读取性能，以便于为用户提供内容。

平台的写入部分是围绕第三方 CMS 产品构建的，并有一个专门的摄取服务来处理通过 webhook 传递的内容更新事件。摄取服务负责将 CMS 数据转换为针对读取优化过的页面内容，这是通过应用模板以及数据验证和转换来实现的。然后，经过读取优化的数据会被发布到一个专门的 Kafka 主题。

初始 Tudum 的数据架构（来源：Netflix工程博客）

在查询方面，页面数据服务负责消费 Kafka 主题的消息，并将数据存储在Cassandra查询数据库中。该服务使用缓存来提高性能，为页面构建服务和其他内部服务提供已存储的页面数据。

初始架构能够从读写路径的解耦中受益，允许独立扩展。然而，由于缓存刷新周期的问题，CMS 更新需要许多秒后才能显示在网站上。这个问题使得内容编辑器预览他们的修改变得问题重重，并且随着内容量的增长，问题逐渐恶化，导致延迟持续数十秒之久。

技术布道师Eugene Yemelyanau和 Netflix 的主任工程师Jake Grice描述了由于缓存导致检索内容显示延迟的原因：

无论哪个系统修改数据，缓存都会在每个刷新周期进行更新。如果你有 60 个键，并且刷新间隔为 60 秒，缓存将每秒更新一个键。这对于预览最近的修改是有问题的，因为这些变化只有在每次缓存刷新时才会反映出来。随着 Tudum 内容的增长，缓存刷新时间增加，这进一步增加了延迟。

最终，团队决定彻底改革架构，以消除预览内容更新的延迟，理想情况下。工程师选择利用RAW Hollow，这是一个自制的内存对象数据库。Netflix 设计了这个数据库来处理小到中等的数据集，并支持强写后读一致性（read-after-write consistency）。RAW Hollow 允许整个数据集驻留在集群中每个应用程序进程的内存中，提供低延迟和高可用性。数据库默认提供最终一致性，但支持在单个请求级别上的强一致性。

修改后的 Tudum 数据架构（来源：Netflix工程博客）

Tudum 工程师用 RAW Follow 集群替换了 Kafka 和 Cassandra，涵盖了摄取和页面构建服务实例。团队最终得出结论，对于手头的用例，CQRS 设计模式并不是最佳方法，使用分布式内存对象存储更适合这种情况。新解决方案消除了缓存失效的问题，因为整个数据集可以适应应用程序的内存，借助 Hollow 的数据压缩，将数据大小减少到 Apache Iceberg 表中未压缩大小的 25%。

由于架构改善以及支持数据迁移，平台能够从数据传播时间和页面构建次数的显著减少中获益，这是由于减少了请求 I/O 和往返时间。Tudum 工程师相信新架构为编辑器和访问者提供了最佳的体验。

原文链接：

 Netflix Revamps Tudum’s CQRS Architecture with RAW Hollow In-Memory Object Store