👏大家好!我是和风coding,希望我的文章能给你带来帮助!
🔥如果感觉博主的文章还不错的话,请👍三连支持👍一下博主哦
📝点击 我的主页 还可以看到和风的其他内容噢,更多内容等你来探索!
📕欢迎参观我的个人网站:Gentlewind
传统设计
这是一个用户购物下单的流程图:
观察一下上面的设计,属于典型的串行化调用,这种设计模式有一个很大的优势,就是代码简单,出现问题很容易定位到问题。但是也有很多劣势,下面咱们从三高(高并发,高性能,高可用)三个方面去评审一下这个设计。
- 高并发:因为这些操作都是由一个线程(主线程)去执行这些操作,所以当我们的QPS如果很高的话,很容易造成超时。
- 高性能:因为上面这种设计模式是串行的,假设我的每次网络传输耗时200ms,业务处理需要20ms,完成上面那些操作需要耗时2s,这样用户体验也会很差(想象一下每次下单都需要等2s),如果用户下单后的操作越来越多,耗时只会越来越高。
所以在一个大型的互联网项目中,以上设计是完全不可取的(非核心模块除外)。 - 高可用:这些服务假如有一个服务挂掉(宕机或者网络波动),就意味着我这个请求失败了,这样用户体验会极差,用户会频繁看到支付失败。
并行处理调优
既然上面说的是串行模块,那么我们用自己的线程池把他改为并行的设计,再看评审一下。
所谓的并行设计就是原来由一个线程去串行做的逻辑,改为多个线程并行去做。
- 高可用:这些服务假如有一个服务挂掉(宕机或者网络波动),理论上讲,如果补偿服务做的出色的话,还是满足高可用的。(可以用try,catch)
- 高并发:相比上面的设计,系统的吞吐量可以达到了很大程度上的提升。
- 高性能:相比上面的设计,因为很多业务是并行执行的,所以相当于只有200*2+20,就可以返回。
上面这个设计看起来还是不错的设计,所以在很多这种串行调用,多次io的时候,我们就可以采用这种方案,上面这种设计也是多线程的一种实战应用。
下面来分析一下弊端:- 系统的可扩展性太差了。上面只是列举了4步,但是实际上会有几十步,这几十步放到代码里就会像屎堆一样,可维护性极差。每次加一个步骤,都要多调一个接口,然后重新发布一下服务。
- 系统的耦合性太高了。想象一下,几十个http调用放到一起并发执行,很有可能会影响其他的点,尤其是淘宝京东这种秒杀敏感的业务,和钱挂钩的业务,很容易出现p0级别的bug。
- 使用的业务本身的线程池,在并发很多的情况下,容易造成cpu的竞争。
消息队列
咱们继续从三高的层面去审视一下这个设计:
- 高可用:当我系统里的一个模块宕机了,因为消息队列对服务调用之间的解耦,不会直接影响到我其他服务。(然后可以通过分布式事务来保证数据最终一致性)
- 高性能:用户下单,将下单所需要的数据都放到消息队列里,就直接返回了,所有耗时相当于就是网络传输所耗时。
- 高并发:由于消息队列不处理任何业务上的逻辑,所以它支持的并发是百万级别的。假如有100万个用户下单,100万的数据放到消息队列里,连接消息队列的服务慢慢消费即可,也不至于造成瞬间有百万请求进来,将我的服务压垮。