消息队列为什么选用redis？聊聊如何做技术方案选型？

消息队列为什么选用redis？聊聊如何做技术方案选型？

老生常谈，消息队列主要有几大用途：

解耦：下单完成之后，需要订单服务去调用库存服务减库存，调用营销服务加营销数据。

引入消息队列，可以把订单完成的消息丢进队列里，下游服务自己去调用就行了，这样就完成了订单服务和其它服务的解耦合。使用消息MQ后，只需要保证消息格式不变，不需要关心发布者及消费者之间的关系，这两者不需要彼此联系

异步：订单支付之后，要扣减库存、增加积分、发送消息等等，这样一来这个链路就长了，链路一长，响应时间就变长了。

引入消息队列，除了更新订单状态等，其它的都可以异步去做。

削峰：例如秒杀系统，秒杀的时候流量疯狂怼进来，我们的服务器，Redis，MySQL各自的承受能力都不一样，直接全部流量可能直接挂了。

场景：在大量流量涌入高峰，如数据库只能抗住2000的并发流量，可以使用MQ控制2000到数据库中。我们把请求扔到队列里面，只放出我们服务能处理的流量，这样就能抗住短时间的大流量了。

日志处理：日志存储在消息队列中，用来处理日志，比如kafka。

那么，我们讨论关于「消息队列为什么选用redis，是否合适」的问题

赞成的观点认为 Redis 很轻量，用作队列很方便。

反对观点认为 Redis 会「丢」数据。

把 Redis 当作队列来用是否合适？让我们一起一探究竟。

show you the code

redis 选用目录：

• List 队列

• pub\sub 发布\订阅模型

• Stream 

• 与消息队列的对比

List 队列

把 Redis 当作队列来使用，最先想到的就是使用 List 这个数据类型。

因为 List 底层的实现就是一个「链表」，在头部和尾部操作元素，时间复杂度都是 O(1)，这意味着它非常符合消息队列的模型。

生产者使用 LPUSH 发布消息：

127.0.0.1:6379> LPUSH queue msg1(integer) 1127.0.0.1:6379> LPUSH queue msg2(integer) 2

消费者这一侧，使用 RPOP 拉取消息：

127.0.0.1:6379> RPOP queue"msg1"127.0.0.1:6379> RPOP queue"msg2"

这里有个小问题，当队列中已经没有消息了，消费者在执行 RPOP 时，会返回 NULL。

127.0.0.1:6379> RPOP queue(nil)   // 没消息了

而我们在编写消费者逻辑时，一般是一个「死循环」，这个逻辑需要不断地从队列中拉取消息进行处理，伪代码一般会这么写：

while true:
    msg = redis.rpop("queue")
    // 没有消息，继续循环
    if msg == null:
        continue
    // 处理消息
    handle(msg)

如果此时队列为空，那消费者依旧会频繁拉取消息，会造成「CPU 空转」，不仅浪费 CPU 资源，还会对 Redis 造成压力。

 

怎么解决这个问题呢？

也简单，当队列为空时，我们可以sleep 2秒，然后再尝试拉取消息。

while true:
    msg = redis.rpop("queue")
    // 没有消息，休眠2s
    if msg == null:
        sleep(2)
        continue
    // 处理消息        
    handle(msg)

这就解决了 CPU 空转问题。

 

但又带来另外一个问题：当消费者在休眠等待时，有新消息来了，那消费者处理新消息就会存在「延迟」。

 

如何既能及时处理新消息，还能避免 CPU 空转呢？

 

Redis 提供了「阻塞式」拉取消息的命令：BRPOP / BLPOP，这里的 B 指的是阻塞（Block）。

如果队列为空，消费者在拉取消息时就「阻塞等待」，一旦有新消息过来，就通知消费者立即处理新消息

 

现在，我们这样来拉取消息了：

while true:
    // 没消息阻塞等待，0表示不设置超时时间
    msg = redis.brpop("queue", 0)
    if msg == null:
        continue
    // 处理消息
    handle(msg)

使用 BRPOP 阻塞式方式拉取消息时，还支持传入一个「超时时间」，如果设置为 0，则表示不设置超时，直到有新消息才返回，否则会在指定的超时时间后返回 NULL。

这个方案既兼顾了效率，还避免了 CPU 空转问题，一举两得。

tips：如果设置的超时时间太长，连接太久没有活跃过，可能会被 Redis Server 判定为无效连接，之后 Redis Server 会强制把这个客户端踢下线。所以，采用这种方案，客户端要有重连机制。

 

这种队列模型，有什么缺点？

1. 不支持重复消费：消费者拉取消息后，这条消息就从 List 中删除了，无法被其它消费者再次消费，即不支持多个消费者消费同一批数据

2. 消息丢失：消费者拉取到消息后，如果发生异常宕机，消息就丢失了

第一，使用 List 做消息队列，一组生产者对应一组消费者，不能满足多组生产者和消费者的业务场景。

第二个问题，因为从 List 中 POP 一条消息出来后，这条消息就会立即从链表中删除。也就是说，无论消费者是否处理成功，这条消息都没办法再次消费了。

如果消费者在处理消息时异常宕机，那这条消息就相当于丢失了。

 

消息延迟问题解决了，又引入新的问题存在。

 

Pub/Sub发布/订阅模型

这个模块是 Redis 专门是针对「发布/订阅」这种队列模型设计的。

它正好可以解决重复消费问题。

Redis 提供了 PUBLISH / SUBSCRIBE 命令，来完成发布、订阅的操作。即多组生产者、消费者的场景。

假设开启 2 个消费者，同时消费同一批数据，就可以按照以下方式来实现。

首先，使用 SUBSCRIBE 命令，启动 2 个消费者，并「订阅」同一个队列。

// 2个消费者 都订阅一个队列
127.0.0.1:6379> SUBSCRIBE queue
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "queue"
3) (integer) 1

此时，2 个消费者都会被阻塞住，等待新消息的到来。

之后，再启动一个生产者，发布一条消息。

127.0.0.1:6379> PUBLISH queue msg1
(integer) 1

这时，2 个消费者就会解除阻塞，收到生产者发来的新消息。

127.0.0.1:6379> SUBSCRIBE queue
// 收到新消息
1) "message"
2) "queue"
3) "msg1"

看到了么，使用 Pub/Sub 这种方案，既支持阻塞式拉取消息，还很好地满足了多组消费者，消费同一批数据的业务需求。

 

除此之外，Pub/Sub 还提供了「匹配订阅」模式，允许消费者根据一定规则，订阅「多个」自己感兴趣的队列。

// 订阅符合规则的队列
127.0.0.1:6379> PSUBSCRIBE queue.*
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "queue.*"
3) (integer) 1

这里的消费者，订阅了 queue.* 相关的队列消息。

之后，生产者分别向 queue.p1 和 queue.p2 发布消息。

127.0.0.1:6379> PUBLISH queue.p1 msg1
(integer) 1
127.0.0.1:6379> PUBLISH queue.p2 msg2
(integer) 1

这时再看消费者，它就可以接收到这 2 个生产者的消息了。

127.0.0.1:6379> PSUBSCRIBE queue.*
Reading messages... (press Ctrl-C to quit)
...
// 来自queue.p1的消息
1) "pmessage"
2) "queue.*"
3) "queue.p1"
4) "msg1"

// 来自queue.p2的消息
1) "pmessage"
2) "queue.*"
3) "queue.p2"
4) "msg2"

Pub/Sub 最大的优势就是，支持多组生产者、消费者处理消息。

而Pub/Sub 最大问题是：数据丢失。

 

这其实与 Pub/Sub 的实现方式有很大关系。

比如，发生以下场景，就有可能导致数据丢失：

1. 消费者下线

2. Redis 宕机

3. 消息堆积

Pub/Sub 在实现时没有基于任何数据类型，也没有做任何的数据存储，它只是单纯地为生产者、消费者建立「数据转发通道」，把符合规则的数据，从一端转发到另一端。

一个完整的发布、订阅消息处理流程是这样的：

1. 消费者订阅指定队列，Redis 就会记录一个映射关系：队列->消费者

2. 生产者向这个队列发布消息，那 Redis 就从映射关系中找出对应的消费者，把消息转发给它

 

整个过程中，没有任何的数据存储，一切都是实时转发的。

这种设计方案，就导致了上面提到的那些问题。

 

例如，如果一个消费者异常挂掉了，它再重新上线后，只能接收新的消息，在下线期间生产者发布的消息，因为找不到消费者，都会被丢弃掉。

如果所有消费者都下线了，那生产者发布的消息，因为找不到任何一个消费者，也会全部「丢弃」。

所以，当你在使用 Pub/Sub 时，一定要注意：消费者必须先订阅队列，生产者才能发布消息，否则消息会丢失。

这也是前面，我们让消费者先订阅队列，之后才让生产者发布消息的原因。

 

另外，因为 Pub/Sub 没有基于任何数据类型实现，所以它也不具备「数据持久化」的能力。

也就是说，Pub/Sub 的相关操作，不会写入到 RDB 和 AOF 中，当 Redis 宕机重启，Pub/Sub 的数据也会全部丢失。

 

最后，我们来看 Pub/Sub 在处理「消息积压」时，为什么也会丢数据？

当消费者的速度，跟不上生产者时，就会导致数据积压的情况发生。

如果采用 List 当作队列，消息积压时，会导致这个链表很长，最直接的影响就是，Redis 内存会持续增长，直到消费者把所有数据都从链表中取出。

但 Pub/Sub 的处理方式却不一样，当消息积压时，有可能会导致消费失败和消息丢失！

回到 Pub/Sub 的实现细节上来说。

每个消费者订阅一个队列时，Redis 都会在 Server 上给这个消费者在分配一个「缓冲区」，这个缓冲区其实就是一块内存。

当生产者发布消息时，Redis 先把消息写到对应消费者的缓冲区中。

之后，消费者不断地从缓冲区读取消息，处理消息。

 

问题就出在这个缓冲区上。

因为这个缓冲区其实是有「上限」的（可配置），如果消费者拉取消息很慢，就会造成生产者发布到缓冲区的消息开始积压，缓冲区内存持续增长。

如果超过了缓冲区配置的上限，此时，Redis 就会「强制」把这个消费者踢下线。

这时消费者就会消费失败，也会丢失数据。

 

我们看一下Redis 的配置文件，缓冲区的默认配置：client-output-buffer-limit pubsub 32mb 8mb 60。

参数含义如下：

• 32mb：缓冲区一旦超过 32MB，Redis 直接强制把消费者踢下线

• 8mb + 60：缓冲区超过 8MB，并且持续 60 秒，Redis 也会把消费者踢下线

 

可以看出，List 其实是属于「拉」模型，而 Pub/Sub 其实属于「推」模型。

List 中的数据可以一直积压在内存中，消费者什么时候来「拉」都可以。

但 Pub/Sub 是把消息先「推」到消费者在 Redis Server 上的缓冲区中，然后等消费者再来取。

当生产、消费速度不匹配时，就会导致缓冲区的内存开始膨胀，Redis 为了控制缓冲区的上限，所以就有了上面讲到的，强制把消费者踢下线的机制。

 

现在，我们总结一下 Pub/Sub 的优缺点：

1. 支持发布 / 订阅，支持多组生产者、消费者处理消息

2. 消费者下线，数据会丢失

3. 不支持数据持久化，Redis 宕机，数据也会丢失

4. 消息堆积，缓冲区溢出，消费者会被强制踢下线，数据也会丢失

所以，Pub/Sub 在实际的应用场景中用得并不多。除了第一个是优点之外，剩下的都是缺点。

 目前只有哨兵集群和 Redis 实例通信时，采用了 Pub/Sub 的方案，因为哨兵正好符合即时通讯的业务场景。

我们再来看一下，Pub/Sub 有没有解决，消息处理时异常宕机，无法再次消费的问题呢？

其实也不行，Pub/Sub 从缓冲区取走数据之后，数据就从 Redis 缓冲区删除了，消费者发生异常，自然也无法再次重新消费。

 

好，现在我们重新梳理一下使用消息队列时的需求。

当我们在使用一个消息队列时，希望它的功能是这样的：

• 支持阻塞等待拉取消息

• 支持发布 / 订阅模式

• 消费失败，可重新消费，消息不丢失

• 实例宕机，消息不丢失，数据可持久化

• 消息可堆积

 

Redis 作者，叫Salvatore Sanfilippo，来自意大利的西西里岛，居住在卡塔尼亚。在开发 Redis 期间，还另外开发了一个开源项目 disque。项目的定位，就是一个基于内存的分布式消息队列中间件。

在 Redis 5.0 版本，作者把 disque 功能移植到了 Redis 中，并给它定义了一个新的数据类型：Stream。

 

Stream

Stream 在做消息队列时，是如何处理的？

首先，Stream 通过 XADD 和 XREAD 完成最简单的生产、消费模型：

• XADD：发布消息

• XREAD：读取消息

生产者发布 2 条消息：

// *表示让Redis自动生成消息ID
127.0.0.1:6379> XADD queue * name zhangsan
"1618469123380-0"
127.0.0.1:6379> XADD queue * name lisi
"1618469127777-0"

使用 XADD 命令发布消息，其中的「*」表示让 Redis 自动生成唯一的消息 ID。

这个消息 ID 的格式是「时间戳-自增序号」。

消费者拉取消息：

// 从开头读取5条消息，0-0表示从开头读取
127.0.0.1:6379> XREAD COUNT 5 STREAMS queue 0-0
1) 1) "queue"
   2) 1) 1) "1618469123380-0"
         2) 1) "name"
            2) "zhangsan"
      2) 1) "1618469127777-0"
         2) 1) "name"
            2) "lisi"

如果想继续拉取消息，需要传入上一条消息的 ID：

127.0.0.1:6379> XREAD COUNT 5 STREAMS queue 1618469127777-0
(nil)

没有消息，Redis 会返回 NULL。

 这就是 Stream 最简单的生产、消费。

为了方便理解，凡是大写的单词都是「固定」参数，凡是小写的单词，例如队列名、消息长度等，都是可以自己定义的。

我们来看看stream 是如何处理消息队列的问题的。

1) Stream 是否支持「阻塞式」拉取消息？

支持，在读取消息时，只需要增加 BLOCK 参数即可。

// BLOCK 0 表示阻塞等待，不设置超时时间
127.0.0.1:6379> XREAD COUNT 5 BLOCK 0 STREAMS queue 1618469127777-0

这时，消费者就会阻塞等待，直到生产者发布新的消息才会返回。

 

2) Stream 是否支持发布 / 订阅模式？

支持，Stream 通过以下命令完成发布订阅：

• XGROUP：创建消费者组

• XREADGROUP：在指定消费组下，开启消费者拉取消息

下面我们来看具体如何做？

首先，生产者依旧发布 2 条消息：

127.0.0.1:6379> XADD queue * name zhangsan
"1618470740565-0"
127.0.0.1:6379> XADD queue * name lisi
"1618470743793-0"

之后，我们想要开启 2 组消费者处理同一批数据，就需要创建 2 个消费者组：

// 创建消费者组1，0-0表示从头拉取消息
127.0.0.1:6379> XGROUP CREATE queue group1 0-0
OK
// 创建消费者组2，0-0表示从头拉取消息
127.0.0.1:6379> XGROUP CREATE queue group2 0-0
OK

消费者组创建好之后，我们可以给每个「消费者组」下面挂一个「消费者」，让它们分别处理同一批数据。

第一个消费组开始消费：

// group1的consumer开始消费，>表示拉取最新数据
127.0.0.1:6379> XREADGROUP GROUP group1 consumer COUNT 5 STREAMS queue >
1) 1) "queue"
   2) 1) 1) "1618470740565-0"
         2) 1) "name"
            2) "zhangsan"
      2) 1) "1618470743793-0"
         2) 1) "name"
            2) "lisi"

同样地，第二个消费组开始消费：

// group2的consumer开始消费，>表示拉取最新数据
127.0.0.1:6379> XREADGROUP GROUP group2 consumer COUNT 5 STREAMS queue >
1) 1) "queue"
   2) 1) 1) "1618470740565-0"
         2) 1) "name"
            2) "zhangsan"
      2) 1) "1618470743793-0"
         2) 1) "name"
            2) "lisi"

可以看到，这 2 组消费者，都可以获取同一批数据进行处理了。

这样就达到了多组消费者「订阅」消费的目的。

3) Stream 能否保证消息不丢失，重新消费？

除了上面拉取消息时用到了消息 ID，这里为了保证重新消费，也要用到这个消息 ID。

当一组消费者处理完消息后，需要执行 XACK 命令告知 Redis，这时 Redis 就会把这条消息标记为「处理完成」。

// group1下的 1618472043089-0 消息已处理完成127.0.0.1:6379> XACK queue group1 1618472043089-0

如果消费者异常宕机，肯定不会发送 XACK，那么 Redis 就会依旧保留这条消息。

待这组消费者重新上线后，Redis 就会把之前没有处理成功的数据，重新发给这个消费者。这样一来，即使消费者异常，也不会丢失数据了。

// 消费者重新上线，0-0表示重新拉取未ACK的消息
127.0.0.1:6379> XREADGROUP GROUP group1 consumer1 COUNT 5 STREAMS queue 0-0
// 之前没消费成功的数据，依旧可以重新消费
1) 1) "queue"
   2) 1) 1) "1618472043089-0"
         2) 1) "name"
            2) "zhangsan"
      2) 1) "1618472045158-0"
         2) 1) "name"
            2) "lisi"

4) Stream 数据会写入到 RDB 和 AOF 做持久化吗？

Stream 是新增加的数据类型，它与其它数据类型一样，每个写操作，也都会写入到 RDB 和 AOF 中。

我们只需要配置好持久化策略，就算 Redis 宕机重启，Stream 中的数据也可以从 RDB 或 AOF 中恢复回来。

 

5) Stream 是如何处理消息堆积的？

其实，当消息队列发生消息堆积时，一般只有 2 个解决方案：

1. 生产者限流：避免消费者处理不及时，导致持续积压

2. 丢弃消息：中间件丢弃旧消息，只保留固定长度的新消息

而 Redis 在实现 Stream 时，采用了第 2 个方案。

在发布消息时，你可以指定队列的最大长度，防止队列积压导致内存爆炸。

// 队列长度最大10000
127.0.0.1:6379> XADD queue MAXLEN 10000 * name zhangsan
"1618473015018-0"

当队列长度超过上限后，旧消息会被删除，只保留固定长度的新消息。

这么来看，Stream 在消息积压时，如果指定了最大长度，还是有可能丢失消息的。

Stream 还支持查看消息长度（XLEN）、查看消费者状态（XINFO）等命令

 

既然Stream 几乎覆盖到了消息队列的各种场景，这是不是意味着，Redis 真的可以作为专业的消息队列中间件来使用呢？

还「差一点」。

 

与消息队列Mq对比

一个消息队列必须要做到两大块：

1. 消息不丢

2. 消息可堆积

前面我们很大篇幅是围绕消息不丢失展开的。

这里我们换个角度，从一个消息队列的「使用模型」来分析一下，怎么做，才能保证数据不丢？

使用一个消息队列，其实就分为三大块：生产者、队列中间件、消费者。

 

消息是否会发生丢失，其重点也就在于以下 3 个环节：

1. 生产者会不会丢消息？

2. 消费者会不会丢消息？

3. 队列中间件会不会丢消息？

1) 生产者会不会丢消息？

当生产者在发布消息时，可能发生以下异常情况：

1. 消息没发出去：网络故障或其它问题导致发布失败，中间件直接返回失败

2. 不确定是否发布成功：网络问题导致发布超时，可能数据已发送成功，但读取响应结果超时了

如果是情况 1，消息根本没发出去，那么重新发一次就好了。

如果是情况 2，生产者没办法知道消息到底有没有发成功？

所以，为了避免消息丢失，它也只能继续重试，直到发布成功为止。

生产者一般会设定一个最大重试次数，超过上限依旧失败，需要记录日志报警处理。

也就是说，生产者为了避免消息丢失，只能采用失败重试的方式来处理。

但这也意味着消息可能会重复发送。

是的，在使用消息队列时，要保证消息不丢，宁可重发，也不能丢弃。

那当消费者收到重复数据数据时，要设计幂等逻辑，保证业务的正确性。

从这个角度来看，生产者会不会丢消息，取决于生产者对于异常情况的处理是否合理。

所以，无论是 Redis 还是专业的队列中间件，生产者在这一点上都是可以保证消息不丢的。

 

2) 消费者会不会丢消息？

消费者拿到消息后，还没处理完成就异常宕机了，那消费者还能否重新消费失败的消息？

要解决这个问题，消费者在处理完消息后，必须「告知」队列中间件，队列中间件才会把标记已处理，否则仍旧把这些数据发给消费者。

这种方案需要消费者和中间件互相配合，才能保证消费者这一侧的消息不丢。

所以，从这个角度来看，Redis 也是合格的。

 

3) 队列中间件会不会丢消息？

前面 2 个问题只要客户端和服务端配合好，就能保证生产端、消费端都不丢消息。

但是，如果队列中间件本身就不可靠呢？

毕竟生产者和消费这都依赖它，如果它不可靠，那么生产者和消费者无论怎么做，都无法保证数据不丢。

在这个方面，Redis 其实没有达到要求。

Redis 在以下 2 个场景下，都会导致数据丢失。

1. AOF 持久化配置为每秒写盘，但这个写盘过程是异步的，Redis 宕机时会存在数据丢失的可能

2. 主从复制也是异步的，主从切换时，也存在丢失数据的可能（从库还未同步完成主库发来的数据，就被提成主库）

基于以上原因我们可以看到，Redis 本身的无法保证严格的数据完整性。

 

那么，专业的消息队列中间件是如何解决这个问题的？

像 RabbitMQ 或 Kafka 这类专业的队列中间件，一般是部署一个集群，生产者在发布消息时，队列中间件通常会写「多个节点」，以此保证消息的完整性。这样一来，即便其中一个节点挂了，也能保证集群的数据不丢失。

也正因为如此，消息队列在设计时也更复杂。毕竟，它们是专门针对队列场景设计的。

 

4) 消息积压如何处理？

因为 Redis 的数据都存储在内存中，所以一旦发生消息积压，则会导致 Redis 的内存持续增长，如果超过机器内存上限，就会面临被 OOM 的风险。

Redis 的 Stream 提供了可以指定队列最大长度的功能，就是为了避免这种情况发生。

但 Kafka、RabbitMQ 这类消息队列就不一样了，它们的数据都会存储在磁盘上，磁盘的成本要比内存小得多。

综上，把 Redis 当作队列来使用时，始终面临的 2 个问题：

1. Redis 本身可能会丢数据

2. 面对消息积压，Redis 内存资源紧张

Redis 是否可以用作队列，我想这个答案应该会比较清晰了。

如果你的业务场景足够简单，对于数据丢失不敏感，而且消息积压概率比较小的情况下，把 Redis 当作队列是完全可以的。

而且，Redis 相比于 Kafka、RabbitMQ，部署和运维也更加轻量。

 

总结

我们介绍了 List、Pub/Sub、Stream 在做队列的使用方式，以及它们各自的优劣。

之后又把 Redis 和消息队列中间件做对比，发现 Redis 的不足之处。

最后，我们得出 Redis 做队列的合适场景。

 

 

消息队列对比总结一下：

目前常用的几个中间件从这些维度来考虑：可靠性，性能，功能，可运维行，可拓展性，社区活跃度。

ActiveMQ作为“老古董”，市面上用的已经不多，其它几种：

RabbitMQ：
优点：轻量，迅捷，容易部署和使用，拥有灵活的路由配置
缺点：性能和吞吐量不太理想，不易进行二次开发

RocketMQ：
优点：性能好，高吞吐量，稳定可靠，有活跃的中文社区
缺点：兼容性上不是太好

Kafka：
优点：拥有强大的性能及吞吐量，兼容性很好
缺点：由于“攒一波再处理”导致延迟比较高

我们之前的案例，有做过性能测试。现简单附rocketMq 和kafka 测试对比。

主要围绕两个测试进行。

1 测试-topic数量的支持

如下图所示，测试环境：

Kafka 0.8.2

RocketMQ 3.4.6

1.0 Gbps Network

16 threads

 这张图是Kafka和RocketMQ在不同topic数量下的吞吐测试。横坐标是每秒消息数，纵坐标是测试case。同时覆盖了有无消费，和不同消息体的场景。一共8组测试数据，每组数据分别在topic个数为16、32、64、128、256时获得的，每个topic包括8个partition。下面四组数据是发送消息大小为128字节的情况，上面四种是发送2k消息大小的情况。on 表示消息发送的时候，同时进行消息消费，off表示仅进行消息发送。

先看最上面一组数据，用的是kafka，开启消费，每条消息大小为2048字节。可以看到，随着topic数量增加，到256 topic之后，吞吐极具下。

可以先看最上面的一组结果，用的是Kafka，开启消费，每条消息是2kb（2048）。可以看到，随着topic数量增加，到256个topic之后，吞吐急剧下降。

第二组是是RocketMQ。可以看到，topic增大之后，影响非常小。

第三组和第四组，是上面两组关闭了消费的情况。结论基本类似，整体吞吐量会高那么一点点。

下面的四组跟上面的区别是使用了128字节的小消息体。可以看到，kafka吞吐受topic数量的影响特别明显。对比来看，虽然topic比较小的时候，RocketMQ吞吐较小，但是基本非常稳定，对于我们这种共享集群来说比较友好。

 

2 测试-延迟

• Kafka

测试环境：

Kafka 0.8.2.2

topic=1/8/32

Ack=1/all，replica=3

测试结果：如下图

（横坐标对应吞吐，纵坐标对应延迟时间）

上面的一组的3条线对应ack=3，需要3个备份都确认后才完成数据的写入。

下面的一组的3条线对应ack=1，有1个备份收到数据后就可以完成写入。

可以看到下面一组只需要主备份确认的写入，延迟明显较低。

每组的三条线之间主要是topic数量的区别，topic数量增加，延迟也增大了。

• RocketMQ

测试环境：

RocketMQ 3.4.6

brokerRole=ASYNC/SYNC_MASTER, 2 Slave

flushDiskType=SYNC_FLUSH/ASYNC_FLUSH

测试结果：如下图

上面两条是同步刷盘的情况，延迟相对比较高。下面的是异步刷盘。

橙色的线是同步主从，蓝色的线是异步主从。

然后可以看到在副本同步复制的情况下，即橙色的线，4w的tps之内都不超过1ms。用这条橙色的线和上面Kafka的图中的上面三条线横向比较来看，kafka超过1w tps 就超过1ms了。kafka的延迟明显更高。

1、由于我们系统的qps压力比较大，所以性能是首要考虑的要素。
2、开发语言，由于我们的开发语言是java，主要是为了方便二次开发。
3、对于高并发的业务场景是必须的，所以需要支持分布式架构的设计。
4、功能全面，由于不同的业务场景，可能会用到顺序消息、事务消息等。

具有一定的并发量，对性能也有比较高的要求，所以选择了低延迟、吞吐量比较高，可用性比较好的RocketMQ。

那么，

3.RocketMQ有什么优缺点？

RocketMQ优点：

• 单机吞吐量：十万级

• 可用性：非常高，分布式架构

• 消息可靠性：经过参数优化配置，消息可以做到0丢失

• 功能支持：MQ功能较为完善，还是分布式的，扩展性好

• 支持10亿级别的消息堆积，不会因为堆积导致性能下降

• 源码是Java，方便结合公司自己的业务二次开发

• 天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况

• RoketMQ在稳定性上可能更值得信赖，这些业务场景在阿里双11已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择RocketMQ

RocketMQ缺点：

• 支持的客户端语言不多，目前是Java及c++，其中c++不成熟

• 没有在 MQ核心中去实现JMS等接口，有些系统要迁移需要修改大量代码

消息队列有两种模型：队列模型和发布/订阅模型

1. 队列模型
这是最初的一种消息队列模型，对应着消息队列发-存-收的模型。生产者往某个队列里面发送消息，一个队列可以存储多个生产者的消息，一个队列也可以有多个消费者，但是消费者之间是竞争关系，也就是说每条消息只能被一个消费者消费。

2. 发布/订阅模型
如果需要将一份消息数据分发给多个消费者，并且每个消费者都要求收到全量的消息。很显然，队列模型无法满足这个需求。解决的方式就是发布/订阅模型。
在发布 - 订阅模型中，消息的发送方称为发布者（Publisher），消息的接收方称为订阅者（Subscriber），服务端存放消息的容器称为主题（Topic）。发布者将消息发送到主题中，订阅者在接收消息之前需要先订阅主题。“订阅”在这里既是一个动作，同时还可以认为是主题在消费时的一个逻辑副本，每份订阅中，订阅者都可以接收到主题的所有消息。

它和 队列模式的异同：生产者就是发布者，队列就是主题，消费者就是订阅者，无本质区别。唯一的不同点在于：一份消息数据是否可以被多次消费

RocketMQ使用的消息模型是怎样的呢？RocketMQ使用的消息模型是标准的发布-订阅模型，在RocketMQ的术语表中，生产者、消费者和主题，与发布-订阅模型中的概念是完全一样的。

消息消费模式有两种：Clustering（集群消费）和Broadcasting（广播消费）。

默认情况下就是集群消费，这种模式下一个消费者组共同消费一个主题的多个队列，一个队列只会被一个消费者消费，如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。

而广播消费消息会发给消费者组中的每一个消费者进行消费。

RocketMQ的基本架构

RocketMQ 一共有四个部分组成：NameServer，Broker，Producer 生产者，Consumer 消费者，它们对应了：发现、发、存、收，为了保证高可用，一般每一部分都是集群部署的

类比一下我们生活的邮政系统——
邮政系统要正常运行，离不开下面这四个角色， 一是发信者，二 是收信者， 三是负责暂存传输的邮局， 四是负责协调各个地方邮局的管理机构。对应到 RocketMQ 中，这四个角色就是 Producer、 Consumer、 Broker、NameServer

未完待续...

文：一只阿木木

欢迎转发、交流小数据。