ActiveMQ:消息中心基本介绍

Redis其实也可以做消息队列，但是更多的企业选择了ActiveMQ，为什么，因为Redis的消息队列比较简单，无法做到像ActiveMQ，那样做做到点对点的消息订阅与发送

首先是哪些情况需要用到消息中心？

1.需要解耦出来的业务

比如淘宝中业务的处理就是使用发布/监听的方式，此处不展开，后面会有详细说明

2.耗时比较久的业务：MQ

比如订单服务，整套订单流水很长，而RPC调用（比如Dubbo）是同步请求的，在发出请求的时候，客户端就要TM一直等订单系统回应结果！

在这个过程中，在等的过程中就要占用服务器的CPU和内存资源，这还不算最糟糕的情况，如果遇到高并发的情况下，有些订单延迟过高，用户会以为出问题了，会反复提交订单，造成状况进一步恶化，和资源的进一步被占用

此时如果采用消息中心进行通讯，那么客户端可以不用去管后台的情况，直接通过消息中心返回的消息，用户拿到消息后，认为OK，但是实际上请求仍然在后台排队等待处理

优点：消息中心避免了同步请求带来的问题，既前台应用根本不用等到后台Service非要将业务处理完毕才返回请求，也同时解决了高并发产生的问题；

PS：但是如果订单建立失败，则会涉及到分布式事务，这个后面解释

简单总结：

对于链条比较长且还是高并发的事务可以采用消息中心来处理，这样比RPC同步调用效率会高出不少

3.存在高并发的业务：MQ + Redis

比如常见的秒杀抢购

假如没有消息中心，采用RPC进行通讯，那么常规的方法可以加乐观锁解决高并发 + 万能的验证码削个峰；

另一种方案就是用队列，就是将所有的请求全部放在队列中，这样就可以不用处理高并发产生的问题

但是这样做，虽然解决了高并发的问题，仍然有其他的问题，问题就是在于客户太多，请求会很多，比如10W个请求，如果商品有有限（比如1），如何解决超卖的问题？

如果要解决超卖的问题，那么我这边的客户端就一定要读取到商品的总数量

这里会出现的问题就是，A客户端从数据库读取到数据怎么能保证不是脏数据？

要做秒杀系统的另一个关键就是：读操作必须是原子性的，不然没有办法解决超卖的问题！

解决的思路就是利用Redis的读写操作原子性的特点来进行改造

具体步骤是：

1.到达了商品抢购的时间，把抢购的商品的数量通过数据库读取到Redis中

2.用户点击商品抢购的按钮，在controller中，使用Redis的decr，让商品的库存数做减法操作，并且接收到减减之后的结果，判断该结果是否大于等于0 （0~99，合计100）

3.如果不是大于等于0，提示用户，商品抢购完毕，并且让抢购的活动结束

4.如果是大于等于0，说明该商品还有库存可以抢，发送关于商品抢购的消息到消息中心

5.商品系统以订阅的方式获取消息中心的消息，最终修改数据库

使用消息中心的大致思路已经明白了，那么我们接下就来看看具体消息中心指的是什么？

什么是消息中心？

消息中心

1.消息异步接收:消息发送者不需要等待接受者的响应，提高整个应用的效率

2.消息可靠接收:消息发送出去以后保存在一个中间容器中，只有消息的接受者收到消息后才能删除消息

3.消息队列接收:消息以队列的形式接收，一个一个排队处理

比较流行的消息中心：

收费：IBM MQService,BEA WebLogic,Oracle MQ

开源：
ActiveMQ(老牌),
RabbitMQ(老牌，Apeach出品),
Kafka(性能很高，单台就能够处理百万级别的并发，一般用在大数据日志的收集),
RocketMQ（阿里开源中间件）

收费：阿里云GTS分布式事务

Kafka例外，并没有实现JMS，原因它并不是Java语言开发的

JMS

JMS就是Java消息服务(Java Message Servcie)应用程序接口，是JavaEE平台关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送信息，进行异步他通信，可以类比为JDBC

JMS规范

JMS定义了Java中间件中访问消息中心的接口，并没有给予实现，实现JMS接口的消息中心成为JMS Provider，例如ActiveMQ

假如想更换消息中心，只需要更换底层的JAR包即可，无需修改代码

关于JMS的几个概念

JMS Provider:实现了JMS接口和规范的消息中心，比如ActiveMQ

JSM Producer: 消息生产者，创建和发送JMS消息的客户端应用

JMS Consumer:消息消费者，接收和处理JSM消息的客户端应用

JMS Message :JMS 消息，分3个部分

1）消息头：每个消息头字段都有相应的getter和setter方法
2）消息属性：如果需要消除消息字段以外的值，那么可以使用消息属性
3）消息体：封装具体的消息数据

5.JMS Destination:消息的目的地，包含queue和topic

目的地通常是一串字符串，比如XX要去北京，XX的目的地就是“beijing”,在消息中心就是"message-order"等形式表型

6.JMS Domain ：消息传递域，JMS规范定义了两种消息传递域，分别是点对点和发布/订阅传递域

p2p与queue

1）点对点：point to point 简称ptp 或者 p2p 消息传递域，该消息传递域发送的消息地称之为队列(queue)

队列queue特点：

A.每个消息只能有一个消费者或者只能有一种消费者

（为什么称之为一种，后面会有解释）

B.消息的生产者和消费者没有时间上的相关性，消费者在提取消息的时候，消息的生产者是否处于运行状态，消费者还是可以去提取消息

或者说消费者所在服务器挂了，但重启后消费者仍然能获取到消息

这个就是queue下生产者和消费者没有时间上的相关性的含义

pub/sub与Topic

publish/subscribe 消息传递域，该消息传递域发送的目的地成为主题(topic)

A.每个消息可以有多个消费者

B.生产者和消费者之间有时间上的相关性，订阅一个主体的消费者只能消费自它订阅之后的消息

简单总结：
简单的来说，
pub/sub可以有N多个消费者，pub/sub发布消息相当于广播，有N个就发送N条消息，

不像p2p只能针对一个或者一种消费者一次性只能发一条消息

pub/sub的消费者和订阅者有时间上的相关性，即消费者挂了，生产者在消费者重启的时候发的消息消费者就拿不到了

而p2p在生产者或者消费者挂了后重启，消费者仍然能拿到消息

JMS Session

与JMS Provider 所建立的会话，可设置事务，消息消费签收方式

这个签名方式就是：

设置事务签名：消费者去拿消息，除非等到该消息被提交之后，消息中心才会删除消息

自定义手动签名：可以设置手动签收，手动签收后才消息中心才会删除消息

ActiveMQ

是Apache推出的，一款开源的，完全支持JMS1.1和JavaEE1.4规范的JMS Provider实现的消息中心(MOM)

ActiveMQ能干什么： 最主要的是用来帮助实现高可用，高性能，可伸缩，易用和安全的消息服务系统

Active MQ 特点：

1.完全支持JMS1.1和JavaEE1.4规范(持久化)

2.支持多种传送协议：TCP，UDP，SSL，NIO