#消息队列#

简单理解：将需要传输的数据存放在队列中（用于存放消息的组件）
很多时候消息队列不是一个永久性的存储，是作为一个临时存储存在的（设定一个期限：设置消息在MQ中存储的时间）

消息队列中间件

消息队列中间件就是用来存储消息的（软件）组件
例：为了分析网站的用户行为，我们需要记录用户的访问日志，这些一条条的日志可以看成是一条条的消息，我们可以将它保存在消息队列中。将来有一些应用程序要处理这些日志，就可以随时将这些消息取出来处理。
市面上的消息队列有很多：Kafka、RabbitMQ、ActiveMQ、RocketMQ、ZeroMQ等

消息队列应用场景

系统解耦

流量削峰
因为消息队列是低延迟、高可靠、高吞吐、故可以应对大量并发
例：当大量并发是

日志处理
可以使用消息队列作为临时存储或者一种通信管道
例：大型电商网站、App等需要分析用户的行为，要根据用户的访问行为来发现用户的喜好、活跃度等情况，需要在页面上收集大量的用户信息（当用户发起请求到服务器，服务器会将数据采集存储在消息队列，然后通过实时处理系统从消息队列里面取数据分析用户的PV、UV得到结果存储在redis，然后我们可以通过可视化将数据展示出来）

异步处理

应用场景：用户注册后，需要发送注册邮件和发送注册信息，传统的做法有两种：串行方式、并行方式
串行：将注册信息写入数据库成功后，发送注册邮件，然后发送注册短信，而所有任务执行完成后，返回信息给客户端
并行：将注册信息写入数据库成功后，同时进行发送注册邮件和发送注册短信的操作。而所有任务执行完成后，返回信息给客户端。同串行方式相比，并行方式可以提高执行效率，减少执行时间。
假设：串行方式需要550ms，而并行方式需要350ms。CPU每1秒吞吐量是100次，则串行方式1秒内可执行的请求量为1000/550，不到2次；并行方式1秒内可执行的请求量为1000/350，接近3次。由上可以看出，传统串行和并行的方式会受到系统性能的局限
为此我们引入消息队列，将不是必须的业务逻辑，异步进行处理。
根据上述的流程，用户的响应时间基本相当于将用户数据写入数据库的时间，发送注册邮件、发送注册短信的消息在写入消息队列后，即可返回执行结果，写入消息队列的时间很快，几乎可以忽略，比串行方式提升近9.2倍，比并行方式提升近6倍。

生产者、消费者模型

• 生产者负责将消息生产到MQ中
• 消费者负责从MQ中获取消息
• 生产者和消费者是解耦的，生产者一个程序、消费者一个程序

消息队列的模型

• 点对点：一个消费者消费一个消息，不可重复消费
  消息生产者生产消息发送到消息队列中，然后消息消费者从消息队列中取出并且消费消息。消息被消费以后，队列中不再有存储，所以消费者不可能消费到已经被消费的消息。消息队列支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
  

• 发布订阅：多个消费者可以消费一个消息，Topic，可以重复消费
  消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。
  如果需要将一份消息数据分发给多个消费者，并且每个消费者都要求收到全量的消息。很显然，队列模型无法满足这个需求。
  一个可行的方案是：为每个消费者创建一个单独的队列，让生产者发送多份。这种做法比较笨，而且同一份数据会被复制多份，也很浪费空间。
  为了解决这个问题，就演化出了另外一种消息模型：发布-订阅模型。
  在发布-订阅模型中，存放消息的容器变成了 “主题”，订阅者在接收消息之前需要先 “订阅主题”。最终，每个订阅者都可以收到同一个主题的全量消息。仔细对比下它和 “队列模式” 的异同：生产者就是发布者，队列就是主题，消费者就是订阅者，无本质区别。唯一的不同点在于：一份消息数据是否可以被多次消费。
  
  区别
  1、 点对点模式：
  生产者发送一条消息到queue，一个queue可以有很多消费者，但是一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有 一个可用的消费者，所以Queue实现了一个可靠的负载均衡。
  2、 发布订阅模式：
  发布者发送到topic的消息，只有订阅了topic的订阅者才会收到消息。topic实现了发布和订阅，当你发布一个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到这个消息的拷贝。