简介

新闻中间件也可以称为消息队列，是指与平台无关的数据通信和基于数据通信的分布式系统的集成。在分布式环境传输和信息队列模型，可以在分布式环境中扩展通信过程。目前主流新闻中间件有RabbitMQ、Kafka、ActiveMQ、RocketMQ等。它可以在不同的平台之间进行通信，通常用于屏蔽各种平台协议之间的特征，实现应用程序之间的协调。其优点是可以在客户端和服务器之间同步和异步连接，消息可以随时传输和转发。主要用于解决应用耦合、异步通信、流量削峰等问题

新闻中间件的作用

新闻中间件的主要功能如下：

• 解耦
  降低工程之间的强依赖性，适应异构系统。在项目启动之初，极难预测项目未来会遇到什么需求。通过在处理过程中间插入一个基于数据的隐含接口层，在处理过程中实现两侧的处理过程。当应用程序发生变化时，只要它们遵守相同的接口约束，就可以独立扩展或修改两侧的处理过程。
• 冗余(存储)
  在某些情况下，处理数据的过程会失败。除非数据持久，否则会丢失。消息队列将数据持久化，直到它们完全处理，以避免数据丢失的风险。在插入-获取-删除范式中，在从队列中删除消息之前，您的处理系统需要明确指出消息已经处理好，以确保您的数据安全保存，直到您使用。
• 扩展性
  因为消息队列解耦了你的处理过程，只要增加处理过程，就很容易增加消息进入和处理的频率。无需更改代码或调整参数。便于分布式扩展。
• 削峰
  当访问量急剧增加时，应用程序仍然需要继续发挥作用，但这种紧急流量无法提前预测；投资资源随时待命无疑是一种巨大的浪费，以应对此类瞬时峰值访问。使用信息队列可以使关键组件承受紧急访问压力，而不会因紧急超载要求而完全崩溃。
• 可恢复性
  当系统的部分组件失效时，不会影响整个系统。消息队列减少了过程之间的耦合，因此即使处理消息的过程被挂断，系统恢复后仍然可以处理添加到队列中的消息。
• 顺序保证
  在大多数使用场景中，数据处理的顺序非常重要。大多数新闻队列最初是排序的，并且可以确保数据按特定的顺序处理。
• 缓冲
  在任何重要的系统中，都会有需要不同处理时间的元素。缓冲有助于控制和优化数据流通过系统的速度，通过缓冲层帮助任务最高效地执行。调整系统响应时间。
• 异步通信
  有些企业不想也不需要立即处理这些信息。消息队列提供了一种异步处理机制，允许用户将消息放入队列，但不会立即处理。把你想把的信息放在队列中，然后在必要时处理它们。

消息中间件的两种模式

PTP模式 （点对点）使用Queue作为通信载体

P2P模式包括三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留消息，直到他们被消费或加班。

P2P的特点:

• 每个消息只有一个消费者（Consumer）(即一旦消费，消息将不再在消息队列中)
• 发送者和接收者之间没有时间依赖，也就是说，当发送者发送消息时，无论接收者是否运行，都不会影响消息被发送到队列
• 收件人成功收到消息后，需要成功回应队列
• 如果希望发送的每个消息都会被成功处理的话，那么需要P2P模式

Pub/Sub模式 (发布/订阅 广播）使用Topic作为通信载体

消息制作人(发布)将消息发布topic同时，消费者(订阅)也有多个消息消费这个消息。不同于点对点，发布到topic所有订阅者都会消费消息。
queue实现了负载均衡，将producer生产的消息发送到消息队列，由多个消费者消费。但是一个消息只能被一个消费者接受。当没有消费者可用时，消息将被保存到有可用消费者。
topic当你发布消息时，所有的订阅都实现了发布和订阅topic所有的服务都可以得到这个消息，所以1到N个订阅者都可以得到一个消息的副本

Pub/Sub的特点

• 每个消息可以有多少消费者？
• 出版商和订阅者之间有时间依赖。针对某个主题（Topic）在消费发布者的消息之前，订阅者必须创建一个订阅者。
• 订阅者必须保持运行状态才能消费新闻。
• 如果你想发送的信息不能被处理，或者只能被一个消息人处理，或者可以被多个消费者处理，那么可以使用Pub/Sub模型。

消息中间件解决的问题

异步通信

场景描述:注册后，用户需要发送注册邮件和注册短信。传统做法有两种:1。 2.并行
1.串行方式:将注册信息写入数据库后，发送注册邮件，然后发送注册短信。上述三项任务完成后，返回客户端。 问题之一是邮件和短信不是必须的。这只是一个通知，这使得客户端无需等待.
2.并行方式:将注册信息写入数据库后,发送邮件的同时,发送短信,以上三个任务完成后,返回给客户端,并行的方式能提高处理的时间。
假设三个业务节点分别使用50个ms,串行使用时间1500ms,并行使用时间100ms。虽然并行性的处理时间有所提高，但正如我前面所说，电子邮件和短信对我正常使用的网站没有影响。客户端不需要等到发送完成才能显示注册成功。它应该在写入数据库后返回.

3.消息队列
引入消息队列后，发送电子邮件和短信不必要

由此可见，引入消息队列后，用户的响应时间等于写入数据库的时间 写入消息队列的时间(可以忽略不计)，引入消息队列后，响应时间是串行的3倍，是并行的2倍。

应用解耦

这是高耦合系统的例子

首先，有人要求他向新系统发送数据H，系统A的同学要修改代码然后在那个代码里加入调用新系统H的流程。

过了一会儿，系统B是一个旧系统，即将离线。告诉系统A的学生：不要给我发数据，然后系统A再次修改代码，不再给系统B。

那么下游系统突然停机呢？

系统A的调用代码会抛出异常吗？系统A的学生会收到报警说异常，但他不得不去。care哪个系统在下游停机。

因此，在实际的系统架构设计中，如果采用这种系统耦合的方式，在某些情况下绝对不合适，系统耦合程度太严重。

相互耦合不是核心链接的呼叫，而是一些非核心场景（如上述数据消费）导致系统耦合，严重影响上下游系统的开发和维护效率。

因此，可以在上述系统架构中使用MQ实现系统解耦的中间件。

系统A将其核心数据发送到MQ下游哪个系统对自己消费感兴趣，不需要就取消数据消费，如下图所示:

流量削峰

• 场景1
  假设你有一个系统，通常正常时间每秒可能有数百个请求，每秒数百个请求可以很容易地抵抗，但偶尔在高峰时间每秒数千个请求，流量高峰，为了抵抗高峰，可以选择扩展机器，增加到10，但高峰后，每秒数百个请求，这不是浪费机器资源吗？但如果你部署了一台机器，它会导致你的系统在瞬间高峰时突然被压垮，因为你永远无法抗拒每秒数千个请求高峰。我们可以在这个时候使用它MQ流量削峰的中间件。在所有机器前部署一层MQ，平时每秒几百个请求大家都可以轻松收到消息。一旦达到瞬时高峰，每秒涌入数千个请求，就可以积压MQ里面，然后机器慢慢处理和消耗。高峰期过后，再花一段时间，MQ积压的数据消耗完毕。这是一个典型的例子MQ如果业务场景允许异步削峰，则在高峰期积压一些要求MQ在里面，高峰期过后，如果后台系统在一定时间内消费后不再积压，则非常适合使用此技术方案。
• 场景2
  在第二次杀戮活动中，应用程序通常会因为流量过大而挂断。为了解决这个问题，通常会在应用程序的前端添加消息队列。功能：1。可以控制活动数量，直接丢弃超过一定阀值的订单。2.可以缓解短时间内高流量压垮应用程序（应用程序根据其最大处理能力获取订单）

待补充

常用的新闻中间件协议

• AMQP协议
  AMQP即Advanced Message Queuing Protocol,提供统一消息服务的应用层标准高级消息队列协议是为面向消息的中间件设计的应用层协议的开放标准。基于本协议的客户端和消息中间件可以传输消息，不受客户端/中间件不同产品和不同开发语言的限制。优点：可靠性和通用性
• MQTT协议
  MQTT（Message Queuing Telemetry Transport，消息队列遥测传输IBM实时通信协议的开发可能成为物联网的重要组成部分。该协议支持几乎所有与外部连接的平台，用作传感器和致动器(例如通过Twitter让房屋联网)通信协议。优点：格式简单，占用带宽小，移动通信，PUSH、嵌入式系统
• STOMP协议
  STOMP（Streaming Text Orientated Message Protocol）流文本定向消息协议是一种MOM(Message Oriented Middleware，简单的文本协议是为新闻中间件设计的。STOMP提供客户端和任何可互操作的连接格式STOMP消息代理（Broker）进行交互。优点:命令模式(非)topic\queue模式）
• XMPP协议
  XMPP(可场协议可扩展消息处理，Extensible Messaging and Presence Protocol）基于可扩展标记语言（XML）的议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大
• 其他基于TCP/IP自定义的协议
  有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范，而是基于TCP\IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ的功能。

常用中间件介绍

• RocketMQ
  阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，3.0版本名称改为RocketMQ，是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要多用于订单交易系统。具有以下特点：能够保证严格的消息顺序提供针对消息的过滤功能提供丰富的消息拉取模式高效的订阅者水平扩展能力实时的消息订阅机制亿级消息堆积能力官方提供了一些不同于kafka的对比差异：https://rocketmq.apache.org/docs/motivation/
• RabbitMQ
  使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了Broker架构，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。
• ActiveMQ
  Apache下的一个子项目。使用Java完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，少量代码就可以高效地实现高级应用场景。可插拔的传输协议支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。
• Redis
  使用C语言开发的一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
• Kafka
  Apache下的一个子项目，使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统，具有以下特性：快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下进行消息持久化；高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；高堆积：支持topic下消费者较长时间离线，消息堆积量大；完全的分布式系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现复杂均衡；支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。
• ZeroMQ
  号称最快的消息队列系统，专门为高吞吐量/低延迟的场景开发，在金融界的应用中经常使用，偏重于实时数据通信场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，开发成本高。因此ZeroMQ具有一个独特的非中间件的模式，更像一个socket library，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序本身就是使用ZeroMQ API完成逻辑服务的角色。但是ZeroMQ仅提供非持久性的队列，如果down机，数据将会丢失。如：Twitter的Storm中使用ZeroMQ作为数据流的传输。ZeroMQ套接字是与传输层无关的：ZeroMQ套接字对所有传输层协议定义了统一的API接口。默认支持 进程内(inproc) ，进程间(IPC) ，多播，TCP协议，在不同的协议之间切换只要简单的改变连接字符串的前缀。可以在任何时候以最小的代价从进程间的本地通信切换到分布式下的TCP通信。ZeroMQ在背后处理连接建立，断开和重连逻辑。特性：无锁的队列模型：对于跨线程间的交互（用户端和session）之间的数据交换通道pipe，采用无锁的队列算法CAS；在pipe的两端注册有异步事件，在读或者写消息到pipe的时，会自动触发读写事件。批量处理的算法：对于批量的消息，进行了适应性的优化，可以批量的接收和发送消息。多核下的线程绑定，无须CPU切换：区别于传统的多线程并发模式，信号量或者临界区，zeroMQ充分利用多核的优势，每个核绑定运行一个工作者线程，避免多线程之间的CPU切换开销。

主要消息中间件的比较

如果本文对你有帮助，别忘记给我个3连 ，点赞，转发，评论，

咱们下期见！学习更多JAVA知识与技巧，关注与私信博主（666）