白话解释一下
mq就是个软件，接收来自某一方的消息，同时其他的地方也可以从他这里拿到消息。
很常见的场所，菜鸟驿站，每个小区都有自己的菜鸟驿站，每个小区的人只关注自己小区的菜鸟驿站。我是这么理解的，把mq消息队列看成消息池，消息队列起到了缓冲和存储消息的作用。一定程度上看成是是池化思想的体现？（如线程池，数据库连接池等，特性：预先创建和管理一组资源，以减少资源创建和销毁的开销，提高资源的复用率和系统的性能）
为什么要使用消息队列？
系统解耦，异步处理，流量削峰
异步
解耦
提高系统的可用性和拓展性
削峰
应用场景比如：每次一到16点~23点,每秒并发请求数量突然会暴增到1万条。但是系统最大的的处理能力就只能是每秒钟处理1000个请求。怎么办?需要我们进行流量的削峰,让系统可以平缓的处理突增的请求。
如何选择合适的消息队列
RabbitMQ于2007年发布,是使用Erlang编程语言编写的,最早是为电信行业系统之间的可
靠通信设计的,也是少数几个支持AMQP协议的消息队列之一RabbitMQ:轻量级、迅捷,它的宣传口号,也很明确地表明了RabbitMQ的特点:Messaging that just works,开箱即用的消息队列。也就是说,RabbitM1Q是一个相当轻量级的消息队列,非常容易部署和使用。
RabbitMQ的客户端支持的编程语言大概是所有消息队列中最多的。
RabbitMQ的问题
RabbitMQ对消息堆积的支持并不好,当大量消息积压的时候,会导致RabbitMQ的性能急剧
下降。RabbitMQ的性能是这几个消息队列中最差的,大概每秒钟可以处理几万到十几万条消息。如
果应用对消息队列的性能要求非常高,那不要选择RabbitMQ,RabbitMQ使用的编程语言Erlang,扩展和二次开发成本高
Apache Kafka是一个分布式消息发布订阅系统。它最初由Linkedin公司基于独特的设计实现为
一个分布式的日志提交系统,之后成为Apache项目的一部分。
在早期的版本中,为了获得极致的性能,在设计方面做了很多的牺牲,比如不保证消息的可靠
性,可能会丢失消息,也不支持集群,功能上也比较简陋,这些牺牲对于处理海量日志这个特定
的场景都是可以接受的。
但是,随后几年Kafka逐步补齐了这些短板,当下的Kafka已经发展为一个非常成熟的消息队列
产品,无论在数据可靠性、稳定性和功能特性等方面都可以满满足绝大多数场景的需求。
Kafka与周边生态系统的兼容性是最好的没有之一,尤其在天数据和流计算领域,几乎所有的相
关开源软件系统都会优先支持 Kafka。
Kafka性能高效、可扩展良好并且可持久化。它的分区特性,可复制和可容错都是不错的特性。
Kafka使用Scala和Java语言开发,设计上大量使用了批量和异步的思想,使得Kafka能做到
超高的性能。Kafka的性能,尤其是异步收发的性能,是三者中最好的,但与RocketMQ并没有
量级上的差异,大约每秒钟可以处理几十万条消息。
在有足够的客户端并发进行异步批量发送,并且开启压缩的情况下,Kafka的极限处理能力可以
超过每秒2000万条消息。
Kafka的问题
Kafka异步批量的设计带来的问题是,它的同步收发消息的响应时延比较高,因为当客户端发送
一条消息的时候,Kafka并不会立即发送出去,而是要等一会儿攒一批再发送,在它的Broker
中,很多地方都会使用这种先攒一波再一起处理的设计。当你的业务场景中,每秒钟消息数量没
有那么多的时候,Kafka的时延反而会比较高。所以,Kafka不太适合在线业务场景。
topic达到上百个时,吞吐量会大幅下降。
RocketMQ是阿里巴巴在2012年开源的消息队列产品,用Java语言实现,在设计时参考了
Kafka,并做出了自己的一些改进,后来捐赠给Apache软件:基金会,2017正式毕业,成为
Apache的顶级项目。RocketMQ在阿里内部被广泛应用在订单,交易,充值,流计算,消息推
送,日志流式处理,Binglog分发等场景。经历过多次双十一考验,它的性能、稳定性和可靠性
都是值得信赖的。
RocketMQ有着不错的性能,稳定性和可靠性,具备一个现代的消息队列应该有的几乎全部功能
和特性,并且它还在持续的成长中。
RocketMQ有非常活跃的中文社区,大多数问题可以找到中文的答案。RocketMQ使用Java语
言开发,源代码相对比较容易读懂,容易对RocketMQ进行扩展或者二次开发。
RocketMQ对在线业务的响应时延做了很多的优化,大多数情请况下可以做到毫秒级的响应,如果
你的应用场景很在意响应时延,那应该选择使用RocketMQ.
RocketMQ的性能比RabbitMQ要高一个数量级,每秒钟大概能处理几十万条消息。
RocketMQ的问题
RocketMQ的劣势是与周边生态系统的集成和兼容程度不够。
