【Python实践】_RabbitMQ理论知识

真正的稳定,是自己不断成长,不断寻找新的空间。与其要稳定,不如开始拥抱这个变化的时代,让自己准备好。


python实践

【目录】Python实践

【写在前面】:
使用Python操作一轮RabbitMQ之后应该对其基础知识做一个认识
【材料】:

【Base 1】:什么是RabbitMQ
RabbitMQ,即消息队列,是对erlang语言开发的AMQP(Advanced Message Queuing Protocol,即高级消息队列协议)的实现。

【Base 2】:RabbitMQ的好处

  1. 应用解耦,即原本两个系统之间通过接口来串联的,现在使用消息队列,可以防止接口异常时业务不能正常响应的情况,典型案例如下:
    订单系统需要调用库存系统来检查是否有库存支持下单,传统方式是订单系统调用库存系统的API来查询,如果该API出现问题,则会影响订单系统的正常下单业务,使用消息队列后,业务场景变成如下方式:
    (1). 订单系统负责向消息队列中添加订单信息并实例化,直接返回下单成功;
    (2).库存系统订阅消息来处理库存信息。
  2. 异步,即无相关联系的业务可以异步处理,不需要同步处理,典型案例如下:
    用户注册成功后,会收到短信和邮件提醒,这里注册成功的结果和短信、邮件提醒没有必然关系,以下是三种处理方式比较:
    (1). 串行方式,即注册->发短信->发邮件都成功才通知用户结果,则相应时间是三者之和;
    (2). 并行方式,即注册成功后,同时发短信和发邮件成功后通知用户结果,则相应时间是注册时间+发短信和发邮件最长的一个时间;
    (3). 异步方式,即注册后直接返回用户成功,将注册信息写入到消息队列,发短信和发邮件同时监听消息并处理,则相应时间是注册时间+写消息队列时间(可忽略)。
  3. 削峰,即转移瞬间压力的方法,一般在秒杀场景中最多:
    100w用户同时下单,库存只有3件,处理方式有以下两种:
    (1).传统方式是去调用接口来处理,等接口处理成功再返回用户实际结果,该过程对接口服务器,数据库服务器压力非常大,容易出现接口响应慢甚至无响应情况;
    (2).使用消息队列,可以设置队列的长度为3,下单系统将消息发到队列,超过3个的直接抛出无库存(简单粗暴),库存系统订阅消息来处理,所以真正到后端的只有3个请求。

【Base 3】:RabbitMQ内部运转机制

image.png

  1. RabbitMQ基于TCP长连接的基础上内部使用虚拟连接Channel,即信道,通过信道的建立和关闭来通信;
  2. Exchange和Queue,Queue存储消息,Exchange中存储的是路由表,即消息和Queue的对应关系,Exchange通过这个表知道将消息发到对应的Queue中;
  3. Vhost,虚拟broker, 即 mini-RabbitMQ server。其内部均含有独立的 queue、exchange 和 binding 等,有独立的权限控制

【Base 4】:RabbitMQ消息发布模式
在第二节()中已经有列举,常用的有4中模式:
(1). 生产者-消费者模式;
(2). 广播模式;
(3). 指定发布模式;
(4). 模糊匹配模式。

【Base 5】:消息队列有什么缺点

  1. 系统可用性降低,依赖消息队列,如果消息队列出现问题,则很多业务信息可能就无法恢复了;
  2. 系统复杂性增加,要考虑消息的很多方面,比如一致性问题、重复消费问题、消息可靠传输等等。

推荐阅读更多精彩内容