00 RabbitMQ：前言
- [1. 前言](#1. 前言)
-
- [1.1. 举个🌰：快递案例](#1.1. 举个🌰：快递案例)
-
- [1.1.1. 过程对比](#1.1.1. 过程对比)
- [1.1.2. 延伸到程序中](#1.1.2. 延伸到程序中)
- [1.2. 举个🌰：订单案例](#1.2. 举个🌰：订单案例)
-
- [1.2.1. 流程](#1.2.1. 流程)
- [1.2.2. 耦合](#1.2.2. 耦合)
- [1.2.3. 响应时间](#1.2.3. 响应时间)
- [1.2.4. 并发压力](#1.2.4. 并发压力)
- [1.2.5. 系统结构弹性](#1.2.5. 系统结构弹性)
- [1.3. 总结](#1.3. 总结)
1. 前言
1.1. 举个🌰：快递案例
1.1.1. 过程对比
同步： 快递小哥送快递，客户正在开会没办法取快递，于是快递小哥只能一直等着。
异步： 快递小哥将快递放到 丰巢柜 中，给客户发个短信，这单就算完事了，不用一直等着，就可以去送下一单了，效率大大提高。客户散会后，再去 丰巢柜 去自己的快递。
1.1.2. 延伸到程序中
1.2. 举个🌰：订单案例
1.2.1. 流程
同步： 当前面几个步骤成功，中间某个步骤失败，会给客户返回下单失败的响应。这样用户体验极差。
异步： 当客户保存订单后，将订单号存入消息队列，就可以收到响应了。后续的操作属于对接消息队列，往往和客户响应无关，陆陆续续去做就可以。
1.2.2. 耦合
同步： 客户下单后，只有当所有步骤走完才可以收到响应。
异步： 客户下单成功后，订单号保存到消息队列，给客户返回下单成功的响应。至于后续的某一步骤失败，可以单独的去处理，不影响客户的正常响应。
1.2.3. 响应时间
同步： 响应时间是全部步骤时间总和，时间相对较长。
异步： 核心步骤完成后，就可以给客户响应了，时间相对较短，大大提升了响应速度。
1.2.4. 并发压力
同步： 并发压力向后传递。前一个步骤承受多大并发量，后续步骤依旧承受相同的并发量。
异步： 由于引入的 消息队列 ，前面步骤承受的并发量和后面步骤承受的并发量可以是不一样的。后面的模块对接消息队列时调整一些参数，可以降低并发量。因为后面的步骤执行通常情况下客户并不关心，不影响给客户返回响应，所及执行速度慢一些也无伤大雅。至此实现了 削峰填谷 的效果。
📣📣📣拓展：
某个时间段，访问量过大，超过硬件承受能力，造成服务器宕机。
某个时间段，访问量很低，服务器资源利用率降低。
旱的旱死，涝的涝死。
将高峰期的任务，转移到低谷期来处理。实现了一时间来换空间。高峰期的时候，客户的访问量对服务器的冲击也不会很大，低谷期时也能实现服务器资源更充分地利用。
1.2.5. 系统结构弹性
同步： 比如说后期新增加个步骤，有可能对原有的步骤进行代码上的修改，牵一发而动全身，工作量可能远超预估。
异步： 新增的模块同样对接消息队列，用订单号可以查询任何数据，原有的功能不需要任何代码修改，完全符合开闭原则（对修改关闭，对扩展开放）。
1.3. 总结
| 方式 | 简述 |
|---|---|
| 同步 | 系统耦合度高 响应时间长 并发压力持续向后续服务传导 系统结构缺乏弹性，可扩展性差 |
| 异步 | 参与的各功能模块相对独立，耦合度低 响应时间短 借助消息队列实现流量削峰填谷 各功能模块对接消息队列，系统功能扩展方便 |
📣📣📣注意：
并不是把所有交互方式都需要改成异步。
强关联调用还是通过OpenFeign进行同步调用。
弱关联、可独立拆分出来的功能可以使用消息队列进行异步调用。
本文隶属于【个人专栏】：06 RabbitMQ📋📋📋
到这里 00 RabbitMQ：前言 就结束了！！！🎉🎉🎉
后续接 01 RabbitMQ：简单介绍 📣📣📣
欢迎小伙伴们学习和指正！！！😊😊😊
祝大家学习和工作一切顺利！！！😎😎😎