真正的稳定，是自己不断成长，不断寻找新的空间。与其要稳定，不如开始拥抱这个变化的时代，让自己准备好。
python实践
【写在前面】：
使用Python操作一轮RabbitMQ之后应该对其基础知识做一个认识
【材料】：
【Base 1】：什么是RabbitMQ
RabbitMQ，即消息队列，是对erlang语言开发的AMQP(Advanced Message Queuing Protocol，即高级消息队列协议)的实现。
【Base 2】：RabbitMQ的好处
- 应用解耦，即原本两个系统之间通过接口来串联的，现在使用消息队列，可以防止接口异常时业务不能正常响应的情况，典型案例如下：
订单系统需要调用库存系统来检查是否有库存支持下单，传统方式是订单系统调用库存系统的API来查询，如果该API出现问题，则会影响订单系统的正常下单业务，使用消息队列后，业务场景变成如下方式：
(1). 订单系统负责向消息队列中添加订单信息并实例化，直接返回下单成功；
(2).库存系统订阅消息来处理库存信息。 - 异步，即无相关联系的业务可以异步处理，不需要同步处理，典型案例如下：
用户注册成功后，会收到短信和邮件提醒，这里注册成功的结果和短信、邮件提醒没有必然关系，以下是三种处理方式比较：
(1). 串行方式，即注册->发短信->发邮件都成功才通知用户结果，则相应时间是三者之和；
(2). 并行方式，即注册成功后，同时发短信和发邮件成功后通知用户结果，则相应时间是注册时间+发短信和发邮件最长的一个时间；
(3). 异步方式，即注册后直接返回用户成功，将注册信息写入到消息队列，发短信和发邮件同时监听消息并处理，则相应时间是注册时间+写消息队列时间(可忽略)。 - 削峰，即转移瞬间压力的方法，一般在秒杀场景中最多：
100w用户同时下单，库存只有3件，处理方式有以下两种：
(1).传统方式是去调用接口来处理，等接口处理成功再返回用户实际结果，该过程对接口服务器，数据库服务器压力非常大，容易出现接口响应慢甚至无响应情况；
(2).使用消息队列，可以设置队列的长度为3，下单系统将消息发到队列，超过3个的直接抛出无库存(简单粗暴)，库存系统订阅消息来处理，所以真正到后端的只有3个请求。
【Base 3】：RabbitMQ内部运转机制
image.png
- RabbitMQ基于TCP长连接的基础上内部使用虚拟连接Channel，即信道，通过信道的建立和关闭来通信；
- Exchange和Queue，Queue存储消息，Exchange中存储的是路由表，即消息和Queue的对应关系，Exchange通过这个表知道将消息发到对应的Queue中；
- Vhost，虚拟broker， 即 mini-RabbitMQ server。其内部均含有独立的 queue、exchange 和 binding 等，有独立的权限控制
【Base 4】：RabbitMQ消息发布模式
在第二节()中已经有列举，常用的有4中模式：
(1). 生产者-消费者模式；
(2). 广播模式；
(3). 指定发布模式；
(4). 模糊匹配模式。
【Base 5】：消息队列有什么缺点
- 系统可用性降低，依赖消息队列，如果消息队列出现问题，则很多业务信息可能就无法恢复了；
- 系统复杂性增加，要考虑消息的很多方面，比如一致性问题、重复消费问题、消息可靠传输等等。
