学习淘淘商城第五十四课（为何引入ActiveMQ）

        我们在学习Solr索引的时候，每当添加一个商品后，都要把数据库中的数据全部重新导入到索引库，特别消耗性能和时间，这显然是我们所不能忍受的，这就需要优化我们的方案。最好是在商品添加的时候就单独将该商品同步到索引库，这样便简单快捷地实现了数据库与索引库的同步。

        摆在我们面前的方案有三个：

方案一：在taotao-manager中，添加商品的业务逻辑中，添加一段同步索引库的业务逻辑。

缺点：很明显，这样会导致业务逻辑耦合度很高，业务拆分不明确，这与我们当初拆分工程，职能单一、明确的原则相违背，故不可采用。

方案二：业务逻辑在taotao-search中实现，调用服务在taotao-manager实现，业务逻辑分开。

缺点：服务与服务之间耦合度变高，服务的启动有先后顺序。服务设计的原则便是各自干各自的活儿，启动要保证互不依赖，服务之间不应该有调用行为，一旦有调用行为，依赖的一方便会因被依赖一方出现故障而无法工作。

方案三：使用消息队列，MQ是一个消息中间件。如下图所示。

       怎么理解消息中间件呢？我们可以把它理解为一个秘书，消息的发布者就是大老板，大老板下午三点要开个会，他只需跟秘书说一声，下午三点，我要开个会，就行了，老板不用管秘书是怎样通知各项目经理的，也不用管项目经理要带什么材料，他所做的只是告诉秘书一声而已。秘书负责与各个项目经理联系，告诉各个项目经理应该准备什么。MQ便相当于"秘书"这个角色。当添加一个商品时，商品服务只需要告诉消息中间件MQ，MQ便去通知其它服务做各自该做的事情，比如通知搜索服务去同步索引库，通知redis服务去同步缓存，通知生成静态页面等等。

         常见的作为MQ的中间件有：ActiveMQ、RabbitMQ、Kafka。我们要学习的是ActiveMQ，其它的都大同小异。

         那么，什么是ActiveMQ？

         ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,尽管JMS规范出台已经是很久的事情了,但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。
        主要特点：
1. 多种语言和协议编写客户端。语言: Java, C, C++, C#, Ruby, Perl, Python, PHP。应用协议: OpenWire,Stomp REST,WS Notification,XMPP,AMQP
2. 完全支持JMS1.1和J2EE 1.4规范 (持久化,XA消息,事务)
3. 对Spring的支持,ActiveMQ可以很容易内嵌到使用Spring的系统里面去,而且也支持Spring2.0的特性
4. 通过了常见J2EE服务器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的测试,其中通过JCA 1.5 resource adaptors的配置,可以让ActiveMQ可以自动的部署到任何兼容J2EE 1.4 商业服务器上
5. 支持多种传送协议:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
6. 支持通过JDBC和journal提供高速的消息持久化
7. 从设计上保证了高性能的集群,客户端-服务器,点对点
8. 支持Ajax
9. 支持与Axis的整合
10. 可以很容易得调用内嵌JMS provider,进行测试

        ActiveMQ的消息形式

        对于消息的传递有两种类型：
一种是点对点的，即一个生产者和一个消费者一一对应；
另一种是发布/订阅模式，即一个生产者产生消息并进行发送后，可以由多个消费者进行接收。
JMS定义了五种不同的消息正文格式，以及调用的消息类型，允许你发送并接收以一些不同形式的数据，提供现有消息格式的一些级别的兼容性。我们用的最多的也就是TextMessage而已。
　　· StreamMessage -- Java原始值的数据流
　　· MapMessage--一套名称-值对
　　· TextMessage--一个字符串对象
　　· ObjectMessage--一个序列化的 Java对象
　　· BytesMessage--一个字节的数据流

        我们可以通过下面一张图来加深理解，图上半部分是"发布/订阅者"模式，两个发布者各自发布了一条消息，每条消息都可以被多个Consumer接收到。图下半部分是"面对面"模式，两个发布者各自发布了一条消息，压入队列当中，队列的特点是先进先出，一旦有某个消费者拿走了一条消息，队列中就少了一条消息，剩下的消费者就不可能再消费那条消息了，因此也就做到了一对一。