RabbitMQ入门
消息队列(Message Queue,简称MQ),从字面意思上看,本质是个队列,FIFO先入先出,只不过队列中存放的内容是message而已
Rabbit
RabbitMQ 使用 Erlang 语言编写,这是一个比较小众的编程语言,学习成本非常高,不像 Java、Scala、C 等编程语言学起来简单。所以虽然 RabbitMQ 也是开源的消息队列,但基于 RabbitMQ 做扩展和二次开发的情况是很少。
另一方面从使用的协议来看,RabbitMQ 支持 AMQP(Advanced Message Queuing Protocol) 协议,这也是主流消息队列不支持的。
- Connection:一个网络连接,AMQP 协议通常使用长连接;
- Channel:网络信道,建立在 Connection 之上的轻量级的连接,一个 Connection 可以有多个 Channel;
- Exchange:交换器,接收消息后将消息路由转发给绑定(Binding)的 Queue;
- Binding:Exchange 和 Queue 之间的虚拟连接;
- Routing Key:这个概念在图中没有画,是指路由规则,用来确定 Exchange 将消息路由到哪些 Queue。
部署
RabbitMQ 是一个非常轻量级的消息队列,官方宣称开箱即用。在 Docker 上部署 RabbitMQ,三个命令就可以。
- 拉取镜像
1 | docker pull rabbitmq:3.8.2-management |
- 创建路径
1 | mkdir /var/lib/rabbitmq |
- 启动容器
1 | docker run -d --name rabbitmq3.8.2 -p 5672:5672 -p 15672:15672 -v `pwd`/data:/var/lib/rabbitmq --hostname myRabbit -e RABBITMQ_DEFAULT_VHOST=my_vhost -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin --privileged=true |
这种开箱即用的效果,大大降低了学习成本和运维成本。
应用场景
主要解决异步处理、应用解耦、流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构
异步处理
用户注册后,需要发注册邮件和注册短信


应用解耦
用户下单后,订单系统需要通知库存系统

流量削峰
流量削锋也是消息队列中的常用场景,一般在秒杀或团抢活动中使用广泛
应用场景:秒杀活动,一般会因为流量过大,导致流量暴增,应用挂掉。
为解决这个问题,一般需要在应用前端加入消息队列 :
a、可以控制活动的人数
b、可以缓解短时间内高流量压垮应用用户的请求,服务器接收后,首先写入消息队列。假如消息队列长度超过最大数量,则直接抛弃用户请求或跳转到错误页面。秒杀业务根据消息队列中的请求信息,再做后续处理
参考文章
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 SquaneBlog!
评论