常用消息队列（ActiveMQ、RabbitMQ、RocketMQ、Kafka）及其特点

1.为什么要引入消息中间件？

削峰

若系统在部分时段有大量超出系统压力上线的请求进入，MQ可以通过将短期压力分散开来。例如每日19:00公司有抽奖活动，每分钟有20万个请求，持续10分钟，而公司的抽奖系统只能支撑每分钟10万的请求，这时候可以先将请求积压在MQ中，待活动结束，一共积压100万条消息，然后再由抽奖系统花费10分钟慢慢的消化MQ中的消息。这就是削峰，将原本10分钟内的请求分摊到20分钟去完成，从而避免了服务器宕机的风险。

异步

对于一些耗时较久的操作，若使用同步操作，等待其完成再进行后续操作，会导致整个请求时长特别久（例如发短信、发邮件），可以通过MQ将该操作异步化，将耗时较长的操作丢给MQ，由MQ分发给对应的模块进行操作，而不影响主流程的正常返回。

解耦

若系统中，某些模块或系统之间的调用很复杂，而且并非一定要同步操作，可以考虑使用MQ来进行解耦操作。例如系统A会产生一个比较重要的数据，而该数据会被多个系统消费，后期可能还会扩展到其它系统使用，倘若每次扩展或减少系统调用，都会导致A系统会进行代码的修改，整个系统就耦合的很紧。若使用了MQ，则可以直接将该数据扔在MQ中，有需要的其它系统直接去MQ中消费即可

---

2.引入消息中间件会导致什么问题

系统可用性降低

主要在于在原有的基础上，增加了额外的MQ系统，倘若MQ挂掉，会导致整个系统的崩溃。

系统复杂性增加

MQ的增加，会带来如消息丢失、消息重复消费、消息消费顺序错误等问题，使整个系统的设计变的更为复杂

系统一致性不能保证

由于在调用MQ进行异步操作后，原流程就直接返回成功，但倘若这是MQ的调用出现了问题，则会导致用户界面显示成功，实际系统调用失败的不一致问题

---

3.常见MQ的特点

ActiveMQ

单机吞吐量在万级，时效性在ms级，由于是老牌的MQ架构，整体功能非常成熟，在早几年的项目中应用的很广泛。并且ActiveMQ是由纯java开发，故只要系统支持java虚拟机，就能很好的支持ActiveMQ。但近几年的官方社区活跃度较低，-平均几个月才更新一个版本，维护的频率也越来越低，故整体来说，使用出现缺陷无人解决的风险较大。

RabbitMQ

单机吞吐量在万级，时效性在微妙级，整个架构是基于erlang语言开发的一款开源MQ，性能极好。但由于是erlang开发，那么公司想要定制化的调优就变得相当困难，好在目前官方社区活跃，维护频率较高，平均每个月更新几个版本，倒也不用太担心BUG修复的问题。另外，RabbitMQ的webConsole页面做的相当好，可用很方便的对MQ的运行状况进行操作和监控。

RocketMQ

单机吞吐量在十万级，时效性在ms级，该MQ是阿里开源的一款产品，整体是基于java开发的一款分布式消息中间件，故其扩展性特别好。该产品在阿里内部已经广泛使用，其性能和问题已经得到了验证，日处理消息可用达到上百亿之多，并且其对大规模topic的支持也特别好。但其并不是基于标准的JSM规范走的，故若要引入可能需要修改相关代码，另外阿里出品，可能突然某天维护该项目的项目组会解散，会导致中小型公司面临无人维护自己却也无力维护的尴尬境地。

Kafka

kafka的特点就是以提供较少的核心功能来保证较高的吞吐量，其吞吐量在十万级，时效性在ms级，主要用于大数据领域的实时计算和日志采集。kafka也支持大规模topic，但相对RocketMQ来说，需要提供更多的机器资源来实现。缺点是kafka会导致消息的重复消费。

---

4.如何解决消息中间件带来的问题

如何保证系统高可用

1.RabbitMQ：

RabbitMQ由三种模式：单机模式、普通集群模式、镜像集群模式。生产上显然不会使用单机模式，要保证高可用，只需要开启镜像集群模式即可，具体步骤是打开webConsole控制台页面，新增一个镜像模式的策略，然后设置数据同步到所有节点（或指定数量的节点）即可。

  2.Kafaka

Kafka是在0.8版本以后，提供了replica副本机制，即每个partition上的数据都会同步到对应的副本机器上。