中间件有哪些(运维常用的中间件有哪几种)

真正将MQ应用到项目中的第一步是什么？

让我们考虑一下。如果我们想在一个项目中使用一项新技术，是否应该先了解市场上有哪些常用的框架？所以我们应该从技术研究开始，选择合适的框架来应用于我们的项目。

有哪些中间件可供选择？其实主流的消息中间件有四种:kafka、ActiveMQ、RocketMQ、RabbitMQ。

我们来看看它们之间的区别，应该用在哪些场景中？

ActiveMQ

我们先来看看ActiveMQ。其实早期的项目一般都需要引入消息中间件，都是用这个MQ，现在用的不多了。说白了就是有些过时了。看一下官网，你会发现官网已经不活跃了，很长一段时间只会更新一次。

它的单机吞吐量是10000，一些小项目是够用的，但是对于高并发的互联网项目就不够用了。

在高可用性上，采用主从架构实现。

就消息可靠性而言，数据丢失的概率很低。

综上所述，其实这个产品基本可以废弃，我们完全可以用RabbitMQ来替代。

RabbitMQ

rabbitMQ出现后，国内大部分公司从activeMQ转到rabbitMQ，基本上取代了activeMQ。它的社区仍然非常活跃。

它的单机吞吐量也是10000，在需要支持极高并发的时候无法担当重任。

在高可用性方面，它采用镜像集群模式，可以保证高可用性。

在消息可靠性方面，可以保证数据不会丢失，这也是它的一大优势。

同时，它还支持消息中间件的一些高级功能，如消息重试、死信队列等。(这将在下一篇文章中讨论)。

但是它的开发语言是erlang，国内很少有人精通erlang，所以看不懂源代码。

对于大多数中小型公司来说，在不面临技术挑战的情况下使用它是合适的。对于一些大型BAT互联网公司来说，显然是不合适的。

RocketMQ

接下来讨论一下我最喜欢的MQ——rocket MQ，这是阿里的开源消息中间件。它已经被证明是可靠的。

它支持高吞吐量，可以达到10万级，可以承受互联网项目高并发的挑战。

在高可用性方面，它采用分布式架构，可以构建高性能的大规模集群。

在消息可靠性方面，通过配置，可以保证绝对的数据丢失，

同时支持大量高级功能，如:延时消息、事务消息、消息回溯、死信队列等。(后续文章会单独解释)。

它非常适合java系统架构，因为它是用java语言开发的，所以我们可以阅读源代码来了解底层原理。

目前没有特别的缺点。它可以支持高并发下的技术挑战，并在此基础上实现分布式事务。大型互联网公司和中小型公司可以选择使用它作为消息中间件。如果我选择技术，我首选的中间件是it。

Kafka

Kafka的吞吐量是中间件中公认的佼佼者，单机可以支持几十万并发，相当强大。

高可用性也支持分布式集群部署。

在消息可靠性方面，如果保证异步性能，消息可能会丢失，因为它保存消息时，先存储在磁盘缓冲区。如果机器出现故障，缓冲区中的数据可能会丢失(将在下一篇文章中讨论)。

它的功能很单一，就是收发消息，所以不适合很多场景。

主要应用于行业大数据领域，用于收集和计算用户行为日志，实现“猜你喜欢”等功能。

所以，如果对大数据没有需求，一般不会选择。