MQ 系列之初识消息中间件

1.1 简介

1.1.1 概述

  消息中间件(MQ)适用于需要可靠的数据传送的分布式环境。采用消息中间件机制的系统中，不同的对象之间通过传递消息来激活对方的事件，完成相应的操作。发送者将消息发送给消息服务器，消息服务器将消息存放在若干队列中，在合适的时候再将消息转发给接收者。消息中间件能在不同平台之间通信，它常被用来屏蔽掉各种平台及协议之间的特性，实现应用程序之间的协同，其优点在于能够在客户和服务器之间提供同步和异步的连接，并且在任何时刻都可以将消息进行传送或者存储转发，这也是它比远程过程调用更进一步的原因。

1.1.2 为什么会有消息中间件

☞ 解耦

  举个例子，李二同学负责开发一个数据系统，咱们姑且称之为 M 系统，M 系统中会产生许多重要数据，其他系统中需要这些数据就会问 M 系统要，这天负责 A 系统的小哥来找李二同学说，咱需要用到 M 系统的数据，你调一下这个接口，把数据给我。李二同学心想，你要数据又不是我要，再说了你要是代码有 Bug，调用你的接口我岂不是跟着一起凉凉，但是碍于情面还是给做了。第二天负责 B 系统的小姐姐也来找李二同学说要数据，接着 C、D、E、F 也说要数据。李二同学差点崩溃，周末就约了几个系统的开发者一起一爬山、拍照，笑嘻嘻的说：我还有机会吗？同样的事情发生在了张三同学身上，但是张三同学就聪明多了，直接将产生的数据丢到 MQ 中，谁要自己去拿！

☞ 异步

  再举个例子，老张和小李同时面试一家公司，面试题目是写一个程序，要求执行之后会给 A 推送微信消息，给 B 发邮件，给 C 发短信。小李一看，这特么太简单了，啪啪啪，就写好了，执行耗时 500 ms；突然小李发现旁边的老张执行耗时只有 80 ms，就问你怎么比我快这么多。老张说我只需要让 MQ 通知微信模块、邮件模块、短信模块发消息就好了，至于怎么发是他们的事。

☞ 削峰

  还是举个例子，喵公司和汪公司是竞争关系，一天喵公司要举办超级美少女大赛，就让公司程序员喵仙人开发一个报名系统。汪公司得知这个消息，跟风举办超级美少男大赛，让公司程序员哈士奇开发一个报名系统。数千万的少男少女坐在电脑前等待报名通道开启后一窝蜂的提交报名申请，汪公司的系统承受不住这么高的压力直接GG，喵公司则是一点问题没有。经过分析发现，汪公司的系统直接处理报名数据，数据量达到无法处理的时候系统GG，而喵公司则是将报名数据扔到 MQ 中，慢慢的交给系统处理，保证可以承受。

1.2 常见消息中间件

ActiveMQ：ActiveMQ 是 Apache 出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持 JMS1.1 和 J2EE 1.4 规范的 JMS Provider 实现。 RabbitMQ：AMQP 协议的领导实现，支持多种场景。淘宝的 MySQL 集群内部有使用它进行通讯， OpenStack 开源云平台的通信组件，最先在金融行业得到运用。 Kafka：Kafka 是一个分布式消息发布订阅系统。它最初由 LinkedIn 公司基于独特的设计实现为一个分布式的日志提交系统，之后成为 Apache 项目的一部分。Kafka 性能高效、可扩展良好并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。 RocketMQ：出自阿里的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更好。RocketMQ 在阿里内部被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog 分发等场景。

1.3 几种中间件对比

1.3.1 对比表

1.3.2 整体分析

  ActiveMQ 非常成熟，功能强大，在业内大量的公司以及项目中都有应用，偶尔会有较低概率丢失消息，但现在社区以及国内应用都越来越少，官方社区现在对 ActiveMQ 5.x 维护越来越少，几个月才发布一个版本。主要是用于解耦和异步，较少在大规模吞吐的场景中使用。

  RabbitMQ 由 erlang 语言开发，性能极其好，延时很低；吞吐量到万级，MQ 功能比较完备，而且开源提供的管理界面非常棒，用起来很好用，社区相对比较活跃，几乎每个月都发布几个版本。在国内一些互联网公司近几年用 rabbitmq 也比较多一些，但是问题也是显而易见的，RabbitMQ 确实吞吐量会低一些，这是因为他做的实现机制比较重。而且 erlang 开发，国内有几个公司有实力做 erlang 源码级别的研究和定制？如果说你没这个实力的话，确实偶尔会有一些问题，你很难去看懂源码，你公司对这个东西的掌控很弱，基本职能依赖于开源社区的快速维护和修复 bug。

  RocketMQ 接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障，日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是 ok 的，还可以支撑大规模的 topic 数量，支持复杂 MQ 业务场景，而且一个很大的优势在于，阿里出品都是 java 系的，我们可以自己阅读源码，定制自己公司的 MQ，可以掌控。社区活跃度相对较为一般，文档相对来说简单一些，接口不是按照标准 JMS 规范走的有些系统要迁移需要修改大量代码。阿里出台的技术，得做好这个技术万一被抛弃，社区黄掉的风险。

  kafka 的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展，同时 kafka 最好是支撑较少的 topic 数量即可，保证其超高吞吐量，而且 kafka 唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略，这个特性天然适合大数据实时计算以及日志收集。