MQ基础
MQ
为什么使用消息队列
解耦
- A系统发送数据到BCD三个系统,通过接口调用发送,如果新增E系统,则需要A修改代码
使用MQ,一个系统产生一个数据发送到MQ,哪个系统需要数据就去MQ里面消费。这样不需要维护代码,也不需要考虑是否调用成功或者失败问题。
- 通过MQ,Pub/Sub发布订阅模型,一个系统可以跟其他系统彻底解耦
异步
- 一个系统接收一个请求,需要在自己本地写库,还需要在 BCD 三个系统写库,自己本地写库要 3ms,BCD 三个系统分别写库要 300ms、450ms、200ms。请求总就是3 + 300 + 450 + 200 = 953ms
如果使用 MQ,那么 A 系统连续发送 3 条消息到 MQ 5 毫秒,请求中,总耗时为用户,一个系统从接受到返回响应给用户,总时间长是 3 + 5 = 8 毫秒,对于用户来说,实际上感觉上就是点个按钮,8ms以后就直接返回了
削峰
- 某个时间段,请求数据突然暴增5K,但是过了这个时间段,请求又降低了
如果使用MQ,5K请求到MQ,一个系统最多处理2K。系统从MQ慢慢拉取,每次只拉取2K个请求,其他的先暂时积压到MQ中
消息队列的优缺点
- 优点:解耦、异步、削峰
- 缺点:
1.系统可用性降低
- 系统引入额外部依赖越多,越容易挂掉。万一MQ挂了系统也会崩溃。如何保证消息队列的高可用
2.系统复杂度变高
3.一致性问题
- 一个系统处理完成直接返回成功,但是可能其他系统失败,导致数据不一致。如何保证消息的幂等性?
Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点?
rabbitMQ的架构设计
Broker:它提供一种传输服务,它的角色就是维护一条从生产者到消费者的路线,保证数据能按照指定的方式进行传输
Exchange:消息交换机它指定消息按什么规则路由到哪个认列
Queue:消息的载体,每个消息都会被投到一个或多个队列
Binding定,它的作用就是把exchange和queue按照落由规则绑定起来
Routing Key:路由关键字,exchange根据这个关键字进行消息投递.
vhost虚拟主机一个broker里可以有多个vhost,用作不同用户的权限分离.
Producer消息生产者就是投递消息的程序.
Consumer.消息消费者,就是接受消息的程序
Channel消息通道,在客户端的每个连接里可建立多个channel
概念
在mq领域中, producer将msg发送到queue,然后consumer通过消费queue完成PC解耦
kafka是由producer决定msg发送到哪个queue
rabbitmq是由Exchange决定msg应该怎么样发送到目标queue,这就是binding及对应的策略
rabbitMQ事务消息的原理
事务V.S确认
确认是对一件事的确认
事务是对批量的确认
增删改查中,事务是对于增删改的保证
发送方事务
开启事务,发送多条数据,事务提交或回滚是原子的,要么都提交,要么都回滚
消费方事务
消费方是读取行为,那么事务体现在哪里呢
rabbitmq的消费行为会触发queuetmsg的是否删除、是否重新放回队列等行为,类增删改
所以,消费方的ack是要手动提交的,且最终确定以事务的提交和回滚决定
RabbitMQ死信队列、延时队列
死信队列
DLX (Dead Letter Exchange) ,死信交换器
当队列中的消息被拒绝、或者过期会变成死信,死信可以被重新发布到另一个交换器,这个交换器就是DLX,与DLX绑定的队列称为死信队列
造成死信的原因
- 信息被拒绝
- 信息超时
- 超过了队列的最大长度
过期消息
在rabbitmq中存在2种方可设置消息的过期时间,第一种通过对队列进行设置,这种设置后,该队列中所有的消息都存在相同的过期时间,第二种通过对消息本身进行设置,那么每条消息的过期时间都不一样。如果同时使用这2种方法,那么以过期时间小的那个数值为准。当消息达到过期时间还没有被消费,那么那个消息就成为了一个死信消息。
队列设置:在队列申明的时候使用x-message-tt1参数,单位为毫秒
单个消息设置:是设置消息属性的expiration参数的值,单位为毫秒
延迟队列
延迟队列存储的是延迟消息
延迟消息指的是,当消息被发发布出去之后,并不立即投递给消费者,而是在指定时间之后投递。如:
在订单系统中,订单有30秒的付款时间,在订单超时之后在投递给消费者处理超时订单。
rabbitMq没有直接支持延迟队列,可以通过死信队列实现。
在死信队列中,可以为普通交换器绑定多个消息队列,假设绑定过期时间为5分钟,10分钟和30分钟, 3个消息队列,然后为每个消息队列设置DLX,为每个DLX关联一个死信队列。
当消息过期之后,被转存到对应的死信队列中,然后投递给指定的消费者消费。
Enjoy Reading This Article?
Here are some more articles you might like to read next: