高并发架构系列:MQ消息队列的12点核心原理总结
消息队列已经逐渐成为分布式应用场景、内部通信、以及秒杀等高并发业务场景的核心手段,它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能。
无论是 RabbitMQ、RocketMQ、ActiveMQ、Kafka还是其它等,都有的一些基本原理、术语、机制等,总结分享出来,希望大家在使用消息队列技术的时候能够快速理解。
1. 消息生产者、消息者、队列
消息生产者Producer:发送消息到消息队列。
消息消费者Consumer:从消息队列接收消息。
Broker:概念来自与Apache ActiveMQ,指MQ的服务端,帮你把消息从发送端传送到接收端。
消息队列Queue:一个先进先出的消息存储区域。消息按照顺序发送接收,一旦消息被消费处理,该消息将从队列中删除。
2.设计Broker主要考虑
1)消息的转储:在更合适的时间点投递,或者通过一系列手段辅助消息最终能送达消费机。
2)规范一种范式和通用的模式,以满足解耦、最终一致性、错峰等需求。
3)其实简单理解就是一个消息转发器,把一次RPC做成两次RPC。发送者把消息投递到broker,broker再将消息转发一手到接收端。
总结起来就是两次RPC加一次转储,如果要做消费确认,则是三次RPC。
3. 点对点消息队列模型
点对点模型 用于 消息生产者 和 消息消费者 之间 点到点 的通信。
点对点模式包含三个角色:
消息队列(Queue)
发送者(Sender)
接收者(Receiver)
每个消息都被发送到一个特定的队列,接收者从队列中获取消息。队列保留着消息,可以放在 内存 中也可以 持久化,直到他们被消费或超时。
特点
每个消息只有一个消费者(Consumer)(即一旦被消费,消息就不再在消息队列中)
发送者和接收者之间在时间上没有依赖性
接收者在成功接收消息之后需向队列应答成功
4. 发布订阅消息模型Topic
发布订阅模型包含三个角色:
主题(Topic)
发布者(Publisher)
订阅者(Subscriber)
多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。
特点
- 每个消息可以有多个消费者:和点对点方式不同,发布消息可以被所有订阅者消费;
- 发布者和订阅者之间有时间上的依赖性;
- 针对某个主题(Topic)的订阅者,它必须创建一个订阅者之后,才能消费发布者的消息;
- 为了消费消息,订阅者必须保持运行的状态。
5.点对点和发布订阅的区别
生产者发送一条消息到队列queue,只有一个消费者能收到。
发布者发送到topic的消息,只有订阅了topic的订阅者才会收到消息。
6. 消息的顺序性保证
基于Queue消息模型,利用FIFO先进先出的特性,可以保证消息的顺序性。
7. 消息的ACK机制
即消息的Ackownledge确认机制,
为了保证消息不丢失,消息队列提供了消息Acknowledge机制,即ACK机制,当Consumer确认消息已经被消费处理,发送一个ACK给消息队列,此时消息队列便可以删除这个消息了。如果Consumer宕机/关闭,没有发送ACK,消息队列将认为这个消息没有被处理,会将这个消息重新发送给其他的Consumer重新消费处理。
8.最终一致性的设计思路
主要是用“记录”和“补偿”的方式。
本地事务维护业务变化和通知消息,一起落地,然后RPC到达broker,在broker成功落地后,RPC返回成功,本地消息可以删除。否则本地消息一直靠定时任务轮询不断重发,这样就保证了消息可靠落地broker。
broker往consumer发送消息的过程类似,一直发送消息,直到consumer发送消费成功确认。
我们先不理会重复消息的问题,通过两次消息落地加补偿,下游是一定可以收到消息的。然后依赖状态机版本号等方式做判重,更新自己的业务,就实现了最终一致性。
如果出现消费方处理过慢消费不过来,要允许消费方主动ack error,并可以与broker约定下次投递的时间。
对于broker投递到consumer的消息,由于不确定丢失是在业务处理过程中还是消息发送丢失的情况下,有必要记录下投递的IP地址。决定重发之前询问这个IP,消息处理成功了吗?如果询问无果,再重发。
事务:本地事务,本地落地,补偿发送。本地事务做的,是业务落地和消息落地的事务,而不是业务落地和RPC成功的事务。消息只要成功落地,很大程度上就没有丢失的风险。
9. 消息的事务支持
消息的收发处理支持事务,例如:在任务中心场景中,一次处理可能涉及多个消息的接收、处理,这应该处于同一个事务范围内,如果一个消息处理失败,事务回滚,消息重新回到队列中。
10. 消息的持久化
消息的持久化,对于一些关键的核心业务来说是非常重要的,启用消息持久化后,消息队列宕机重启后,消息可以从持久化存储恢复,消息不丢失,可以继续消费处理。
11. 消息队列的高可用性
在实际生产环境中,使用单个实例的消息队列服务,如果遇到宕机、重启等系统问题,消息队列就无法提供服务了,因此很多场景下,我们希望消息队列有高可用性支持,例如
RabbitMQ的镜像集群模式的高可用性方案,ActiveMQ也有基于LevelDB+ZooKeeper的高可用性方案,以及Kafka的Replication机制等。
12.消息队列的选型和应用场景
具体请参考:高并发架构系列:详解分布式之消息队列的特点、选型、及应用场景,更多优质内容,推荐群179961551了解,本号专注技术学习交流、分享面试机会,我会不定期回答群内问题~
以上是就是消息队列MQ技术的一些梳理和归纳,希望对大家有帮助。
觉得不错请点赞支持,更多分享,查看我往期博文~
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Java程序员干货学习笔记—Spring结合MyBatis实现数据库读写分离
随着系统用户访问量的不断增加,数据库的频繁访问将成为我们系统的一大瓶颈之一。由于项目前期用户量不大,我们实现单一的数据库就能完成。但是后期单一的数据库根本无法支撑庞大的项目去访问数据库,那么如何解决这个问题呢? 实际的应用中,数据库都是读多写少(读取数据的频率高,更新数据的频率相对较少),而读取数据通常耗时比较长,占用数据库服务器的CPU较多,从而影响用户体验。我们通常的做法就是把查询从主库中抽取出来,采用多个从库,使用负载均衡,减轻每个从库的查询压力。 采用读写分离技术的目标:有效减轻Master库的压力,又可以把用户查询数据的请求分发到不同的Slave库,从而保证系统的健壮性。我们看下采用读写分离的背景。 我们在项目开发初期的时候就设计了一个简单的读写分离,现在我把demo分享给大家。 采用技术Spring + mybatis 首先定义一个annotation import java.lang.annotation.ElementType; import java.lang.annotation.Target; import java.lang.annotation.Retenti...
- 下一篇
12月28日云栖精选夜读 | 一篇文章掌握Java注解
什么是注解? 用一个词就可以描述注解,那就是元数据,即一种描述数据的数据。所以,可以说注解就是源代码的元数据。比如,下面这段代码: @Override public String toString() { return "This is String Representation of current object."; } 上面的代码中,我重写了toString()方法并使用了@Override注解。 热点热议 一篇文章掌握Java注解 作者:动力节点 蚂蚁金服核心技术:百亿特征实时推荐算法揭秘 作者:技术小能手发表在:阿里技术 一场稳定、高清、流畅的大型活动直播是怎么炼成的? 作者:樰篱发表在:阿里云视频云 知识整理 Spring Bean注入/单例理解/循环依赖 作者:v18653847113 初识Django(一) 作者:死生之契 开源EDR(OSSEC)基础篇- 01 -设计定位与能力输出 作者:orright python 类的继承 作者:hiekay 正则表达式 命名捕获组 作者:hyzhou 美文回顾 (九)Java springcloud B2B2C o2o多用户商...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2全家桶,快速入门学习开发网站教程
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8编译安装MySQL8.0.19
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- MySQL8.0.19开启GTID主从同步CentOS8