Netflix基于Redis Kafka和Elasticsearch构建高吞吐优先队列Timesone

Netflix基于Redis Kafka和Elasticsearch构建高吞吐优先队列Timesone

最近,Netflix 公布了它是如何构建Timestone的——一个高吞吐、低延迟的优先队列系统。Netflix 使用 Redis、Apache Kafka、Apache Flink 和 Elasticsearch 等开源组件来构建这个队列系统。Netflix 的工程师们表示,他们之所以要构建 Timestone,是因为他们无法找到满足其所有要求的现成解决方案。

其中一个需求是不需要在消费者端进行任何锁定或协调的情况下将某些工作项标记为不可并行。这一需求意味着在属于同一工作集的前一个项目完成之前,Timestone 不应该发送消息。Timestone 引入了“独占队列(Exclusive Queue)”的概念来实现这一目的。

Netflix 的软件工程师 Kostas Christidis 解释了独占队列的工作原理。

下图描绘了这个示例。

当 worker_2 发出出队列调用时,会收到 msg_2 而不是 msg_1,即使 msg_1 具有更高的优先级

来源:另一个需求是,在任何给定的时间,一条消息只能分配给一个消费者。这很重要,因为 Cosmos 种的工作负载往往是资源密集型的,并且可能扇出数千个动作,这个需求的目标之一便是减少资源浪费。这个需求排除了最终一致性解决方案,这意味着 Netflix 的工程师想要的是队列级别的线性一致性。

Netflix 工程师通过为每条消息维护一个消息状态来实现这一需求。当生产者将消息入队时,消息将被设置为“Pending”或“Invisible”状态,这取决于消息的超时设置(可选)。当消费者将挂起的消息从队列中取出时,它将获得该消息的独占租约,Timestone 将该消息设置为“Running”状态。在这个阶段,生产者可以将消息标记为“Completed”或“Cancelled”。每条消息最多可以尝试有限的取出次数,然后 Timestone 将其标记为“Errored”状态。下图说明了所有可能的状态转换。

来源:服务器提供了一个基于 gRPC 的接口。所有 API 操作都在队列作用域内。所有修改状态的 API 操作都是幂等的。记录系统是一个 Redis 集群。在将响应发送回服务器之前,Redis 会将每个写请求持久化到事务日志中。在 Redis 内部使用了一个按优先级排序的排序集代表每个队列。消息和队列配置以散列值的方式存储。

Christidis 提到了 Netflix 工程师如何用 Redis 实现原子性:

来源:为了实现可观察性,Timestone 捕获关于传入消息及其状态间转换的信息,并将其保存在 Elasticsearch 的两个二级索引中。当 Timtstone 服务器从 Redis 获得写入响应时,它将其转换为发送到 Kafka 集群的事件。有两个分别对应 Timestone 两个索引的 Flink 作业,消费来自相应 Kafka 主题的事件,并更新 Elasticsearch 中的索引。

Netflix 创建 Timestone 是为了满足其媒体编码平台 Cosmos 的需求。Timestone 还支持——Netflix 的通用工作流编排引擎,作为大规模数据管道的调度器。

原文链接

Netflix Builds a Custom High-Throughput Priority Queue Backed by Redis, Kafka and Elasticsearch

声明:本文来自用户分享和网络收集,仅供学习与参考,测试请备份。