分类:MQ - 版本历史

Eijux：Eijux移动页面分类:消息中间件至分类:MQ，不留重定向

2021-05-15T15:10:57Z

←上一版本	2021年5月15日 (六) 23:10的版本
（没有差异）

Eijux：/* 关于 */

2021-05-15T11:24:43Z

关于

@@ 第12行： / 第12行： @@
 * 通俗点说，就是一个先进先出的数据结构。
-=== 为什么使用MQ？（使用场景）===
+=== 为什么使用MQ？（作用） ===
-消息队列常见的使用场景很多，但是比较核心的有 3 个：'''解耦'''、'''异步'''、'''削峰'''。
+消息队列的作用有很多，但是比较核心的有 3 个：
 === MQ有哪些缺点？ ===
 # 系统可用性降低：系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，人 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套系统崩溃的，你不就完了？
 # 系统复杂度提高：硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。
 # '''一致性问题'''：A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。
 == MQ 基础 ==

Eijux：/* 关于 */

2021-05-15T11:03:28Z

关于

←上一版本		2021年5月15日 (六) 19:03的版本
第6行：		第6行：

	=== 什么是MQ？ ===		=== 什么是MQ？ ===
	MQ（Message Queue）是一种'''~~跨进程的通信机制~~'''~~，用于传递消息。通俗点说，就是一个先进先出的数据结构。~~		<pre>
			消息队列（英语：Message queue）是一种进程间通信或同一进程的不同线程间的通信方式，软件的贮列用来处理一系列的输入，通常是来自用户。消息队列提供了异步的通信协议，每一个贮列中的纪录包含详细说明的数据，包含发生的时间，输入设备的种类，以及特定的输入参数，也就是说：消息的发送者和接收者不需要同时与消息队列互交。消息会保存在队列中，直到接收者取回它。 ——维基百科
			</pre>
			MQ（Message Queue）是一种'''异步的服务间通信方式'''，适用于无服务器和微服务架构。消息在被处理和删除之前一直存储在队列上。
			* 通俗点说，就是一个先进先出的数据结构。

	=== 为什么使用MQ？（使用场景）===		=== 为什么使用MQ？（使用场景）===

Eijux：/* 关于 */

2021-05-15T10:48:47Z

关于

←上一版本		2021年5月15日 (六) 18:48的版本
第9行：		第9行：

	=== 为什么使用MQ？（使用场景）===		=== 为什么使用MQ？（使用场景）===
	# 非实时性：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。主要解决了应用耦合、异步处理、流量削锋等问题。		消息队列常见的使用场景很多，但是比较核心的有 3 个：'''解耦'''、'''异步'''、'''削峰'''。



	~~解耦、异步、削峰~~



	~~消息队列常用的使用场景：~~		常用的使用场景：
			# 非实时性：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。主要解决了应用耦合、异步处理、流量削锋等问题。
	# 应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；（如：订单->库存）		# 应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；（如：订单->库存）
	# 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；(点对多场景，广播场景(注册发短信，发邮件)等等)		# 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；(点对多场景，广播场景(注册发短信，发邮件)等等)
第22行：		第24行：

	=== MQ有哪些缺点？===		=== MQ有哪些缺点？===
			# 系统可用性降低：系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，人 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套系统崩溃的，你不就完了？
			# 系统复杂度提高：硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。
			# '''一致性问题'''：A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。

	== MQ 基础 ==		== MQ 基础 ==

Eijux：/* MQ 基础 */

2021-05-15T10:42:10Z

MQ 基础

←上一版本		2021年5月15日 (六) 18:42的版本
第30行：		第30行：
	#: [[File:消息中间件模式分类：点对点.png\|400px]]		#: [[File:消息中间件模式分类：点对点.png\|400px]]
	#: 消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。		#: 消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。
	#* 消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。		#* 消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。【'''不存在重复消费'''】
	#* ~~Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。~~		#* Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。【一个消息对应'''一个消费者'''】
	# 发布/订阅（Pub/Sub）：使用 topic 作为通信载体		# 发布/订阅（Pub/Sub）：使用 '''topic''' 作为通信载体
	#: [[File:消息中间件模式分类：发布订阅.png\|400px]]		#: [[File:消息中间件模式分类：发布订阅.png\|400px]]
	#: ~~消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。~~		#: 消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。
			#* 和点对点方式不同，发布到topic的消息会被所有订阅者消费。【一个消息对应'''多个消费者'''】

			=== 消息推拉模式 ===
			# '''pull'''：（'''拉'''）主动权在于'''消费方'''，优点是'''按需消费'''（吃自助餐，能吃多少拿多少），而且服务端队列堆积的消息处理也相对简单。
			#* 缺点就是消息延迟（不知道啥时候去拉取更新）。
			# '''push'''：（'''推'''）主动权就在'''服务方'''了，优点是'''实时性高'''，服务端可以统一管理来进行负载，不过也容易导致慢消费。
			#* 缺点就是发送消息的状态是集中式管理。

	~~对比：~~
	* queue：实现了'''负载均衡'''，将 producer 生产的消息发送到消息队列中，由多个消费者消费。但'''一个消息只能被一个消费者接受'''，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者。		当然也可以根据实际情况，将二者结合使用来：1、提高消息的实时性；2、按需消费；
	* topic：实现了发布和订阅，当你发布一个消息，所有订阅这个 topic 的服务都能得到这个消息，所以'''从 1 到 N 个订阅者都能得到一个消息的拷贝'''。

	=== 消息中间件常用协议 ===		=== 消息中间件常用协议 ===

Eijux：/* 消息中间件模式分类 */

2021-05-15T10:31:27Z

消息中间件模式分类

←上一版本		2021年5月15日 (六) 18:31的版本
第23行：		第23行：
	=== MQ有哪些缺点？===		=== MQ有哪些缺点？===


			== MQ 基础 ==

	=== 消息中间件模式分类 ===		=== 消息中间件模式分类 ===

Eijux：/* 关于 */

2021-05-15T10:30:05Z

关于

←上一版本		2021年5月15日 (六) 18:30的版本
第6行：		第6行：

	=== 什么是MQ？ ===		=== 什么是MQ？ ===
			MQ（Message Queue）是一种'''跨进程的通信机制'''，用于传递消息。通俗点说，就是一个先进先出的数据结构。

			=== 为什么使用MQ？（使用场景）===
			# 非实时性：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。主要解决了应用耦合、异步处理、流量削锋等问题。

			解耦、异步、削峰



			消息队列常用的使用场景：
			# 应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；（如：订单->库存）
			# 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；(点对多场景，广播场景(注册发短信，发邮件)等等)
			# 限流削峰：应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；(根据服务承受度设置队列大小，超过了就返回活动结束了，咱们经常各大商城秒杀，心里还没有点B数吗)减少压力,避免服务挂掉。
			# 消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；(分工处理(各自对应相应的队列)，灵活应用(收到就处理/定时处理))

			=== MQ有哪些缺点？===


			=== 消息中间件模式分类 ===
			# 点对点（PTP）：使用 '''queue''' 作为通信载体。
			#: [[File:消息中间件模式分类：点对点.png\|400px]]
			#: 消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。
			#* 消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。
			#* Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
			# 发布/订阅（Pub/Sub）：使用 topic 作为通信载体
			#: [[File:消息中间件模式分类：发布订阅.png\|400px]]
			#: 消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。


			对比：
			* queue：实现了'''负载均衡'''，将 producer 生产的消息发送到消息队列中，由多个消费者消费。但'''一个消息只能被一个消费者接受'''，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者。
			* topic：实现了发布和订阅，当你发布一个消息，所有订阅这个 topic 的服务都能得到这个消息，所以'''从 1 到 N 个订阅者都能得到一个消息的拷贝'''。

			=== 消息中间件常用协议 ===
			# '''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的功能。

			== MQ需要考虑的问题 ==

			=== 怎么保证消息没有重复消费？ ===
			# 如果是拿这个消息做数据库 insert 操作（事实上 update 和 delete 重复也不影响）给这个消息做一个唯一主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
			# 当拿到这个消息做 redis 的 set 的操作，那就容易了，不用解决，因为你无论 set 几次结果都是一样的，set 操作本来就算幂等操作。
			# 如果上面两种情况还不行，准备一个第三方存储,来做消费记录。以 redis 为例，给消息分配一个全局 id，只要消费过该消息，将 <id,message> 以 K-V 形式写入 redis。那消费者开始消费前，先去 redis 中查询有没消费记录即可。

			=== 怎么处理消息丢失的情况？ ===

			=== 怎么保证消息传递的顺序性？ ===

			=== 怎么保证多系统消息一致性？ ===

	== 选型 ==		== 选型 ==

Eijux：/* 不同MQ的特点对比？ */

2021-05-14T20:06:20Z

不同MQ的特点对比？

←上一版本		2021年5月15日 (六) 04:06的版本
第29行：		第29行：
	=== 不同MQ的特点对比？ ===		=== 不同MQ的特点对比？ ===
	没有最好的消息中间件，只有最合适的消息中间件：		没有最好的消息中间件，只有最合适的消息中间件：
	: [[File:MQ对比1.png\|~~400px~~]]		: [[File:MQ对比1.png\|800px]]
	: [[File:MQ对比2.png\|~~400px~~]]		: [[File:MQ对比2.png\|800px]]

	* 性能小、量小，用什么都没有关系，性质是一样的，如果消息性能要求高用 RocketMQ 与 Kafka 可以更优，二者各有利弊，看业务需要。		* 性能小、量小，用什么都没有关系，性质是一样的，如果消息性能要求高用 RocketMQ 与 Kafka 可以更优，二者各有利弊，看业务需要。

2021年5月14日 (五) 20:06 Eijux

2021-05-14T20:06:03Z

显示更改

Eijux：建立内容为“
消息中间件
== 关于 ==”的新页面

2021-05-14T18:26:19Z

建立内容为“<div align="center"><span style="color:black; font-weight:bold; font-size:150%;">消息中间件</span></div> == 关于 ==”的新页面

新页面

<div align="center"><span style="color:black; font-weight:bold; font-size:150%;">消息中间件</span></div>

== 关于 ==

分类:MQ - 版本历史

Eijux：​Eijux移动页面分类:消息中间件至分类:MQ，不留重定向

Eijux：​/* 关于 */

Eijux：​/* 关于 */

Eijux：​/* 关于 */

Eijux：​/* MQ 基础 */

Eijux：​/* 消息中间件模式分类 */

Eijux：​/* 关于 */

Eijux：​/* 不同MQ的特点对比？ */

2021年5月14日 (五) 20:06 Eijux

Eijux：​建立内容为“消息中间件 == 关于 ==”的新页面

Eijux：Eijux移动页面分类:消息中间件至分类:MQ，不留重定向

Eijux：/* 关于 */

Eijux：/* 关于 */

Eijux：/* 关于 */

Eijux：/* MQ 基础 */

Eijux：/* 消息中间件模式分类 */

Eijux：/* 关于 */

Eijux：/* 不同MQ的特点对比？ */

Eijux：建立内容为“
消息中间件
== 关于 ==”的新页面