RocketMQ原理解析之服务安装启动

一、RocketMQ简介

    阿里的消息中间件有很长的历史，从2007 年的Notify 到2010 年的Napoli,2011 年升级后改为MetaQ ，然后到2012 年开始做RocketMQ, RocketMQ 使用Java 语言开发，于2016 年开源。第一代的Notify 主要使用了推模型(push)，解决了事务消息；第二代的MetaQ 主要使用了拉模型(pull)，解决了顺序消息和海量堆积的问题。RocketMQ 基于长轮询的拉取方式， 兼有两者的优点。
    消息队列是基于“先进先出(FIFO)” 的一种数据结构, 随着互联网的发展，“微架构” 的模式不段兴起, 这些微服务可以再同一个局域网内，也可以跨机房部署，这使得服务之间松耦合要求越来越高, 并且服务之间的联系越来越紧密。这对通信质量要求越来越高, 对消息队列也有了更高的要求。

二、消息队列提供的功能

2.1 应用解耦

    复杂的应用里会存在多个子系统, 比如：电商系统中有 会员中心、用户中心、交易中心、支付中心、营销中心、库存中心、物流中心、通用中心等。传统的开发是前面的各个中心放在一个应用中, 这使得各个子系统之间的耦合性太高了，整个系统的可用性比较低， 即使各个子模块是低错误率系统，但是整合到一起可能会是一个高错误率的系统。
举例: 以电商系统为例，用户在创建订单后，如果耦合调用库存系统，物流系统，支付系统，当其中一个子系统出现问题或者进行升级，都会造成整个下单流程失败, 严重影响用户的体验。
    如果系统之间的调用通过消息队列，系统的可用性会提高很多, 还是参照上面的例子， 如果物流系统出现BUG或者在进行升级, 可以将消息缓存在消息队列中, 在服务可以正常使用时再进行后续处理，保证这个服务再宏观上时可用的，终端客户也不会感受到故障的发生。
    可以参照下面的图进行比较:

图一、RocketMQ应用解耦

2.2 流量削峰

    在高并发的场景下，大部分应用系统的流量会达到峰值，如果没