消息队列 -- active mq 安装测试

   1、我理解的消息队列

    国庆没有去看人山人海，窝在家里看了几本书，还剩一天突然想折腾一下message queue。以前也调研过message queue，还停留在了解的层面上。这次深入研究一下。

   我理解的消息队列,其实就是一个生产者消费模型的实现。其中有4个元素需要知道，consumer(消息的生产者)  producer(消费者) queue(队列) message(消息)。 

    

2、消息队列举例

2.1 消息队列应用:博客例子

举个写博客的列子:

消息:用户上传的博客的内容(标题，内容，分类等等)

生产者1：blogService ---  csdn的某个后台服务 

消费者1:   blogPersistenceService --- 博文存储服务,将博客存放到数据库

消费者2:   blogAnalysisService — 博文分析服务,分析是否是反动内容，黄赌毒内容，如果是的话后台会做一些处理)

消息队列：ActiveMQ

下面是一个完整的消息队列运作过程:

1用户写了一篇博文，将博文上传到csdn的blogServie(生产者1）

2 blogService 将博文封装并发送到ActiveMQ(消息队列)，这样就生产了一条消息MSG1

3 blogPersistenceService 将消息MSG1消费，取出博文，存入mysql服务器

4 blogAnalysisService 将消息MSG1消费，取出博文，对博文进行分析

5 ActiveMq(消息队列) 将MSG1从队列里删除

2.2我了解的消息队列应用场景

我知道的一些需要消息队列的场景(仅仅是个人理解):

1.上面的博客的例子:

   同一个消息需要被多个不同的异构的系统处理(一篇博文需要被blogPersistenceService和blogAnalysisService处理)

2.当消费者能力不够的时候，保证系统不被生产者压垮---平滑系统压力

  还是上面博客的例子，比如 blogPersistenceService 系统每小时处理博客的上限是1000篇。但是由于国庆节大家都不想去看“人山人海”，都窝在家里写博客，这一天的每小时提交的博客是5000篇。

   1）如果不使用消息队列的 — 用户提交博文，直接存储mysql。处理每小时上限是1000篇，但是来了5000篇。情况可能是mysql会由于连接过多抛异常，用户上传的博文数据丢失，或者blogPersistenceService崩溃。造成线上重大事故。

   2）使用消息队列的 — 用户提交博文，先通过ActiveMQ。处理每小时上限是1000篇，但是来了5000篇。blogPersistenceService每小时只能处理1000篇，其余4000篇会缓存到队列里面(数据没有丢失)。这时候如果及时增加blogPersistenceService的能力,比如增加机器，将队列的blog消费掉，是不会丢失任何数据的。用户会因延迟抱怨，但是不会弄丢用户的数据，造成事故。 

3.ActiveMQ安装,测试

3.1.先决条件：

ActiveMQ依赖java需要配置java环境。