前言

消息中间件 MQ消息处理是一种先进先出的数据结构生产者---->消息---->消息队列---->消息---->消费者

MQ定义

来源

Message Queue 的需求由来已久，在 19 世纪 80 年代金融交易中，美国高盛等公司采用 Teknekron 公司的产品，当时的 Message queuing 软件叫做(the informationbus（TIB）,后来 TIB 被电信和通讯等公司采用，然后路透社收购了 Teknekron 公司，再然后 IBM 公司开发了 MQSeries，并且微软也开发了 Microsoft Message Queue（MSMQ），但是这些商业 MQ 供应商的问题是厂商锁定及使用价格高昂，于是 2001 年，Java Message queuing 试图解决锁定和交互性的问题，但对应用来说反而更加麻烦了，于是 2004 年，摩根大通和 iMatrix 开始着手 Advanced Message Queuing Protocol （AMQP）开放标准的开发，2006 年，AMQP 规范发布，2007年，Rabbit 技术公司基于 AMQP 标准开发的 RabbitMQ 1.0 发布。

定义

消息队列的目的是为了实现各个 APP 之间的通讯，APP 基于 MQ 实现消息的发送和接收实现应用程序之间的通讯，这样多个应用程序可以运行在不同的主机上，通过 MQ 就可以实现夸网络通信，因此 MQ 实现了业务的解耦和异步机制。

分类

Kafka 是一个高性能、可扩展的[分布式消息队列])系统，被设计用于处理大规模的数据流和实时数据传输。它以其出色的吞吐量、持久性和可靠性而闻名，广泛应用于各种数据处理和事件驱动的架构中。Kafka 的设计思想注重于可扩展性和高性能，使其成为大规模数据处理和实时数据流的首选。

ZeroMQ 是一个高性能的消息传递库，旨在提供低延迟和轻量级的消息通信。ZeroMQ 的设计目标是简化并发编程和分布式系统的开发，通过提供灵活的消息传递模式和异步通信机制，使开发人员能够轻松构建高效的通信系统。它的特点包括高性能、低延迟和可靠性，适用于需要高并发和低延迟通信的场景。

RabbitMQ 是一个灵活的消息中间件，提供了丰富的消息路由和队列模式，以及多种协议的支持。它的设计目标是提供可靠性、灵活性和高度可定制化的消息传递解决方案。RabbitMQ 提供了多种消息传递模式，包括发布-订阅模式、消息队列模式和广播模式，可以根据需求选择适当的模式。它支持多种协议，如 AMQP、STOMP 和 MQTT，使其能够与不同的应用程序和系统进行集成。

同步处理

用户将请求发给系统A，系统A受到请求调用B系统，系统B返回结果到系统A，系统A才能返回给用户，这就是同步调用。
同步调用就是各个系统之间相互依赖，一个系统发出请求，其它系统会跟着一次执行，只有所有系统处理完后对用户来说才算是完成了一次请求，只有任何一个系统出现故障，就会报错给用户

异步处理用户发送请求给系统A，系统A将发送消息到MQ，然后就返回结果给用户，不会去管系统B是否处理。系统B再根据知己的能力去MQ中获取消息，执行自己的操作也不会去告诉系统*A，所以整个过程的通信时异步调用

消息中间件优点

应用解耦

应用解耦就是让两个系统之间隔断运行。
平常没有消息中间件时，客户端系统和后台处理系统时耦合在一起的，如果后台系统宕机，那么就可能导致客户端系统请求出现无法处理的情况。只有等待后台系统处理完，才可正常使用。
加上消息中间件，这样就会进行解耦，当客户端的消息发送给后台时，不会直接发送到后台，而是发送到消息中间件上面，消息中间件再按照后台服务器情况进行分配处理。这样即使后台服务器宕机，消息中间件还是可以正常接收客户端的请求。

通俗理解：当系统A中在订单创建后，需要通知B系统和C系统，然后B系统和C系统再做出相应的处理，此时A系统是强依赖B系统和C系统，当B系统需要下线，或者需要重新加入D系统，则需要修改代码如此这样反复的添加和删除依赖的系统，使得系统难以维护，此时可以通过MQ来进行解耦这个时候A系统就与需要关心订单创建事件的系统解耦开，不再关心下游有哪些系统，也不用受下游系统可用性的影响。

注：耦合性（Coupling）是指不同部分或模块之间的相互连接或交互程度。在软件设计中，耦合性是指两个或多个软件模块间相互依赖的程度，即软件模块间联系的紧密程度

流量削峰

流量削峰就是用来处理在高并发的时候，不影响客户端的正常使用
当客户端处于高并发状态时，这些消息并不会直接发给后台数据库等，而是在消息中间件上进行排队等待
这样不仅可以客户端正常使用，还可以缓解后台的并发压力

比如：活动页面，平时大概就50qps，但每天有一个时刻访问的人比较多，达到了10000qps，但是当前系统的处理能力为1000qps。整个活动大部分时间流量都不太高，扩充太多的机器利用率太低，这个时候可以通过mq来进行削峰.

蓄流压测

线上有些链路不好压测，可以通过堆积一定量消息再放开来压测

消息中间件的模式

常用的Kafka，pulsar等消息中间件都在原有的消息模型上做了扩展，同时提出了一些新名词，比如：主题（topic）、分区（partition）、队列（queue）等等。

原始模型(ptp）点对点模式

它是一个严格意义上的队列（Queue）。消息按照什么顺序写进去，就按照什么顺序读出来。不过，队列没有 “读” 这个操作，读就是出队，从队头中 “删除” 这个消息。

发布/订阅模式（Pub/Sub）

如果需要将一份消息数据分发给多个消费者，并且每个消费者都要求收到全量的消息。很显然，队列模型无法满足这个需求。一个可行的方案是：为每个消费者创建一个单独的队列，让生产者发送多份。这种做法比较笨，而且同一份数据会被复制多份，也很浪费空间。为了解决这个问题，就演化出了另外一种消息模型：发布-订阅模型。

发布和订阅是一对多的关系。**

前台系统连接到消息队列
后台系统连接到消息队列，并订阅主机Topic1。
当前台系统发送到消息给到消息队列中，主题为Topic1。
消息队列收到了前台系统发来的消息，发现后台系统订阅了该主题，然后便将消转到后台系统。
后台系统从消息队列中接收到该消息

ZooKeeper

ZooKeeper 最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题，所以，雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上

应用场景

ZooKeeper 是一个分布式服务框架，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：命名服务、状态同步、配置中心、集群管理等。

命名服务

在分布式环境下，经常需要对应用/服务进行统一命名，便于识别

命名服务是分布式系统中比较常见的一类场景。命名服务是分布式系统最基本的公共服务之一。在分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等——这些我们都可以统称它们为名字（Name），其中较为常见的就是一些分布式服务框架（如 RPC、RMI）中的服务地址列表，通过使用命名服务，客户端应用能够根据指定名字来获取资源的实体、服务地址和提供者的信息等

状态同步

每个节点除了存储数据内容和 node 节点状态信息之外，还存储了已经注册的APP 的状态信息，当有些节点或 APP 不可用，就将当前状态同步给其他服务。

配置中心

分布式环境下，配置文件同步非常常见。一般要求一个集群中，所有节点的配置信息是一致的，比如Kafka集群。对配置文件修改后，希望能够快速同步到各个节点上配置管理可交由ZooKeeper实现。可将配置信息写入ZooKeeper上的一个Znode。各个客户端服务器监听这个Znode。一旦 Znode中的数据被修改，ZooKeeper将通知各个客户端服务器。现在我们大多数应用都是采用的是分布式开发的应用，搭建到不同的服务器上，我们的配置文件，同一个应用程序的配置文件一样，还有就是多个程序存在相同的配置，当我们配置文件中有个配置属性需要改变，我们需要改变每个程序的配置属性，这样会很麻烦的去修改配置，那么可用使用 ZooKeeper 来实现配置中心，ZooKeeper 采用的是推拉相结合的方式：客户端向服务端注册自己需要关注的节点，一旦该节点的数据发生变更，那么服务端就会向相应的客户端发送Watcher 事件通知，客户端接收到这个消息通知后，需要主动到服务端获取最新的数据。

集群管理

所谓集群管理，包括集群监控与集群控制两大块，前者侧重对集群运行时状态的收集，后者则是对集群进行操作与控制，在日常开发和运维过程中，我们经常会有类似于如下的需求：

希望知道当前集群中究竟有多少机器在工作。
对集群中每台机器的运行时状态进行数据收集。
对集群中机器进行上下线操作。

分布式环境中，实时掌握每个节点的状态是必要的。可根据节点实时状态做出一些调整。 ZooKeeper可以实现实时监控节点状态变化。可将节点信息写入ZooKeeper上的一个ZNode。监听这个ZNode可获取它的实时状态变化。

Zookeeper = 文件系统 + 通知机制。

前言