系统间通信（二）---优化篇（1）

    上一篇文章讲了系统间通信的一些基本信息，本篇文章开始，将结合我的学习经验为大家介绍系统间通信优化的过程。

    系统间通信的优化，主要是通过选择不同的通信模型来达到优化的目的。前文讲过通信模型有大体上可以分为四种：阻塞式，非阻塞式，同步，异步。通信模型的优化也可以理解为这四种通信模型的发展史。

    接下来具体介绍优化的方案。

1.采用多线程。

    注：本例不考虑以下情况（1）通信模型的影响（2）CPU不够，以及多个线程用同样的资源

    确切的说，多线程优化系统间通信并不属于通过通信模型来优化。但是多线程确实可以达到优化系统间通信的目的。

    举个例子（这个地方）：如果现在有1000个客户同时请求一台服务器，那么服务器在收到这1000个请求以后，用一个线程去处理这1000个请求，那么这1000个请求是顺序执行的。假设处理第一个客户的请求用了1min，那么第二个客户得到服务器的响应最起码要在1min之后了，如果是第1000个客户，那时间可能就很久了。显然这样的处理方式会给用户带来很差的体验，在现实中是不可行的。

    这个时候，就可以用多线程来处理。同样是1000个客户请求，服务器针对每个接收到的请求都创建一个单独的线程去处理，那么第一个线程在处理第一个客户请求的时候，第二个线程也可以同时处理第二个客户的请求...第1000个线程也可以同时处理第1000个客户的请求。显然这样处理会快很多。

    当然使用多线程会存在一下问题：

        （1）每个系统支持的最大线程数是有限制的。线程数量越多，CPU切换线程花费的时间越多，那么用来处理业务需求的时间就少了。

        （2）操作系统创建线程是需要消耗资源的。JVM创建一个线程，即使这个线程什么都不做，但是也会为这个线程分配128K的堆栈空间。

        （3）如果应用程序使用的是长连接，那么线程不会被关闭，这样系统资源的消耗也会更容易失控。

        （4）有人可能会想到用线程池来控制线程。但是，虽然可以用线程池来控制线程创建，但是如果请求过多，创建的线程数达到了线程池中的最大线程数，那么新的请求会造成BlockingQueue的积压，也会消耗资源。

        所以，使用线程可以达到系统间通信的优化，但是单纯的使用多线程并不是最优的选择。因为现实中每个服务器节点都会有很大的并发请求，而且使用多线程并没有从根本上解决通信模型中的"阻塞"和"同步"问题。

        注：关于多线程的优化，就不上代码了，就是针对每个请求创建一个线程，单独去处理每个请求。