-
使用消息队列还可以降低系统耦合性。我们知道如果模块之间不存在直接调用，那么新增模块或者修改模块就对其他模块影响较小，这样系统的可扩展性无疑更好一些。
假设有这样的一个场景：A系统发送数据到B、C、D三个系统，通过接口调用发送。如果E系统也要这个数据呢?那如果C系统现在不需要了呢?A系统负责人几乎要改到崩溃……
在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A系统产生一条比较关键的数据，很多系统都需要A系统将这个数据发送过来。A系统要时时刻刻考虑B、C、D、E四个系统如果挂了该怎么办?要不要重发，要不要把消息存起来?头发都白了啊!
如果使用MQ，A系统产生一条数据，发送到MQ里面去，哪个系统需要数据自己去MQ里面消费。如果新系统需要数据，直接从MQ里消费即可;如果某个系统不需要这条数据了，就取消对MQ消息的消费即可。这样下来，A系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。
- ActiveMQ：的社区算是比较成熟，但是较目前来说，ActiveMQ的性能比较差，而且版本迭代很慢，不推荐使用。
- RabbitMQ：在吞吐量方面虽然稍逊于Kafka和RocketMQ ，但是由于它基于erlang开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。但是也因为RabbitMQ基于erlang开发，所以国内很少有公司有实力做erlang源码级别的研究和定制。如果业务场景对并发量要求不是太高(十万级、百万级)，那这四种消息队列中，RabbitMQ一定是你的首选。如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
- RocketMQ：阿里出品，Java系开源项目，源代码我们可以直接阅读，然后可以定制自己公司的MQ，并且 RocketMQ有阿里巴巴的实际业务场景的实战考验。RocketMQ 社区活跃度相对较为一般，目前RocketMQ已捐给 Apache，但 GitHub 上的活跃度其实不算高，文档相对来说简单一些，然后接口这块不是按照标准 JMS 规范走的有些系统要迁移需要修改大量代码。还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用RabbitMQ吧，人家有活跃的开源社区，绝对不会黄。
- Kafka：特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量。kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集。
