同步阻塞与异步非阻塞(简单了解)

1 同步阻塞消息处理

假如有这样一个系统功能,客户端提交Event至服务器,服务器接收到客户请求之后开辟线程处理客户请求,经过比较复杂的业务计算后将结果返回给客户端

在这里插入图片描述
图5-1所示的设计存在几个显著的缺陷,具体如下:

  • 同步Event提交,客户端等待时间过长(提交Event时长+接受Event创建thread时长+业务处理时长+返回结果时长)会陷入阻塞,导致二次提交Event耗时过长。
  • 由于客户端提交的Event数量不多,导致系统同时受理业务数量有限,也就是系统整体的吞吐量不高。
  • 这种一个线程处理一个Event的方式,会导致出现频繁的创建开启与销毁,从而增加系统额外开销。
  • 在业务达到峰值的时候,大量的业务处理线程阻塞会导致频繁的CPU上下文切换,从而降低系统性能。

2 异步非阻塞消息处理

前面分析了同步阻塞消息的处理方式存在诸多缺陷,尤其是系统的吞吐量低,很难应对比较高的业务并发量。如果我们将同步阻塞的方式换成异步非阻塞的方式,则不仅可以提高系统的吞吐量,而且业务处理线程的数量也能够控制在一个固定的范围,以增加系统的稳定性

在这里插入图片描述
客户端提交Event后会得到一个相应的工单并且立即返回,Event则会被放置在Event队列中。服务端有若干个工作线程,不断地从Event队列中获取任务并且进行异步处理,最后将处理结果保存至另外一个结果集中,如果客户端想要获得处理结果,则可凭借工单号再次查询。

两种方式相比较,你会发现异步非阻塞的优势非常明显,首先客户端不用等到结果处理结束之后才能返回,从而提高了系统的吞吐量和并发量;其次若服务端的线程

数量在一个可控的范围之内是不会导致太多的CPU上下文切换从而带来的额外开销的;再次服务端线程可以重复利用,这样就减少了不断创建线程带来的资源浪费。但是异步处理的方式同样也存在缺陷,比如客户端想要得到结果还需要再次调用接口方法进行查询(在本书的第4部分会详细讲解如何利用异步回调接口的方式来解决这个问题)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值