动态每日更新算法题,想要一起学习的小伙伴可以关注一下
文章目录
一、RabbitMQ是什么?
1、基本概念
名词介绍
Exchange:消息交换机,它指定消息按什么规则,路由到哪个队列
Broker:安装消息中间件的服务器
Queue:消息的载体,每个消息都会被投到一个或多个队列
Binding:绑定,它的作用就是把exchange和queue按照路由规则绑定起来
Routing Key:路由关键字,exchange根据这个关键字进行消息投递
Producer:消息生产者,就是投递消息的程序
Consumer:消息消费者,就是接受消息的程序
Channel:消息通道,在客户端的每个连接里,可建立多个channel
2、基本流程
- 生产者(publisher)连接到消息队列服务器(Broker),打开一个channel。这种连接是长连接,只连接一次,且不会断开。
- 消息从生产者(publisher)发出,由channel传输到达服务器(Broke)r,再由Broker交由交换机(exchange)。
- 交换机(exchange)根据消息中带来的消息体中获取route-key,再由交换机根据绑定的相应消息队列,路由给这个队列。(比如route-key=2,那么就路由给2号消息队列)(前提交换机类型是direct)
- 消费者(consumer)与Broker建立长连接,且建立多个channel,每个channel会监听对应的消息队列(queue),当有新消息到达时就会拿到消息。
1. Direct Exchange
exchange也有几个类型,完全根据key进行投递的叫做Direct交换机,例如,绑定时设置了routing key为”abc”,那么客户端提交的消息,只有设置了key为”abc”的才会投递到队列。
2. Topic Exchange
对key进行模式匹配后进行投递的叫做Topic交换机,符 号”#”匹配一个或多个词,符号””匹配正好一个词。例如”abc.#”匹配”abc.def.ghi”,”abc.”只匹配”abc.def”。
3. Fanout Exchange
还 有一种不需要key的,叫做Fanout交换机,它采取广播模式,一个消息进来时,投递到与该交换机绑定的所有队列。
3.RabbitMQ的优点
1. 异步处理
对于没有严格要求先后的顺序我们无须同步,可以直接进行异步操作。
以常见的订单系统为例,用户点击【下单】按钮之后的业务逻辑可能包括:扣减库存、生成相应单据、发红包、发短信通知。在业务发展初期这些逻辑可能放在一起同步执行,随着业务的发展订单量增长,需要提升系统服务的性能,这时可以将一些不需要立即生效的操作拆分出来异步执行,比如发放红包、发短信通知等。这种场景下就可以用 MQ ,在下单的主流程(比如扣减库存、生成相应单据)完成之后发送一条消息到 MQ 让主流程快速完结,而由另外的单独线程拉取MQ的消息(或者由 MQ 推送消息),当发现 MQ 中有发红包或发短信之类的消息时,执行相应的业务逻辑。
2.应用解耦
在分布式架构下,如果上层服务的源代码改变之后(如接口等),那么下层服务也随之需要改变代码,如果将信息存由RabbitMQ进行转发订阅,那么下层服务不需要改变代码
3.流量削峰
最常见的就是秒杀系统,在大并发到来之前我们将信息转存入消息中间件可以起到一个缓冲的作用。
二、RabbitMQ安装
1.安装Docker
elasticsearch安装附带docker和kibana
在先前的文章中已经说明了如何安装Docker,只需要安装阿里云镜像即可。
2.安装RabbitMQ
docker run -d --name rabbitmq --publish 5671:5671 \
--publish 5672:5672 --publish 4369:4369 --publish 25672:25672 --publish 15671:15671 --publish 15672:15672 \
rabbitmq:management
直接docker run RabbitMQ,当在本地镜像库中没有找到时,就会自行从云镜像拉取。
3. 登录web浏览器查看RabbitMQ服务器
登录到本机地址
http://192.168.1.150:15672
三、 发展现状
一般的业务系统要引入 MQ,最早大家都用 ActiveMQ,但是现在确实大家用的不多了,没经过大规模吞吐量场景的验证,社区也不是很活跃,所以大家还是算了吧,我个人不推荐用这个了;后来大家开始用 RabbitMQ,但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它,对公司而言,几乎处于不可控的状态,但是确实人家是开源的,比较稳定的支持,活跃度也高;不过现在确实越来越多的公司会去用 RocketMQ,确实很不错。
而且RabbitMQ在大并发情况下很容易发生宕机,一旦发生宕机那么上下游的服务器全部不能正常运转,并不能做到高吞吐,就是因此kafka诞生了,在面对大量的流式数据情况下,kafka能够很好的做到消息自然堆积,并不会轻易发生宕机,所以在使用难度和在各种业务场景下,RabbitMQ或许正慢慢退出舞台,但是我们还是要学的,就像大数据的spark框架,难道你就不学Mapreduce了吗?