朝着先能干活的方向努力。。。奥利给！！！05

搞完了example项目的测试环境部署，接下来我们来学习学习给它加上一些公司的中间件吧。

其实，坦白地讲之前在做node的时候，所有的中间件的服务都不是我集成到代码中的。。。。。

好吧，承认之前的我很菜。但是现在近了新的小组，我们每个人都是平等的，每个人都以技术说话，因此自然这些东西我也必须去学习使用。这对我来讲，无疑是好事！

搞吧。。。。。。

首先我要学习一下mq。其实在之前做node的时候也接触过mq。但是一直不太会用，项目集成mq也不是我弄得。。。。。

但是在java中，mq就是一个特别常用的中间件。他就像mysql、redis一样常用。搞起来吧

准先学习一下基础的mq知识，在学习一下公司封装的mq。

中间件MQ

什么是中间件

中间件是一种独立的系统软件服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。从这个意义上可以用一个等式来表示中间件：中间件=平台+通信

回忆一下之前学的中间件，mysql、redis、nginx。就像编程语言写出的应用程序一样，中间件不过也只是在应用程序之下，操作系统之上的一个中间服务。这种中间件的服务其实就是提供服务以及通讯。这样就能保证应用程序通过中间件和操作系统进行通讯了。

中间件的分类

• 分布式消息中间件：各种mq（kafka、rocket......）
• 负载均衡中间件: nginx(lvs、cdn)
• 缓存中间件：redis 、memocache
• 数据库中间件：mysql

这些中间件说实在的，之前或多或少都有接触过。mysql、redis、nginx、mq。。。。。。但是不太会用mq。。

系统架构

单体架构

分布式架构：就是一个请求由服务器端的多个服务协同处理完成

单体架构下一个请求发起走一个jvm调度线程，而分布式架构一个请求发起同时走多个jvm调度线程。

消息中间件

• 消息中间件就是利用可靠的消息传递机制进行系统和系统直接的通讯
• 通过提供消息传递和消息的排队机制，他可以在分布式系统环境下扩展进程间的通讯

消息中间件的应用场景

• 系统和系统之间需要进行数据传递的场景（这个是我接触的第一个mq的使用场景，将app端采集的数据生产在mq中，让其他需要app端数据的系统去消费）
• 高并发下的流量削峰（这个是我接触的第二个mq的使用场景，由于订单系统高并发压力大，因此让把订单系统发来的消息先生产到mq，使用另外一个线程去消费）

消息中间件的本质

消息中间件的本质就是一种接受数据、存储数据、发送数据等功能的技术服务。

我相信理解了中间件的本质：中间件就是提供服务的，自然也就理解了mysql、redis的本质。mq的本质其实也不难理解。

mq的本质实际就是一个服务，一个提供消息接收、消息存储、消息分发的服务。。。。。

消息队列，又叫做消息中间件。是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信（维基百科）。

基于以上的描述（MQ 是用来解决通信的问题），我们知道，MQ 的几个主要特点：

1、是一个独立运行的服务。生产者发送消息，消费者接收消费，需要先跟服务器建立连接。

2、采用队列作为数据结构，有先进先出的特点。

3、具有发布订阅的模型，消费者可以获取自己需要的消息。

我们可以把RabbitMQ 类比成邮局和邮差，它是用来帮我们存储和转发消息的。问题：如果仅仅是解决消息消费的问题，Java 里面有这么多的队列的实现，为什么不用他们呢？这个问题的答案，就跟有了HashMap 之后，为什么还要Redis 做缓存是一样的。 

Queue 不能跨进程，不能在分布式系统中使用，并且没有持久化机制等等。

消息中间件的核心组成部分

• 消息的协议
• 消息的持久化机制
• 消息的分发策略
• 消息的高可用、高可靠
• 消息的容错机制

消息中间件采用的协议

为什么消息中间件不采用http协议呢？

因为http协议的数据格式中包含了太多无用的数据，消息中间件接收数据、传递数据根本就不需要这么多多余的数据。另外http协议使用的是短链接，短链接不适合消息中间件的业务场景。

常用的消息中间件协议：AMQP 、MQTT、Kafka

消息中间件那么多，我们怎么选择呢？这种就上升到架构层面了，对技术要求挺高的，这个必须得建立在对各个中间件的使用场景优缺点有足够了解，并且根据业务场景才能做出决策。

消息的持久化

持久化：其实就是数据存入磁盘，而不是存在内存中。防止因服务器重启导致数据丢失。对于中间件来讲，一旦服务宕掉，向redis或者mq这里面会有很多更重的数据，一旦中间件坏掉或者服务器重启数据丢失，就会产生问题。因此中间件的一个重中之重就是数据的持久化。

消息的分发策略

消息的分发策略：要么主动推，要么被动拉。在消息中间件中消息的分发策略为主动推。主动推的策略有几种：

• 发布订阅
• 轮训分发（70 70 70）
• 公平分发（会造成数据的倾斜 100 80 30）
• 重发（保证消息的可靠性）
• 消息拉取（被动拉取机制）

消息队列的高可用和高可靠

高可用：

消息中间件的高可用一般都是通过集群来保证的。就是指当业务量增加时，请求也过大的时候，一台消息中间件服务器可能会达到该台服务器的cpu、内存或者磁盘的极限。这个时候一台消息服务器已经无法满足业务的需求，所以消息中间件必须支持集群部署，从而达到高可用的目的。

反观，任何中间件其实都得满足高可用。仔细想想，mysql/redis鸭是不都有集群。这种集群，其实就是为了满足高可用。目前我们的业务中，mysql是master-slave的集群模式，redis采用的也是集群。

一般在公司办公，公司都会封装自己的redis、mysql、mq中间件。而且这些中间件被封装成集群后一般都能保证高可用。

高可靠：

消息中间件的高可靠一般都是通过协议保证数据传输的高可靠，通过数据的持久化来保证高可靠。。。。。

回到公司的消息中间件

我们公司也是自己对mq作出了自己的封装。