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.商品系统以订阅的⽅式获取消息中⼼的消息，最终修改数据库
session如何设置和读取使⽤消息中⼼的⼤致思路已经明⽩了，那么我们接下就来看看具体消息中⼼指的是什么？
什么是消息中⼼？
消息中⼼
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.⽣产者和消费者之间有时间上的相关性，订阅⼀个主体的消费者只能消费⾃它订阅之后的消息

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。