同步阻塞与异步非阻塞
同步阻塞消息处理
假如有这样一个系统功能，客户端提交Event至服务器，服务器接收到客户请求之后开辟线程处理客户请求，经过比较复杂的业务计算后将结果返回给客户端 |
|---|
| 以上设计存在几个显著的缺陷，具体如下。 |
|---|
·同步Event提交，客户端等待时间过长（提交Event时长+接受Event创建thread时长+业务处理时长+返回结果时长）会陷入阻塞，导致二次提交Event耗时过长。 |
·由于客户端提交的Event数量不多，导致系统同时受理业务数量有限，也就是系统整体的吞吐量不高。 |
·这种一个线程处理一个Event的方式，会导致出现频繁的创建开启与销毁，从而增加系统额外开销。 |
·在业务达到峰值的时候，大量的业务处理线程阻塞会导致频繁的CPU上下文切换，从而降低系统性能。 |
异步非阻塞消息处理
前面分析了同步阻塞消息的处理方式存在诸多缺陷，尤其是系统的吞吐量低，很难应对比较高的业务并发量。如果我们将同步阻塞的方式换成异步非阻塞的方式，则不仅可以提高系统的吞吐量，而且业务处理线程的数量也能够控制在一个固定的范围，以增加系统的稳定性。 |
|---|
客户端提交Event后会得到一个相应的工单并且立即返回，Event则会被放置在Event队列中。服务端有若干个工作线程，不断地从Event队列中获取任务并且进行异步处理，最后将处理结果保存至另外一个结果集中，如果客户端想要获得处理结果，则可凭借工单号再次查询。 |
|---|
| 两种方式相比较，你会发现异步非阻塞的优势非常明显 |
|---|
首先客户端不用等到结果处理结束之后才能返回，从而提高了系统的吞吐量和并发量； |
其次若服务端的线程数量在一个可控的范围之内是不会导致太多的CPU上下文切换从而带来的额外开销的； |
再次服务端线程可以重复利用，这样就减少了不断创建线程带来的资源浪费。 |
|
但是异步处理的方式同样也存在缺陷，比如客户端想要得到结果还需要再次调用接口方法进行查询（可以利用异步回调接口的方式来解决这个问题） |
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/595339.html
如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！
