上一篇文章讲了系统间通信的一些基本信息,本篇文章开始,将结合我的学习经验为大家介绍系统间通信优化的过程。
系统间通信的优化,主要是通过选择不同的通信模型来达到优化的目的。前文讲过通信模型有大体上可以分为四种:阻塞式,非阻塞式,同步,异步。通信模型的优化也可以理解为这四种通信模型的发展史。
接下来具体介绍优化的方案。
1.采用多线程。
注:本例不考虑以下情况(1)通信模型的影响(2)CPU不够,以及多个线程用同样的资源
确切的说,多线程优化系统间通信并不属于通过通信模型来优化。但是多线程确实可以达到优化系统间通信的目的。
举个例子(这个地方):如果现在有1000个客户同时请求一台服务器,那么服务器在收到这1000个请求以后,用一个线程去处理这1000个请求,那么这1000个请求是顺序执行的。假设处理第一个客户的请求用了1min,那么第二个客户得到服务器的响应最起码要在1min之后了,如果是第1000个客户,那时间可能就很久了。显然这样的处理方式会给用户带来很差的体验,在现实中是不可行的。
这个时候,就可以用多线程来处理。同样是1000个客户请求,服务器针对每个接收到的请求都创建一个单独的线程去处理,那么第一个线程在处理第一个客户请求的时候,第二个线程也可以同时处理第二个客户的请求...第1000个线程也可以同时处理第1000个客户的请求。显然这样处理会快很多。
当然使用多线程会存在一下问题:
(1)每个系统支持的最大线程数是有限制的。线程数量越多,CPU切换线程花费的时间越多,那么用来处理业务需求的时间就少了。
(2)操作系统创建线程是需要消耗资源的。JVM创建一个线程,即使这个线程什么都不做,但是也会为这个线程分配128K的堆栈空间。
(3)如果应用程序使用的是长连接,那么线程不会被关闭,这样系统资源的消耗也会更容易失控。
(4)有人可能会想到用线程池来控制线程。但是,虽然可以用线程池来控制线程创建,但是如果请求过多,创建的线程数达到了线程池中的最大线程数,那么新的请求会造成BlockingQueue的积压,也会消耗资源。
所以,使用线程可以达到系统间通信的优化,但是单纯的使用多线程并不是最优的选择。因为现实中每个服务器节点都会有很大的并发请求,而且使用多线程并没有从根本上解决通信模型中的"阻塞"和"同步"问题。
注:关于多线程的优化,就不上代码了,就是针对每个请求创建一个线程,单独去处理每个请求。