各种消息中间件对比与总结

喜欢ヅ旅行 2023-07-15 06:59 94阅读 0赞

**一：优劣对比**

消息中间件ActiveMq,RabbitMq,RocketMq,Kafka面试时可以从单机吞吐量，时效性，架构可靠性，消息可靠性，支持的功能等方面去讲

<table> 
 <tbody> 
  <tr> 
   <td style="width:80px;">&nbsp;</td> 
   <td>ActiveMq</td> 
   <td style="width:163px;">RabbitMq</td> 
   <td style="width:284px;">RocketMq</td> 
   <td style="width:291px;">Kafka</td> 
  </tr> 
  <tr> 
   <td style="width:80px;">单机吞吐量</td> 
   <td style="width:60px;">每秒万级</td> 
   <td style="width:163px;">每秒万级</td> 
   <td style="width:284px;">10万级</td> 
   <td style="width:291px;">10万级</td> 
  </tr> 
  <tr> 
   <td style="width:80px;">时效性</td> 
   <td style="width:60px;">毫秒级</td> 
   <td style="width:163px;">微秒级</td> 
   <td style="width:284px;">毫秒级</td> 
   <td style="width:291px;">毫秒级</td> 
  </tr> 
  <tr> 
   <td style="width:80px;">可用性</td> 
   <td style="width:60px;">基于主从架构</td> 
   <td style="width:163px;">基于主从架构</td> 
   <td style="width:284px;">天然支持分布式</td> 
   <td style="width:291px;">天然支持分布式</td> 
  </tr> 
  <tr> 
   <td style="width:80px;">消息可靠性</td> 
   <td style="width:60px;">较低概率丢失</td> 
   <td style="width:163px;">经过配置几乎可以0丢失</td> 
   <td style="width:284px;">经过配置几乎可以0丢失</td> 
   <td style="width:291px;">经过配置几乎可以0丢失</td> 
  </tr> 
  <tr> 
   <td style="width:80px;">功能</td> 
   <td style="width:60px;">及其完备</td> 
   <td style="width:163px;">基于erlang语言开发，并发能力强，延时很低</td> 
   <td style="width:284px;">接口简单易用，功能完备，扩展性好，比如支持，普通消息（同步发送，异步发送，单向发送），定时延时消息，顺序消息，事物消息</td> 
   <td style="width:291px;">功能较为简单，主要支持简单的mq功能，因为功能简单，在大数据以及日志采集方面用处广</td> 
  </tr> 
  <tr> 
   <td>数据存储</td> 
   <td>每个节点存储着所有的数据</td> 
   <td style="width:163px;">每个节点存储着所有的数据</td> 
   <td style="width:284px;">每个节点存储着一部分数据，并且每个节点都有数据备份，防数据丢失</td> 
   <td style="width:291px;">每个节点存储着一部分数据，并且每个节点都有数据备份，防数据丢失</td> 
  </tr> 
 </tbody> 
</table>

[参考一][Link 1]，[参考二][Link 2]，[参考三][Link 3]

**二：消息存储与消费**

1.  ### **RabbitMq** ###

*  是基于主从做高可用的，有三种模式：单机模式，普通集群模式，镜像集群模式，每台机器上存储着全量的数据。（这里不多做介绍）

1.  ### **[RocketMq][]** ###

*  **架构：**Producer （Producer Group）、Consumer （Consumer Group）、 NameServer 、Broker （Topic-->queue）、master/slave结构
    
     *  是天然支持分布式的，Topic由多个队列组成，队列会平均分散在多个Broker上，而Producer的发送机制保证消息尽量平均分布到所有队列中，最终效果就是所有消息都平均落在每个Broker上，类似elasticsearch存储数据一样
        
         *  ![kafaka/rocketmq][kafaka_rocketmq]
 *  **消息消费：**
    
     *    一个消费者集群（Consumer Group ）多台机器共同消费平均消费一个 topic 的多个队列，**一个队列只会被一个消费者消费**。如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费
     *  不同消费者组的消费者全量消费一个 topic 的多个队列所有的消息
     *  而每个消费者组在每个队列中的消费位置都是不同的。如果此时有多个消费者组，那么消息被一个消费者组消费完之后是不会删除的(因为其它消费者组也需要呀)，它仅仅是为每个消费者组维护一个 **消费位移(offset)** ，每次消费者组消费完会返回一个成功的响应，然后队列再把维护的消费位移加一，这样就不会出现刚刚消费过的消息再一次被消费![临近期末考试，一篇消息队列和RocketMQ的总结送给你们（二）][RocketMQ]
     *  **为什么一个主题中需要维护多个队列：**答案是 **提高并发能力**
     *  所以总结来说，RocketMQ 通过**使用在一个 Topic 中配置多个队列并且每个队列维护每个消费者组的消费位置** 实现了 **主题模式/发布订阅模式** 。
     *  [rocketmq的消息顺序消费][rocketmq]，在全局消息下是无法保证的，如果想要顺序消费那么就把消息单独发送到一个queue里面这样可以顺序消费
 *  **重复消费**
    
     *  发生重复消费的原因有3点
     *  **发送时消息重复**
        
        当一条消息已被成功发送到服务端并完成持久化，此时出现了网络闪断或者客户端宕机，导致服务端对客户端Producer 应答失败。 如果此时生产者Producer 意识到消息发送失败并尝试再次发送消息，消费者后续会收到两条内容相同并且 Message ID 也相同的消息。
     *  **投递时消息重复**
        
        消息消费的场景下，消息已投递到消费者并完成业务处理，当客户端给服务端反馈应答的时候网络闪断。为了保证消息至少被消费一次，消息队列 RocketMQ 版的服务端将在网络恢复后再次尝试投递之前已被处理过的消息，消费者后续会收到两条内容相同并且 Message ID 也相同的消息。
     *  负载均衡时消息重复（包括但不限于网络抖动、Broker 重启以及消费者应用重启）
        
        当消息队列 RocketMQ 版的 Broker 或客户端重启、扩容或缩容时，会触发 Rebalance，此时消费者可能会收到重复消息
     *  解决办法
        
         *  rocketmq消息重复问题解决起来是很复杂的一件事，所以最好的办法就是不解决，所以需要我们自己根据业务情况来去做幂等
 *  **消息类型**
    
     *  普通消息（同步发送，异步发送，单向发送）
     *  定时和延时消息
     *  顺序消息
     *  事物消息
 *  **[消息可靠性][Link 4]（可点击）**
    
     *  从Producer的视角来看：消息发送失败会丢失
     *  从Broker的视角来看：消息存持久化失败会丢失
     *  从Consumer的视角来看：消息返回消费成功应答码但是突然宕机消费失败会丢失
     *  解决：
        
         *  Producer可以采用同步阻塞式的发送，检查Brocker返回的状态是否持久化成功，状态超时或者失败，则会触发默认的2次重试，RocketMQ 选 择了确保一定投递，保证消息不丢失，但有可能造成消息重复
         *  Broker自身支持同步双写和异步刷盘的策略，可以保证接收到的消息一定存储在本地的内存中，并且Broke集群支持 1主N从的策略，支持同步复制和异步复制的方式，同步复制可以保证即使Master 磁盘崩溃，消息仍然不会丢失  2、Broker采取事务消息的投递方式，并不能保证消息100%投递成功到了Broker，但是如果消息发送Ack失败的话，此消息会存储在CommitLog当中
         *  Consumer可以关闭自动消费之后的响应码为手动状态，人为的确保消费成功之后再返回ack码，然后再更新消费唯一offset

1.  ### **[Kafka][]** ###

*  **架构：**Producer （Producer Group）、Consumer （Consumer Group）、zk(0.9版本之后弃用使用Broker存储元数据)、Broker （Topic-->Partition-->Replica）、Leader/Follower结构
    
     *  ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQ1NzEz_size_16_color_FFFFFF_t_70][]
     *  分布式架构的， Topic 可以分布到多个 Broker （即服务器）上，一个 Topic 可以分为多个 Partition，每个 Partition 是一个 有序的队列。**Replica：**副本，为实现备份的功能，保证集群中的某个节点发生故障时，该节点上的 Partition 数据不丢失，且 Kafka 仍然能够继续工作，Kafka 提供了副本机制，一个 Topic 的每个分区都有若干个副本，一个 Leader 和若干个 Follower。
     *  Topic 是逻辑上的概念，而 Partition 是物理上的概念，每个 Partition 对应于一个 log 文件，该 log 文件中存储的就是 Producer 生产的数据。Producer 生产的数据会不断追加到该 log 文件末端，且每条数据都有自己的 Offset。
 *  **消息消费**
    
     *  消费者组内每个消费者负责消费不同分区的数据，提高消费能力。一个分区只能由组内一个消费者消费，消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。这点跟RocketMq中的同一Consumer Group消费类似，这样方便扩展
 *  **存储机制**
    
     *  由于生产者生产的消息会不断追加到 log 文件末尾，为防止 log 文件过大导致数据定位效率低下，Kafka 采取了分片和索引机制。它将每个 Partition 分为多个 Segment，每个 Segment 对应两个文件：“.index” 索引文件和 “.log” 数据文件。
 *  **重复消费**
    
     *  Kafka消费数据会在zk里面记录当前消费者消费到的位置offset=第几条数据，每当消费者消费一条数据之后都会通知zk去提交消费者的位置，但是并不是每次消费一条数据都会去提交，而是定时定期提交一次offset,kafka后面的版本消费唯一offset都存在了broker上了，所以当消费者消费完之后还没有提交offset的时候突然宕机了，等启动之后然而位移没发生变化，就可能会出现重复消费。
     *  消息队列不保证消息的幂等性，需要我们自己根据业务去保证消息幂等性。
 *  **消息可靠性**
    
     *  从Producer的视角来看：消息发送失败会丢失
     *  从Broker的视角来看：消息存持久化失败会丢失
     *  从Consumer的视角来看：消息返回消费成功应答码但是突然宕机消费失败会丢失
     *  解决：
        
         *  为保证 Producer 发送的数据，能可靠地发送到指定的 Topic，Topic 的每个 Partition 收到 Producer 发送的数据后，都需要向 Producer 发送 ACK（ACKnowledge 确认收到）。如果 Producer 收到 ACK，就会进行下一轮的发送，否则重新发送数据
         *  何时发送 ACK？确保有 Follower 与 Leader 同步完成，Leader 再发送 ACK，这样才能保证 Leader 挂掉之后，能在 Follower 中选举出新的 Leader 而不丢数据。多少个 Follower 同步完成后发送 ACK？全部 Follower 同步完成，再发送 ACK。
         *  **ACK 应答机制**
            
             *  对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等 ISR 中的 Follower 全部接受成功。所以 Kafka 为用户提供了三种可靠性级别，用户根据可靠性和延迟的要求进行权衡，选择以下的配置。
             *  **0：**Producer 不等待 Broker 的 ACK，这提供了最低延迟，Broker 一收到数据还没有写入磁盘就已经返回，当 Broker 故障时有可能丢失数据。
             *  **1：**Producer 等待 Broker 的 ACK，Partition 的 Leader 落盘成功后返回 ACK，如果在 Follower 同步成功之前 Leader 故障，那么将会丢失数据。
             *  **-1（all）：**Producer 等待 Broker 的 ACK，Partition 的 Leader 和 Follower 全部落盘成功后才返回 ACK。但是在 Broker 发送 ACK 时，Leader 发生故障，则会造成数据重复。
             *  **![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQ1NzEz_size_16_color_FFFFFF_t_70 1][]**
         *  ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQ1NzEz_size_16_color_FFFFFF_t_70 2][]

参考：[Kafka1][]，[Kafka2][]

[Link 1]: https://www.toutiao.com/i6773192136738210307/?tt_from=weixin&utm_campaign=client_share&wxshare_count=2&from=singlemessage&timestamp=1577435795&app=news_article&utm_source=weixin&utm_medium=toutiao_android&req_id=201912271636340101290430191B04494F&group_id=6773192136738210307&pbid=6703867960429594123
[Link 2]: https://blog.csdn.net/javahongxi/article/details/84931747
[Link 3]: https://help.aliyun.com/document_detail/155952.html?spm=a2c4g.11186623.2.20.55747e80URqFeX
[RocketMq]: https://help.aliyun.com/document_detail/29532.html?spm=a2c4g.11186623.6.546.4b3036315YGuDG
[kafaka_rocketmq]: /images/20230528/12108cddb89f4a89a8ac9167924b59f0.png
[RocketMQ]: /images/20230528/95afb69d5f0c4ff2a7b2daad79c8d60b.png
[rocketmq]: https://cloud.tencent.com/developer/article/1451219
[Link 4]: https://blog.csdn.net/qq_38545713/article/details/104758104
[Kafka]: https://mp.weixin.qq.com/s/VzNF4-3HuPZldi2TpV-kjg
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQ1NzEz_size_16_color_FFFFFF_t_70]: /images/20230528/c32bc211da93487aa1858769327073d9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQ1NzEz_size_16_color_FFFFFF_t_70 1]: /images/20230528/579da6ebdbc345a6bfc6727e2d08a907.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQ1NzEz_size_16_color_FFFFFF_t_70 2]: /images/20230528/112249c03bd642bf832ae5e86dc4ccb2.png
[Kafka1]: https://blog.csdn.net/qq_38545713/article/details/104894860
[Kafka2]: https://mp.weixin.qq.com/s/MQidI8BsFCMzbJrbRtfCuQ