【消息队列】三高角度看消息队列与传统设计的区别

👏大家好！我是和风coding，希望我的文章能给你带来帮助！
🔥如果感觉博主的文章还不错的话，请👍三连支持👍一下博主哦
📝点击 我的主页 还可以看到和风的其他内容噢，更多内容等你来探索！
📕欢迎参观我的个人网站：Gentlewind

---

---

传统设计

这是一个用户购物下单的流程图：

观察一下上面的设计，属于典型的串行化调用，这种设计模式有一个很大的优势，就是代码简单，出现问题很容易定位到问题。但是也有很多劣势，下面咱们从三高（高并发，高性能，高可用）三个方面去评审一下这个设计。

• 高并发：因为这些操作都是由一个线程（主线程）去执行这些操作，所以当我们的QPS如果很高的话，很容易造成超时。
• 高性能：因为上面这种设计模式是串行的，假设我的每次网络传输耗时200ms，业务处理需要20ms，完成上面那些操作需要耗时2s，这样用户体验也会很差（想象一下每次下单都需要等2s）,如果用户下单后的操作越来越多，耗时只会越来越高。
  所以在一个大型的互联网项目中，以上设计是完全不可取的（非核心模块除外）。
• 高可用：这些服务假如有一个服务挂掉（宕机或者网络波动），就意味着我这个请求失败了，这样用户体验会极差，用户会频繁看到支付失败。

并行处理调优

既然上面说的是串行模块，那么我们用自己的线程池把他改为并行的设计，再看评审一下。
所谓的并行设计就是原来由一个线程去串行做的逻辑，改为多个线程并行去做。

• 高可用：这些服务假如有一个服务挂掉（宕机或者网络波动），理论上讲，如果补偿服务做的出色的话，还是满足高可用的。（可以用try,catch）
• 高并发：相比上面的设计，系统的吞吐量可以达到了很大程度上的提升。
• 高性能：相比上面的设计，因为很多业务是并行执行的，所以相当于只有200*2+20，就可以返回。
  上面这个设计看起来还是不错的设计，所以在很多这种串行调用，多次io的时候，我们就可以采用这种方案，上面这种设计也是多线程的一种实战应用。
  下面来分析一下弊端：
  1. 系统的可扩展性太差了。上面只是列举了4步，但是实际上会有几十步，这几十步放到代码里就会像屎堆一样，可维护性极差。每次加一个步骤，都要多调一个接口，然后重新发布一下服务。
  2. 系统的耦合性太高了。想象一下，几十个http调用放到一起并发执行，很有可能会影响其他的点，尤其是淘宝京东这种秒杀敏感的业务，和钱挂钩的业务，很容易出现p0级别的bug。
  3. 使用的业务本身的线程池，在并发很多的情况下，容易造成cpu的竞争。

消息队列

咱们继续从三高的层面去审视一下这个设计：

• 高可用：当我系统里的一个模块宕机了，因为消息队列对服务调用之间的解耦，不会直接影响到我其他服务。（然后可以通过分布式事务来保证数据最终一致性）
• 高性能：用户下单，将下单所需要的数据都放到消息队列里，就直接返回了，所有耗时相当于就是网络传输所耗时。
• 高并发：由于消息队列不处理任何业务上的逻辑，所以它支持的并发是百万级别的。假如有100万个用户下单，100万的数据放到消息队列里，连接消息队列的服务慢慢消费即可，也不至于造成瞬间有百万请求进来，将我的服务压垮。

本文章转载于：https://blog.csdn.net/m0_51963973/article/details/131378531?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522172223551916800222830617%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=172223551916800222830617&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2_blogfirst_rank_ecpm_v1~rank_v31_ecpm-1-131378531-null-null.nonecase&utm_term=%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97&spm=1018.2226.3001.4450