消息中间件总结（各个消息中间件对比、为什么要引入消息中间件及引入中间件后缺点）

• 消息中间件分类
  ActiveMQ、RabbitMQ、RocketMQ、kafka、PSQ

• 各个消息中间件对比：

  • RabbitMq 和Kafka比较
    • RabbitMq 比Kafka 成熟，在可用性上，稳定性上，可靠性上， RabbitMq 胜于 Kafka （理论上）。
    • 另外，Kafka 的定位主要在日志等方面， 因为Kafka 设计的初衷就是处理日志的，可以看做是一个日志（消息）系统一个重要组件，针对性很强，所以 如果业务方面还是建议选择 RabbitMq 。
    • 还有就是，Kafka 的性能（吞吐量、TPS ）比RabbitMq 要高出来很多。
  • Activemq、rabbitmq、rocketmq、kafka
    • ActiveMq几个月才发一次版本，据说研究重心在他们的下一代产品Apollo。没法确认能否支撑互联网公司的高并发、高负载及高吞吐量等场景。
    • RabbitMQ可以支撑高并发、高吞吐、性能很高，支持集群化、高可用部署架构、消息高可靠。RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug。但是RabbitMQ自身是基于erlang语言开发的，所以导致较为难以分析里面的源码。
    • rocketmq是阿里出品，支持高并发、高吞吐、分布式事务。Rocketmq是基于java语言开发的，适合深入阅读源码。
    • kafka提供的功能较少，优势在于专为超高吞吐量的实时日志采集、实时数据同步、实时数据计算等场景。
    • (1)中小型软件公司，建议选RabbitMQ.一方面，erlang语言天生具备高并发的特性，而且他的管理界面用起来十分方便。正所谓，成也萧何，败也萧何！他的弊端也在这里，虽然RabbitMQ是开源的，然而国内有几个能定制化开发erlang的程序员呢？所幸，RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug，这点对于中小型公司来说十分重要。
      不考虑rocketmq和kafka的原因是，一方面中小型软件公司不如互联网公司，数据量没那么大，选消息中间件，应首选功能比较完备的，所以kafka排除。
      不考虑rocketmq的原因是，rocketmq是阿里出品，如果阿里放弃维护rocketmq，中小型公司一般抽不出人来进行rocketmq的定制化开发，因此不推荐。
    • (2)大型软件公司，根据具体使用在rocketMq和kafka之间二选一。一方面，大型软件公司，具备足够的资金搭建分布式环境，也具备足够大的数据量。
      针对rocketMQ,大型软件公司也可以抽出人手对rocketMQ进行定制化开发，毕竟国内有能力改JAVA源码的人，还是相当多的。至于kafka，根据业务场景选择，如果有日志采集功能，肯定是首选kafka了。具体该选哪个，看使用场景。

• 你们用的是什么消息中间件

  • 专家管理系统用到了消息中间件
    
    图1
    其中EII就是个中间件，统一授权把数据放到EII，然后EII往下游系统推数据。因为不知道，所以暂且就说是ActiveMQ。
  • 那么我们为什么选择了ActiveMQ：
    i. 首先说我们是传统企业，采用用消息中间件，只是来做异步调用和系统解耦。在不考虑高并发、高吞吐、分布式这些场景下，首选ActiveMQ。
    ii. 据我了解，国内大大小小的互联网公司，使用的是RabbitMQ或者RocketMQ，两者都是支持高并发、分布式，区别在于前者采用的erlang语言开发的，所以导致难以分析源码或者进行二次开发。 后者采用java语言，适合深入阅读源码。

• 为什么要用消息中间件

  • 系统解耦、异步调用
    拿专家管理系统（图1）来说，需要从统一授权系统拿人员部门数据的不止上面3个系统，如果说每个系统都直接对接统一授权系统，比如有的系统新接入，需要统一授权系统修改代码。有的系统不再接入，也需要统一授权系统改代码。还有些系统需要加入一些标识但是其他系统不需要的这种情况，都需要统一授权系统改代码。

    就拿最近做的功能来讲：
    

    本来上传头像的功能已经测试完成，功能正常，没有任何问题。现在因为要加入头像审核，需要加入部分代码，难免会影响到原来的头像上传功能。而且头像审核毕竟是调用第三方系统，如果第三方系统有异常，都会影响到头像的上传。
    所以将调用第三方系统审核头像和头像上传两个功能分离，因为不确定第三方系统审核响应结果，所以异步调用。
    

  • 流量削峰
    这一点之前并没有想到，只是看到这，觉得原来的项目确实是符合这种的。
    专业资质认证系统一年申报两次，在非申报期间，每秒几十请求，只需要1-2台机器足够。但是再申报期间，每秒几百几千请求，很low的想法是多部署几台机器，来应对大量请求。但是非申报期间，机器资源将是浪费。
    
    所以采用了MQ中间件进行流量削峰。

  • 引用消息中间件的缺点

  • 系统可用性降低
    意思就是万一中间件系统挂掉了，将会影响到我们的业务系统。对中间件系统多了一个依赖，可用性就会降低。

  • 系统稳定性降低
    就拿专家管理系统（图1）来说，EII可能会丢失报文数据或者重复发送。

  • 分布式一致性问题

• 疑问：

  • 消息队列和消息中间件有什么区别？
  • 队列是先进先出？先进先出是队列的基本特性