作为消息代理时Kafka吞吐量远高于Redis的核心原因是什么？

研究表明，当Kafka与Redis同时作为消息代理时，Kafka在每秒消息处理量、每秒传输数据量两个维度的整体吞吐量表现均更优。名为《实时流处理管道中数据摄取平台对比》的最新研究显示，针对1kB大小的有效负载，Kafka每秒可处理的请求量最多可达Redis的3倍。

二者的性能差异本质上是定位和设计目标的不同带来的，核心原因可以分为以下几点：

• 架构定位差异
  Redis的核心定位是内存键值数据库，消息队列（Pub/Sub、Stream）属于附加的衍生功能，设计上没有为大规模流式消息传输做专项优化；Kafka从诞生之初就是专门为高吞吐分布式流处理场景设计的，所有核心能力都围绕大流量消息的存储、传输、订阅做定向优化。
• I/O性能优化差异
  Kafka采用顺序磁盘写入+操作系统页缓存+零拷贝传输技术，即使数据持久化落盘也能达到接近内存操作的吞吐量，加上原生支持消息批量发送、批量拉取的机制，大幅降低了网络交互的额外开销；Redis的消息功能虽然基于内存实现，但没有针对大流量批量消息场景做优化，出现消息堆积时还容易触发内存抖动、OOM等问题，反而影响整体性能。
• 消费模型效率差异
  Kafka采用消费者主动拉取消息的模式，消费者可以根据自身消费能力控制拉取速度，不会出现 broker 被消费速度慢的客户端拖垮的问题，同时消费偏移量（offset）由消费者自行维护，大幅降低了 broker 侧的状态维护成本；Redis的Pub/Sub是服务端主动推送模式，Stream虽然支持拉取，但整体设计偏向轻量消息场景，单队列大规模消费时的元数据维护成本远高于Kafka。
• 水平扩展能力差异
  Kafka天然支持分布式分区设计，一个主题可以拆分为多个分区分布在不同的 broker 节点上，整体吞吐量可以通过增加节点、增加分区数实现近乎线性的提升；Redis的消息队列能力受限于单实例性能上限，集群模式下消息路由、一致性维护的额外开销很高，很难支撑超大流量的消息传输场景。

注：Redis的消息队列能力并非完全不适用，它在低延迟、中小流量的即时消息场景下表现非常优秀，只是在高吞吐流处理的特定场景下，Kafka的定向优化优势会十分明显。

内容的提问来源于stack exchange，提问作者Vitor Medeiros