MQ应用场景分析

MQ对比文档

MQ主要做用

1.解耦

每一个成员没必要受其余成员的影响，一个大的系统拆分为多个子系统，子系统中间利用mq进行通讯，共享数据就是接耦的一种表现

2.异步通讯

有些业务不想也不须要当即处理消息。消息队列提供了异步处理机制，容许用户把一个消息放入队列，但并不当即处理它。想向队列中放入多少消息就放多少，而后在须要的时候再去处理它们。

2.削峰

利用消息中间件，不管前面压力又多大，对后端系统来讲，都是一个有序的过程，减小后端系统瞬时压力

3.消息广播

这是MQ自带的特性，进行消息的发送，消息有队列和广播模式，根据业务需求自行选择

MQ系统特性

• 提供丰富的消息订阅模式，
• 消息持久化以及可靠传输
• 消息重发机制
• 支持的队列数量
• 事务消息
• 顺序消息
• 消息堆积能力
• 消息消费模式
• 消息过滤
• 消息丢失
• 定时消息
• 可用性
• 并发性
• 容灾机制
• 单机吞吐量
• 负载均衡
• 可维护性
• 可扩展性

MQ对比

特性	ActiveMq	RabbitMq	Rocketmq	kafka
开发语言	java	erlang	java	Scala
消息订阅模式	完美支持JMS规范，支持订阅和广播模式	支持订阅广播模式	支持订阅广播模式	支持订阅广播模式
消息持久化	内存、文件、数据库	内存、文件	磁盘文件	磁盘文件
消息重发机制	支持	支持	支持	不支持
支持队列数量	大数量队列，mq会出问题	支持大数量队列	支持很大数量队列	支持大数量队列
事务消息	支持	支持	支持	不支持
顺序消息	支持（实现比较麻烦）	支持	支持严格的顺序消息，即便down机也不会乱序	支持
消息堆积能力	通常	通常	亿级消息堆积能力	亿级消息堆积能力
消息消费模式	广播、集群	广播、集群	广播、集群、回溯消费	极高
消息过滤	支持	不	支持客户端过滤和服务端过滤模式	不支持
消息丢失	低	低	理论上不会丢失	理论上不会丢失
定时消息	支持	支持	支持	不支持
可用性	高(主从)	高（主从）	极高（分布式）	极高（分布式）
并发性	高	极高	高	高
容灾机制	高	极高	极高	极高
单机吞吐量	万级	万级	万级	十万级
负载均衡	通常	极高	极高	极高
可维护性	高	高	高	高
可扩展性	通常	集群不支持动态扩展	集群支持动态扩展	支持动态扩展

ActiveMq是根据标准JMS规范实现的，采用JAVA编写，项目比较成熟。 Rabbitmq是erlang开发，所以他的并发性极高，要优于其余MQ，可是也是因为erlang语言的特性，集群不支持动态扩展。 Rocketmq是基于JAVA开发，在设计初衷，借鉴JMS和COBAR Notification规范。并且rocketmq里面的部署都是分布式，提供了同步双写，异步刷盘等多种存储策略，同时采用零拷贝技术，因此在兼顾数据一致性、可用性的时候他的吞吐量极高。 Kafak因为在实现上并无实现不少MQ的特性，因此他的性能比较优越，同时采用零拷贝技术，他的吞吐量能够说是业界目前最高的。

综上所述： MQ没有好坏之分，只有合适的应用场景合适的MQ 。 针对通常的业务场景，并发量不是太大，AMQ足以 。 针对注重数据一致性、可用性和稳定性比较高，可是吞吐量不怎么关心的时候能够采用Rabbitmq 。 针对流计算、日志、大数据方面的采用 Kafak 针对即注重数据一致性、稳定性、可用性的，又关心吞吐量的能够采用Rocketmq。