MQ（Message Queue）知识Part01（场景，作用）

1、前言
 	1.1、在何种场景下使用了消息中间件
 	1.2、为什么要在系统里面引用
2、如何学，方法讨论
	2.1、MQ产品种类（天上飞的理念，必然有落地的实现
		Kafka（大数据专用[java/scala]）【多个产品——》分】
		RabbitMQ[erlang]
		RocketMQ[java]
		ActiveMQ（总——》技术维度）
			api发送和接收
			MQ的高可用性
			MQ的集群和容错配置
			MQ的持久化
				redis
			延时发送/定时投递
			签收机制
			Spring整合
			编程语言：java
		阿里内部自己研发Notify

	2.2、对着一个城墙口发起冲锋，总-分-总
3、从生活case到实际生产案例
	3.1、上述问题引出产生背景
		3.1.1、系统之间直接调用实际工程落地和存在的问题
			微服务架构后，链式调用是我们在写程序时候的一般流程，为了完成一个整体功能会将其拆分成多个函数（或子模块），比如模块A调用模块B，模块B调用模块C，等等。但在大型分布式应用中，系统的RPC交互繁杂，一个功能背后要调用上百个接口并非不可能，从单机架构过渡到分布式微服务架构的通例。这种架构会有哪些问题？
				系统之间接口耦合比较严重
					加入系统A要发送数据给系统B和C，发送给每个系统的数据可能有差异，因此系统A对要发送给每个系统的数据进行组装，然后逐一发送。
					当代码上线后又新增了一个需求：
					把数据也发送给D，新上了一个D系统用也要接受A系统的数据。此时就需要修改A系统，让他感知到D的存在，同时把数据处理好再A给D。在这个过程会发现每接入一个下游系统，都要对A系统进行代码改造，开发联调的效率很低。
				面对大流量并发时，容易被冲垮
					每个接口模块的吞吐能力是有限的，这个上限能力比作是堤坝，当大流量（洪水）来临时，容易被冲垮。
					例子秒杀业务：
						上游系统发起下单购买操作，我就是下单一个操作
						下游系统完成秒杀业务逻辑
							（读取订单，库存检查，库存冻结，余额检查，订单生成，余额扣减，库存扣减，生成流水，余额解冻，库存解冻
				等待同步存在性能问题
					RPC接口基本上是同步调用，整体的服务性能遵循“木桶理论”，即整体系统的耗时取决于链路中最慢的那个接口。比如A调用B/C/D都是50ms，但此时B又调用了B1,花费了2000ms，那么直接就拖累了整个服务性能（假设B/C/D之间并行）即最后需要2050ms
	3.2、需要有一种东西能够摆平上述情况
		3.2.1、设计系统可以明确的目标
			要做到系统解耦，当新的模块接进来时，可以做到代码改动最小：能够解耦
			设置流量缓冲池，可以让后端系统按照自身吞吐能力进行小费，不被冲垮：能够削峰
			强弱依赖梳理能将非关键调用链路的操作异步化并提升整体系统的吞吐能力：能够异步

4、是什么
	4.1、定义
		4.1.1、面向消息的中间件（message-oriented middleware）MOM能够很好的解决【解耦、削峰、异步】
			是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。
			通过提供消息传递和消息派对模型在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等功能。
		大致的过程是这样的：
			发送者把消息发送给消息服务器，消息服务器将消息存放在若干队列【发短信，先来后到】/主题【朋友圈发送，只有是你的好友才会有】中，在合适的时候，消息服务器会将消息转发给接受者。在这个过程中，【发送和接受是异步的】，也就是发送无需等待【想发就发】，而且发送者和接受者的生命周期也没有必然关系：尤其在发布pub/订阅sub模式下，也可以完成一对多的通信，即让一个消息有多个接受者。


	4.2、特点
		4.2.1、采用异步处理方式
			消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一条虚拟的通道（主题或队列）上：
				消息接受者则订阅或监听该通道，一条信息可能最终转发给一个或多个消息接收者，这些接收者都无需对消息发送者做出同步回应。整个过程都是异步的。
			案例：
				也就是说，一个系统和另外一个系统之间进行通信的时候，假如系统A希望发送一个消息给系统B，让他去处理。
				但是系统A不关注系统B到底怎么处理或者没有处理好，所以系统A把消息发送给MQ，然后就不管这条消息的“死活”了，接着系统B从MQ里消费出来处理即可。至于怎么处理，是否处理完毕，什么时候处理，都是系统B的事，与系统A无关.
			这样的一种通信方式，就是所谓的“异步”通信方式对于系统A来说，只要把消息发送给B，然后系统B就会异步的去进行处理了，系统A不需要“同步”等待系统B处理完，这样的好处是什么？解耦
		4.2.2、应用系统之间解耦合
			发送者和接受者不必了解对方，只需要确认信息
			发送者和接受者不必同时在线
		4.2.3、上游系统所做的事少，处理快，下游系统要处理东西多，处理慢。可以添加一个MQ作为缓冲。上游不再直接调用下游


5、能干嘛
	解耦
	削峰
	异步

6、ActiveMQ官网 
	http://activemq.apache.org/

7、怎么玩
	7.1、最主要的功能
		实现高可用、高性能、可伸缩、易用和安全的企业级面向消息服务的系统
	7.2、异步消息的消费和处理
	7.3、控制消息的消费顺序
	7.4、可以和spring/springboot整合简化编码
	7.5、配置集群容错的MQ集群
8、目的地Destination
	两大模式特性
		8.1、队列 点对点 谁给谁发短信 目的地被称为队列（queue
			8.1.1、每个消息只能有一个消费者，类似一对一的关系，好比个人快递自己领取自己的。
			8.1.2、消息的生产者和消费者之间没有时间上的相关性。无论消费者在生产者发送消息的时候是否处于运行状态，消费者都可以提取消息。好比我们的发送消息，发送者发送后不见得接受者会即收即看
			8.1.3、消息被消费后队列中不会再存储，所以消费者不会消费到已经被消费掉的消息
		8.2、主题 一对多 朋友圈发动态 通过sub
			发布订阅消息传递域的特点
			8.2.1、生产者将消息发布到topic中，每个消息可以有多个消费者，属于1：N的关系
			8.2.2、生产者和消费者之间有时间上的相关性。订阅某一个主题的消费者只能消费自它订阅之后发布的消息。
			8.2.3、生产者生产时，topic不保存消息它是无状态的不落地，假如无人订阅就去生产，那就是一条废消息，所以，一般先启动消费者再启动生产者。

	JMS规范允许客户创建持久订阅，这在一定程度上放松了时间上的相关性要求。持久订阅允许消费者消费它在未处于激活状态时发送的消息。就好比微信公众号的订阅。
9、消息控制台的说明
	Number of Pending Message 等待消费的数量
	这个是当前未出队列的数量。公式=总接受数-总出队列数
	Number of Consumers 消费者数量
	消费者端的消费者数量
	Messages Enqueued 进队消息数
	进入队列的总数量，包括出队列的。这个数量只增不减
	Messages Dequeued 进队消息数
	可以理解为是消费者消费掉的数量
总结
	当有一个消息进入队列时，等待消费的数量是1，进入队列的消息是1
	当消息消费后，等待消费的消息是0，进入队列的消息是1，出队列的消息是1.
	再来一条消息时，等待消费的消息是1，进入队列的消息是2 
10、JMS开发的基本步骤
	10.1、创建一个Connection Factory
	10.2、通过connection factory 来创建JMS connection
	10.3、启动 JMS connection
	10.4、通过connection创建JMS session
	10.5、创建JMS destination
	10.6、创建JMS producer或者创建JMS message 并设置destination
	10.7、创建JMS consumer或者是注册一个JMS message listener
	10.8、发送或者接受JMS message(s)
	10.9、关闭所有的JMS资源
	Connection、session、producer、consumer等
11、两种消费方式
	同步阻塞方式（receive（））
		订阅者或接受者调用MessageConsumer的receive()方法来接受信息，receive方法能够接收到消息之前（或超时之前）将一直阻塞
	异步非阻塞方式（监听器onMessage())
		订阅者或接受者通过MessageConsumer的setMessageListener(MessageListener listener)注册一个消息监听器
		当消息到达之后，系统自动调用监听器MessageListener的onMessage(Message message) 方法
12、JavaEE
	JavaEE是一套使用JAva进行企业级应用开发的大家一致遵循的13个核心规范工业标准。JavaEE平台提供了一个基于组件的方法来加快设计、开发、装配及部署企业应用程序
	12.1、JDBC（Java Database）数据库连接
	12.2、JNDI（Java Naming and Directory Interfaces）JAva的目录和目录接口
	12.3、EJB（ENterprise JavaBean)
	12.4、RMI（Remote Method Invoke）远程方法调用
	12.5、Java IDL（Interface Description Language）/CORBA(Common oBject Broker Architecture)接口定义语言/公用对象请求代理程序体系结构
	12.6、JSP（Java Server Pages)
	12.7、Servlet
	12.8、XML（Extensible Markup Language）可扩展白标记语言
	12.9、JMS（Java Message Service）Java 消息服务
	12.10、JTA（Java Transaction API) Java 事务API
	12.11、JTS（Java Transaction Service） Java事务服务
	12.12、JavaMail
	12.13、JAF（JavaBean Activation Framework） 
13、什么是Java消息服务
	Java消息服务指的是两个应用程序之间进行异步通信的API，它为标准消息协议和消息服务提供了一组通用接口，包括创建、发送、读取消息等，用于支持JAVA应用程序咖啡i啊。在JavaEE中，当两个应用程序使用JMS进行通信时，它们之间并不是直接相连的，而是通过一个共同的信息收发服务组件关联起来以达到解耦/异步削峰的效果