消息队列简单总结

1.优势，使用场景

（1）异步处理

（2）解耦

（3）抗压

2.使用代价

（1）维护成本，挂掉怎么办，消息丢失怎么办

（2）数据一致性

3.选择消息队列

如何分析？

1.分析是否符合业务的基本要求，市面常见基本标准是否满足,接下来是性能，稳定性，安全性，最后一点是否有业界参考案例。

2.缺点，不满足什么要求，相互对比的劣势，要求成本

 

 

RabbitMq:

优点：简单，易用，具备点对点，订阅模式，消息确认等常见消息队列特点，快速上手

缺点：erlang编写，出现问题很难定位，二次开源麻烦；消息堆积能力差；与同款产品相比性能相对低点，每秒几万

参考场景：小项目，同步改异步，用来解决一部分问题，开箱即用

 

RocketMq:

优点：具备常见消息队列的功能，包括事务消息；性能高，毫秒级消费，每秒十几万消费能力；稳定，有很多项目参考案例。

缺点：与很多框架生态集成不太容易

参考场景：实时性要求高的金融业务项目

 

kafka:

优点：具备基本功能，包括事务消息；性能高，表现在处理量大不是速度快；稳定，有很多项目参考案例；大数据领域生态发展好

缺点：消息延时处理稍差，

参考场景：数据埋点，日志记录，大数据相关处理

 

4.消息模型

RabbitMq：

主要思路：

生产者通过exchange 投放到队列，然后消费者从队列拉取消息进行消费

发布-订阅模式怎么实现？ 通过exchange 投放到多个队列，多个消费者消费

rabbitmq 各大模式也主要是在exchange上动手脚

 

 

RocketMq:

主要思路：

生产者生产消息根据nameserver 获取broker信息，再投递到具体的broker下的topic 的队列里面，消费者是一个组也可以是一台机器，消费一个或多个topic下队列的消息

 

发布订阅核心概念和rabbitMq 不一样的点在于：

rocketMq 是多个消费者组订阅同一个topic，只有一个队列有值，每个组各自消费

rabbitMq 是多个队列里面都有值，每个队列的消费者消费就是发布订阅 

 

5.使用

基于不同的设计思路，使用方式也不一样，各自功能也不一样

RabbitMq相关模式:

1基于队列

生产者与消费者一对一；

生产者与消费者一对多(work),只有一个能消费，不是每个都消费；

2.基于交换器exchange，发布订阅

(1)direct交换器，一对一key关联一致的队列

(2)fanout 交换器绑定的所有队列

(3)topic key通配符模糊匹配  

可以看出RabbitMq的设计以及思路还是相对简单的

 

RocketMq 相关模式