Netflix 如何利用 RAW Hollow 重构 Tudum 架构

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"