市面上有非常多的消息中间件，rabbitMQ、kafka、rocketMQ、pulsar、 redis等等，多得令人眼花缭乱。它们到底有什么异同，你又应该选哪个？今天就来聊聊这些消息队列的对比。

最基础的队列

最基础的消息队列其实就是一个双端队列，我们可以用双向链表来实现，如下图所示：

• push_front：添加元素到队首；
• pop_tail：从队尾取出元素。

有了这样的数据结构之后，我们就可以在内存中构建一个消息队列，一些任务不停地往队列里添加消息，同时另一些任务不断地从队尾有序地取出这些消息。添加消息的任务我们称为producer，而取出并使用消息的任务，我们称之为consumer。

要实现这样的内存消息队列并不难，甚至可以说很容易。但是如果要让它能在应对海量的并发读写时保持高效，还是需要下很多功夫的。

Redis的队列

redis刚好提供了上述的数据结构——list。redis list支持：

• lpush：从队列左边插入数据；
• rpop：从队列右边取出数据。

这正好对应了我们队列抽象的push_front和pop_tail，因此我们可以直接把redis的list当成一个消息队列来使用。而且redis本身对高并发做了很好的优化，内部数据结构经过了精心地设计和优化。所以从某种意义上讲，用redis的list大概率比你自己重新实现一个list强很多。

但另一方面，使用redis list作为消息队列也有一些不足，比如：

• 消息持久化：redis是内存数据库，虽然有aof和rdb两种机制进行持久化，但这只是辅助手段，这两种手段都是不可靠的。当redis服务器宕机时一定会丢失一部分数据，这对于很多业务都是没法接受的。
• 热key性能问题：不论是用codis还是twemproxy这种集群方案，对某个队列的读写请求最终都会落到同一台redis实例上，并且无法通过扩容来解决问题。如果对某个list的并发读写非常高，就产生了无法解决的热key，严重可能导致系统崩溃。
• 没有确认机制：每当执行rpop消费一条数据，那条消息就被从list中永久删除了。如果消费者消费失败，这条消息也没法找回了。你可能说消费者可以在失败时把这条消息重新投递到进队列，但这太理想了，极端一点万一消费者进程直接崩了呢，比如被kill -9，panic，coredump…
• 不支持多订阅者：一条消息只能被一个消费者消费，rpop之后就没了。如果队列中存储的是应用的日志，对于同一条消息，监控系统需要消费它来进行可能的报警，BI系统需要消费它来绘制报表，链路追踪需要消费它来绘制调用关系……这种场景redis list就没办法支持了。
• 不支持二次消费：一条消息rpop之后就没了。如果消费者程序运行到一半发现代码有bug，修复之后想从头再消费一次就不行了。

对于上述的不足，目前看来第一条（持久化）是可以解决的。很多公司都有团队基于rocksdb leveldb进行二次开发，实现了支持redis协议的kv存储。这些存储已经不是redis了，但是用起来和redis几乎一样。它们能够保证数据的持久化，但对于上述的其他缺陷也无能为力了。

其实redis 5.0开始新增了一个stream数据类型，它是专门设计成为消息队列的数据结构，借鉴了很多kafka的设计，但是依然还有很多问题…直接进入到kafka的世界它不香吗？

Kafka

从上面你可以看到，一个真正的消息中间件不仅仅是一个队列那么简单。尤其是当它承载了公司大量业务的时候，它的功能完备性、吞吐量、稳定性、扩展性都有非常苛刻的要求。kafka应运而生，它是专门设计用来做消息中间件的系统。

前面说redis list的不足时，虽然有很多不足，但是如果你仔细思考，其实可以归纳为两点：

• 热key的问题无法解决，即：无法通过加机器解决性能问题；
• 数据会被删除：rpop之后就没了，因此无法满足多个订阅者，无法重新从头再消费，无法做ack。

这两点也是kafka要解决的核心问题。

热key的本质问题是数据都集中在一台实例上，所以想办法把它分散到多个机器上就好了。为此，kafka提出了partition的概念。一个队列（redis中的list），对应到kafka里叫topic。kafka把一个topic拆成了多个partition，每个partition可以分散到不同的机器上，这样就可以把单机的压力分散到多台机器上。因此topic在kafka中更多是一个逻辑上的概念，实际存储单元都是partition。

其实redis的list也能实现这种效果，不过这需要在业务代码中增加额外的逻辑。比如可以建立n个list，key1, key2, ..., keyn，客户端每次往不同的key里push，消费端也可以同时从key1到keyn这n个list中rpop消费数据，这就能达到kafka多partition的效果。所以你可以看到，partition就是一个非常朴素的概念，用来把请求分散到多台机器。

redis list中另一个大问题是rpop会删除数据，所以kafka的解决办法也很简单，不删就行了嘛。kafka用游标（cursor）解决这个问题。

和redis list不同的是，首先kafka的topic（实际上是partion）是用的单向队列来存储数据的，新数据每次直接追加到队尾。同时它维护了一个游标cursor，从头开始，每次指向即将被消费的数据的下标。每消费一条，cursor+1 。通过这种方式，kafka也能和redis list一样实现先入先出的语义，但是kafka每次只需要更新游标，并不会去删数据。

这样设计的好处太多了，尤其是性能方面，顺序写一直是最大化利用磁盘带宽的不二法门。但我们主要讲讲游标这种设计带来功能上的优势。

首先可以支持消息的ACK机制了。由于消息不会被删除，因此可以等消费者明确告知kafka这条消息消费成功以后，再去更新游标。这样的话，只要kafka持久化存储了游标的位置，即使消费失败进程崩溃，等它恢复时依然可以重新消费

第二是可以支持分组消费：

这里需要引入一个消费组的概念，这个概念非常简单，因为消费组本质上就是一组游标。对于同一个topic，不同的消费组有各自的游标。监控组的游标指向第二条，BI组的游标指向第4条，trace组指向到了第10000条……各消费者游标彼此隔离，互不影响。

通过引入消费组的概念，就可以非常容易地支持多业务方同时消费一个topic，也就是说所谓的1-N的“广播”，一条消息广播给N个订阅方。

最后，通过游标也很容易实现重新消费。因为游标仅仅就是记录当前消费到哪一条数据了，要重新消费的话直接修改游标的值就可以了。你可以把游标重置为任何你想要指定的位置，比如重置到0重新开始消费，也可以直接重置到最后，相当于忽略现有所有数据。

因此你可以看到，kafka这种数据结构相比于redis的双向链表有了一个质的飞跃，不仅是性能上，同时也是功能上，全面的领先。

我们可以来看看kafka的一个简单的架构图：

从这个图里我们可以看出，topic是一个逻辑上的概念，不是一个实体。一个topic包含多个partition，partition分布在多台机器上。这个机器，kafka中称之为broker。（kafka集群中的一个broker对应redis集群中的一个实例）。对于一个topic，可以有多个不同的消费组同时进行消费。一个消费组内部可以有多个消费者实例同时进行消费，这样可以提高消费速率。

但是这里需要非常注意的是，一个partition只能被消费组中的一个消费者实例来消费。换句话说，消费组中如果有多个消费者，不能够存在两个消费者同时消费一个partition的场景。

为什么呢？其实kafka要在partition级别提供顺序消费的语义，如果多个consumer消费一个partition，即使kafka本身是按顺序分发数据的，但是由于网络延迟等各种情况，consumer并不能保证按kafka的分发顺序接收到数据，这样达到消费者的消息顺序就是无法保证的。因此一个partition只能被一个consumer消费。kafka各consumer group的游标可以表示成类似这样的数据结构：

1. Kafka中的数据查找

topic的一个partition是一个逻辑上的数组，由多个segment组成，如下图所示：

2. Kafka高可用

高可用（HA）对于企业的核心系统来说是至关重要的。因为随着业务的发展，集群规模会不断增大，而大规模集群中总会出现故障，硬件、网络都是不稳定的。当系统中某些节点各种原因无法正常使用时，整个系统可以容忍这个故障，继续正常对外提供服务，这就是所谓的高可用性。对于有状态服务来说，容忍局部故障本质上就是容忍丢数据（不一定是永久，但是至少一段时间内读不到数据）。

系统要容忍丢数据，最朴素也是唯一的办法就是做备份，让同一份数据复制到多台机器，所谓的冗余，或者说多副本。为此，kafka引入 leader-follower的概念。topic的每个partition都有一个leader，所有对这个partition的读写都在该partition leader所在的broker上进行。partition的数据会被复制到其它broker上，这些broker上对应的partition就是follower:

producer在生产消息时，会直接把消息发送到partition leader上，partition leader把消息写入自己的log中，然后等待follower来拉取数据进行同步。具体交互如下：

3. 优缺点

（1）优点：kafka的优点非常多

• 高性能：单机测试能达到 100w tps；
• 低延时：生产和消费的延时都很低，e2e的延时在正常的cluster中也很低；
• 可用性高：replicate + isr + 选举 机制保证；
• 工具链成熟：监控 运维 管理 方案齐全；
• 生态成熟：大数据场景必不可少 kafka stream.

（2）不足

• 无法弹性扩容：对partition的读写都在partition leader所在的broker，如果该broker压力过大，也无法通过新增broker来解决问题；
• 扩容成本高：集群中新增的broker只会处理新topic，如果要分担老topic-partition的压力，需要手动迁移partition，这时会占用大量集群带宽；
• 消费者新加入和退出会造成整个消费组rebalance：导致数据重复消费，影响消费速度，增加e2e延迟；
• partition过多会使得性能显著下降：ZK压力大，broker上partition过多让磁盘顺序写几乎退化成随机写。

上面这些不足总结起来就是一个词：scalebility。通过直接加机器就能解决问题的系统才是大家的终极追求。Pulsar号称云原生时代的分布式消息和流平台，所以接下来我们看看pulsar是怎么样的。

Pulsar

kafka的核心复杂度是它的存储，高性能、高可用、低延迟、支持快速扩容的分布式存储不仅仅是kafka的需求，应该是现代所有系统共同的追求。而apache项目底下刚好有一个专门就是为日志存储打造的这样的系统，它叫bookeeper！

有了专门的存储组件，那么实现一个消息系统剩下的就是如何来使用这个存储系统来实现feature了。pulsar就是这样一个”计算-存储 分离“的消息系统：

如果某个topic写入量特别特别大，一个broker扛不住怎么办？所以pulsar和kafka一样，也有partition的概念。一个topic可以分成多个partition，为了每个partition内部消息的顺序一致，对每个partition的生产必须对应同一台broker。

在bookeeper集群中每个节点叫bookie（为什么集群的实例在kafka叫broker在bookeeper又叫bookie……无所谓，名字而已，作者写了那么多代码，还不能让人开心地命个名啊）。在实例化一个bookeeper的writer时，就需要提供3个参数：

• 节点数n：bookeeper集群的bookie数；
• 副本数m：某一个ledger会写入到n个bookie中的m个里，也就是说所谓的m副本；
• 确认写入数t：每次向ledger写入数据时（并发写入到m个bookie），需要确保收到t个acks，才返回成功。

bookeeper会根据这三个参数来为我们做复杂的数据同步，所以我们不用担心那些副本啊一致性啊的东西，直接调bookeeper的提供的append接口就行了，剩下的交给它来完成。

存算分离架构

其实技术的发展都是螺旋式的，很多时候你会发现最新的发展方向又回到了20年前的技术路线了。

在20年前，由于普通计算机硬件设备的局限性，对大量数据的存储是通过NAS(Network Attached Storage)这样的“云端”集中式存储来完成。但这种方式的局限性也很多，不仅需要专用硬件设备，而且最大的问题就是难以扩容来适应海量数据的存储。

数据库方面也主要是以Oracle小型机为主的方案。然而随着互联网的发展，数据量越来越大，Google后来又推出了以普通计算机为主的分布式存储方案，任意一台计算机都能作为一个存储节点，然后通过让这些节点协同工作组成一个更大的存储系统，这就是HDFS。

然而移动互联网使得数据量进一步增大，并且4G 5G的普及让用户对延迟也非常敏感，既要可靠，又要快，又要可扩容的存储逐渐变成了一种企业的刚需。而且随着时间的推移，互联网应用的流量集中度会越来越高，大企业的这种刚需诉求也越来越强烈。

因此，可靠的分布式存储作为一种基础设施也在不断地完善。它们都有一个共同的目标，就是让你像使用filesystem一样使用它们，并且具有高性能高可靠自动错误恢复等多种功能。然而我们需要面对的一个问题就是CAP理论的限制，线性一致性（C），可用性（A），分区容错性（P），三者只能同时满足两者。因此不可能存在完美的存储系统，总有那么一些“不足”。我们需要做的其实就是根据不同的业务场景，选用合适的存储设施，来构建上层的应用。这就是pulsar的逻辑，也是tidb等newsql的逻辑，也是未来大型分布式系统的基本逻辑，所谓的“云原生”。

文章部分素材来源：浪尖聊大数据