从JAVA多线程理解到集群分布式和网络设计的浅析

对于JAVA多线程的应用很是普遍，如今的系统没有多线程几乎什么也作不了，不少时候咱们在何种场合如何应用多线程成为一种首先须要选择的问题，另外关于java多线程的知识也是很是的多，本文中先介绍和说明一些经常使用的，在后续文章中若是有必要再说明更加复杂的吧，本文主要说明多线程的一下几个内容：

一、在应用开发中何时选择多线程？

2、多线程应该注意些什么？

3、状态转换控制，如何解决死锁？

4、如何设计一个具备可扩展性的多线程处理器？

五、多线程联想：在多主机下的扩展-集群？

六、WEB应用的多线程以及长链接原理。

 

一、在应用开发中何时选择多线程。

在前序的文章中已经简单说起到过一些关于多线程应用的文章，经过对web的一些线程控制对下载流量的控制，其实那只是雕虫小技，也存在不少的问题须要去解决，不过面对用户量不大的人群通常问题不大而已。

多线程在生活中的体现就是将多个一样不少事情交给多我的来并行的完成，而中间有一个主线程起到调度者的做用，运行者能够强制依赖于主线程的存在而存在，也可让主线程依赖于自身；曾经我听不少人说过若是你的机器是单CPU，多线程没有意义，其实我并不这么认为，觉得内单个CPU只能证实在线程被调度的瞬间只能同时执行一条最底层的命令，而并不表明不能够在CPU的征用上提升效率，一个是内存级别的，而另外一个是CPU级别的，效率上仍然存在很大差距的；（这个可让一个程序单线程去循环10亿次（每次自增1），和让十个线程独立运行1亿次也是一样的动做，记住这里不要将每条数据System.out.println出来，一个是机器扛不住，另外一个是这里会对测试数据产生影响，由于这个方法我前面的文章中已经说明会产生阻塞，尤为是在并发状况下的阻塞，即便在单CPU下结果确定也是有很大差距的，我这暂时没有单核的PC机器，因此无法获得一些测试结果数据给你们，请有条件的朋友本身测试一下）。

在如今的系统中无时无刻都离不开多线程的思想，包括集群、分布式均可以理解为多线程的一种原理，那么什么是多线程的原理呢？多线程和多进程的是什么呢？

其实要实现分布最简单的思想就是多进程，其实相似于在系统分隔过程当中的一种垂直分隔，将不一样业务的系统分布在不一样的节点上运行，他们彼此互不干扰，而多进程的申请、释放资源各方面的开销都很大，并且占用资源并不是CPU级别的，而线程是属于进程内部更细节的内容，一个进程内部能够分配N个线程，这些线程会并行的征用CPU资源，若是你的机器是多核的处理器，并发将会带来异常的性能提高，其实原理上就是在有限的资源下，如何发挥出最大的性能优点（可是必定是资源有必定余量的状况下，正所谓作事不能作得太绝）。

在java中经常使用于实现多线程的方法有3中：

一、继承于Thread类，重写run方法

二、实现Runable接口，实现run方法

三、实现Callable接口，实现call方法（具备返回值）

至于调用的方法多种多样，能够直接用start启动，也可使用java.util.concurrent.Executors来建立线程池来完成，建立的线程池也主要分为：

一、Executors.newSingleThreadScheduledExecutor() 建立一个顺序执行的线程池，你在run方法内部无需使用synchronized来同步，由于它自己是顺序的。

二、Executors.newCachedThreadPool()建立一个线程池，线程会并行的去执行它。

三、Executors.newFixedThreadPool(10)建立大小为10的一个线程池，这个线程池最多建立长度为10的队列，若是超过10个，就最多有10个线程在执行，便可以控制线程的数量，也可让其并行执行。

 

若是你的系统是一个WEB应用，建议尽可能不要再web应用中作多线程，由于这部分线程控制主要是由web容器控制的，若是在非得必要的状况下创建，尽可能创建较少，或者尽可能将能够不太频繁调度的线程使用完后直接释放掉，哪怕下次重建也无所谓。

若是你的多线程序是独立运行的，专门用于接受和和处理一些消息，那么我相信最少有一个线程是不断探测的（有不少程序会先休眠一点时间，如：TimeUnit.MINUTES.sleep(SLEEP_TIME)此方法是按照毫秒级进行休眠一段时间），这类程序，最好将线程设置为后台线程（setDaemon(true)，必定要在线程调用run以前调用该方法有效），后台线程和非后台线程最大的区别在于：后台线程在全部非后台线程死掉后，后台线程自动会被杀死和回收；而正如你写其余的多线程程序，即便你的main方法完成（主线程），可是在main中申请的子线程没有完成，程序仍然不会结束。

总的来讲，其实几乎每时每刻写的代码都是多线程的，只是不少事情容器帮助咱们完成了，即便编写本地的AWT、SWING，也在不少控制处理中式异步的，只是这种异步相对较少，更多的异步能够由程序去编写，自定义的多线程通常用于在独立于前段容器应用的后台处理中。为何相似web应用的前端会把多线程早就处理好呢，一个是由于为了减小程序和bug，另一个就是要写好多线程的确不容易，这样会使得程序员去关心更多没有必要关心的东西，也须要程序员拥有很高的水准，可是若是要成为好的程序员就必定要懂多线程，咱们接下来以几个问题入手，再进行说明：

若是一个系统专门用于时钟处理、触发器处理，这个系统多是分布式的，那么在一个系统内部应该如何编写呢？另外多线程中编写的过程当中咱们最郁闷的事情、也是最难琢磨补丁的是什么：多线程如今的运行情况是怎样的？个人这个线程不能死掉，若是死掉了我怎么发现？发现到了如何处理（自动、人工、难道重启）？

带着这些问题，咱们引出了文章下面的一些话题。

 

2、多线程应该注意些什么？

多线程用起来爽，出现问题你就不是那么爽了，简单说来，多线程你最纳闷的就是它的问题；可是不要惧怕它，你惧怕它就永远不能征服它，呵呵，只要摸清楚一些脾气，咱们总有办法征服它的。

◆明白多线程有状态信息，和之间的转换规则？

◆多线程通常在什么状况下会出现焊住或者死掉的现象？

◆多线程焊住或者死掉如何捕获和处理？

这里仅仅是提出问题，提出问题后，在说到问题以前，先说起一下扩展知识点，下面的章节来讲明这些问题。

开源多线程调度任务框架中的一个很好选择是：Quartz，有关它的文章能够到http://wenku.baidu.com/view/3220792eb4daa58da0114a01.html

下载这个文档，这个文档也讲述了大部分该框架的使用方法，不过因为该框架自己的封装层次较多，因此不少底层的实现内容并非那么明显，并且对于线程池的管理基本是透明的，本身只能经过一些其余的手段获得这些内容。

因此拿到这个框架首先学习好它的特性后，进一步就是看如何进一步封装它获得最适合你项目的内容。

另外多线程在数据结构选项上也有不少技巧，关于多线程并发资源共享上的数据结构选型专门来和你们探讨，由于技巧的确不少，尤为是jdk 1.6之后提出了不少的数据结构，它参考了相似于oracle的版本号原理，在内存中作了数据复制以及原子拷贝的方法，实现了即保证一致性读写又在很大程度上下降了并发的征用；另外还有对于乐观锁机制，也是高性能的多线程设计中很是重要知识体系。

 

3、状态转换控制，如何解决死锁。

3.1.java默认线程的状态有哪些？（所谓默认线程就是本身没有重写）

NEW ：刚刚建立的线程，什么也没有作，也就是尚未使用start命令启动的线程。

BLOCKED ：阻塞或者叫梗阻，也就是线程此时因为锁或者某些网络缘由形成阻塞，有焊住的迹象。

WAITING：等待锁状态，它在等待对一个资源的notify，即资源的一个锁机会，这个状态通常和一个静态资源绑定，并在使用中有synchronzed关键字的包装，当使用obj.wait()方法时，当前线程就会等待obj对象上的一个notify方法，这个对象多是this，若是是this的话那么在方法体上面通常就会有一个synchronized关键字。

TIME_WAITDE:基于时间的等待，当线程使用了sleep命令后，就会处于时间等待状态，时间到的时候，恢复到running状态。

RUNNING：运行状态，即线程正在处于运行之中（当线程被梗阻）。

TERMINATED：线程已经完成，此时线程的isAlive()返回为false。

通常默认的线程状态就是这些，部分容器或者框架会把线程的状态等进行进一步的封装操做，线程的名称和状态的内容会有不少的变化，不过只要找好对应的原理也不会脱离于这个本质。

3.1.线程通常在什么状况下会死掉？

锁，相互交叉派对，最终致使死锁；多是程序中本身致使，编写共享缓存以及自定义的一部分脱离于容器的线程池管理这里就须要注意了；还有就是有多是分布式的一些共享文件或者分布式数据库的锁致使。

网络梗阻，网络不怕没有，也不怕太快，就怕时快时慢，如今的话叫太不给力了，伤不起啊！而国内如今每每还就是这样不给力；当去网络通讯调用内容的时候（包括数据库交互通常也是经过网络的），就很容易产生焊住的现象，也就是假死，此时很难断定线程究竟是怎么了，除非有提早的监控预案。

其余状况下线程还会死掉吗？就我我的的经验来讲还没遇到过，但并不是毫不可能，我想在常规的同一个JVM内部操做的线程会死掉的几率只有系统挂掉，否则SUN的java虚拟机也太不让人信任了；至少从这一点上咱们能够决定在绝大部分状况下线程阻塞的主要缘由是上述两个主要来源。

在明白绝大部分缘由的基础上，这里已经提出了问题并初步分析了问题，那么继续来如何解决这些问题，或者说将问题的几率下降到很是低的程度（由于没有百分百的高可用性环境，咱们只是要尽可能去作到它尽可能完美，亚马逊的云计算也有宕机的惊人时刻，呵呵）。

3.1. 多线程焊住或者死掉如何捕获和处理？

说到捕获，学习java朋友确定第一想到的是try catch，可是线程假死根本不会抛异常，如何知道线程死掉了呢？

这须要从咱们的设计层面下手，对于后来java提供的线程池也能够比较放心的使用，可是对于不少很是复杂的线程管理，须要咱们本身来设计管理。如何捕获咱们用一个生活中的例子来举例，下一长中将它反馈到实际的系统设计上。

首先多线程本身死掉了它确定不知道，就想一我的本身喝醉了或者被被人打晕了同样，呵呵，那么如何才能知道它的现状了？提出两种现实思路，一个是有一个跟班的人，而另外一种是它上面有一个领导带一群人出来玩，下面人丢了一个它确定要去找。

先看看第一种思路，跟班那个我假如他平时什么也不作，就跟在前者后面，当发现前者倒下，本身立刻跟上去顶替工做，这也是系统架构上常常采用的冗余主从切换，可能一主多从；而云计算也是在基础上的进一步作的异地分流切换和资源动态调度（也就是事情少了，这些人能够去作其余的事情或者睡觉养精神而且为国家节约粮食，当这边的事情忙不过来，会有作其它事情的人或者待命的人来帮着作这些事情；甚至于此地遭到地震洪水类天灾什么的，异地还有机构能够顶替一样的工做内容，这样让对外的服务永远不断间断下来，也就是传说中的24*7的高可用性服务），可是这样冗余太大，成本将会很是巨大。

再看看第二种服务，上面有一个老大，它过一小会看看这帮小弟在作什么，是否是遇到了困难，那里忙它在上面动态调配这资源；好像这种模式很好呢？小弟要是多了，它就忙不过来了，由于资源的分配是须要提早明白下面资源的细节的，否则这个领导不是好领导；那么再细想下去，咱们能够用多个老大，每一个老大带领一个小团队，团队之间能够资源调配，可是团队内部能够由老大本身掌控一切，老大的上面还有个老总它只关心于老大再作什么，而不须要关心小弟们的行为，这样你们的事情就平均起来了；那么问题了又出来了，小弟的问题是能够透明的看到了，要是那个老大出事了甚至于老总出事了怎么办？此时结合第一种思想，咱们此时就只须要再老总下面挂一个跟班的，集合两种模式的特征，也就是小弟不须要配跟班的，这样就节约了很大的成本（由于叶子节点的数量是最多的），而上面的节点咱们须要有跟班的，若是想最大程度节约成本，只须要让主节点配置一个或者多个跟班就能够，可是这样恢复成本就上去了，由于恢复信息须要逐层找到内容才行，通常咱们没有必要在这个基础上再进一步去节约成本。

这些是现实的东西，如何结合到计算机系统架构中，再回到本文的多线程设计上，第四章中一块儿来探讨一下。

 

4、如何设计一个具备可扩展性的多线程处理器。

其实在第三章中，已经从生活的管理模式上找到了不少的解决方案，这也是我我的在解决问题上惯用的手段，由于我的认为再复杂的数学算法也没有人性自己的复杂，生活中的种种手段若用于计算机中可能会获得不少神奇的效果。

若是本身不使用任何开源技术，要作一个多线程处理的框架应该从何下手，在上面分析的基础上，咱们通常会将一个专门处理多线程的系统至少分解为主次二层，也就是主线程引导多个运行线程去处理问题；好了，此时咱们须要解决如下几个问题：

a)多个线程处理的内容是相似的，如何控制并发征用数据或者说下降并发热点的粒度。

方法1：hash散列思想将会是优秀的原则，按照数据特征进行分解数据框，每一个框的数据规则按照一种hash规则分布，hash散列对于编程容易遍历，并且计算速度很是迅速，几乎能够忽略掉定位分组的时间，但结构扩展过程比较麻烦，但在多线程设计中通常不须要考虑这个问题。

方法2：range分布，range范 围分布数据是提早让管理者知道数据的大体分布状况，并按照一种较为平均的规则交给下面的运做线程去去处理本身范围内的数据，相互之间的数据也是没有任何交叉的，其扩展性较好，能够任意扩展，若是分解的数量不受控制的话，分解过多，会形成定位范围比较慢一点，可是多线程设计中也通常不用考虑这个问题，由于程序是由本身编写的。

方法3：位图分布，即数据具备位图规则，通常是状态，这种数据按照位图分布后，线程能够设立为位图个数，找到本身的位图段数据便可作操做，而不须要作进一步的更新，可是每每位图数量有限，而须要处理的数据量很大，一个线程处理一个位图下的全部数据也每每力不从心，若多个线程处理一个位图又会重蹈覆辙。

三种方法各自有优缺点，因此咱们每每采用组合模式来说真个系统的架构达到比较完美的状态，固然没有完美的东西，只有最适应于当前应用环境的架构，因此设计前须要考虑不少预见性问题；关于这种数据分布更多的用于架构，可是架构的基础也来源于程序设计思想，二者思想都是一致的，有关架构和数据存储分布，后面有机会单独讨论。

b)线程死掉如何发现(以及处理)：

管理线程除有运行动做的线程外，还有1~N跟班，个数根据实际状况决定，至少要有一个当管理线程挂掉能够立刻顶替工做，另外还有应当有一个线两程去按期检测线程的运行状况，因为它只负责这件事情，因此很简单，并且这一组中的线程谁死掉均可以相互替换工做并重启新的线程去替代，这个检测的周期不用太快、也不用太慢，只要应用能够接受就能够，由于挂掉些东西，应用阻塞一点时间是很是正常的事情。

发现线程有阻塞现象，在执行中找到了某种之外而阻塞，致使的缘由咱们上面已经分析过，解决的方法通常是在探测几回（这个次数通常是基于配置的）后发现都是处于阻塞状态，就基本能够认为它是错误的了；错误的状况此时须要给该线程执行一个interrupt()方法，此时线程内部的执行会自动的抛出一个异常，也就是理解执行线程的内容的时候尤为是带有网络操做的时候须要带上一个try catch，执行部分都在try中，当出现假死等现状的时候，外部探测到使用一个interrupt()方法，运行程序就会跳转到catch之中，这个里面就不存在征用资源的问题，而快速的将本身的须要回滚的内容执行完，并认为线程执行结束，相应的资源也会获得释放，而使用stop方法之因此如今不推荐是由于它不会释放资源，会致使不少的问题。

另外写代码以前若是涉及到一些网络操做，必定要对你所使用的网络交互程序有不少的深刻认识，如socket交互时，通常状况下若是对方因为网络缘由（通常是有IP当时端口不对或者网段的协议不通）致使在启动链接对方时，socket链接对方好几分钟后才会显示是超时链接，这是默认的，因此你须要提早设置一个启动链接超时保证网络是能够通讯的，再进行执行（注意socket里面还有一个超时是链接后不断的时间，前者为链接以前设置的一个启动链接超时时间，通常这个时间很短，通常是2秒就很长了，由于2秒都链接不上这个网络就基本链接不上了，然后者是运行，有些交互可能长达几小时也有可能，但相似这种交互建议采用异步交互，以保证稳定运行）。

C）若是启动和管理二级管理线程组：

上面有一个主线程来控制启动和关闭，这里能够将这些线程在start前的setDaemon(true)，那么该线程将会被设立为后台线程，所谓后台线程就是当主线程执行完毕释放资源后，被主线程建立的这些线程将会自动释放资源并死掉，若是一个线程被设置为后台线程，若在其run方法内部建立的其余子线程，将会自动被建立为后台线程（若是在构造方法中建立则不是这样）。

管理线程也能够像二级线程同样来管理子节点，只要你的程序不怕写得够复杂，虽然须要使用很是好的代码来编写，而且须要经过很复杂的测试才会稳定运行，可是一旦成功，这个框架将会是很是漂亮和稳定，并且也是高可用的。

 

五、多线程在多主机下的扩展-集群

其实咱们在上面以及说起了一些分布式的知识，也能够叫作数据的分区知识（在网络环境利用PC实现相似于同一个主机上的分区模式，基本就能够称为数据是分布式存储的）。

可是这里提到的集群和这个有一些区别，能够说分布式中包含了集群的概念，可是通常集群的概念也有不少的区别，而且要分app集群和数据库集群。

集群通常是指同一个机组下多个节点（同一台机器也能够部署多个节点），这些节点几乎去完成一样的事情，或者说相似的事情，这就和多线程扯在一块儿了，多线程也正是如此，对比来看就是多线程调度在多主机群组下的实现，因此参照app集群来讲，通常有一个管理节点，它几乎干不多的事情，由于咱们不想让它挂掉，由于他虽然干的事情少，可是却很是重要，一个是从它那里能够获得每个节点的一些应用部署和配置，以及状态等等信息；另外是代理节点或者叫作分发节点，它几乎在管理节点的控制之下只作分发的，固然要保证session一致性。

集群在多线程中的另外一个体现就是挂掉一台，其他的能够顶替，而不会致使全盘死掉；而集群组至关于一个大的线程组，相关牵制管理，也相互能够失败切换，而多个业务会或者多种工具项会划分为不一样的集群组，这就相似于咱们设计线程中的三层线程模式的中多组线程组的模式，每组线程组内部都有本身个性化的属性和共享属性。

而面对数据库集群，就相对比app集群要复杂，app在垂直扩展时几乎只会受到分发节点能力的限制，而这部分是能够调整的，因此它在垂直扩展的过程当中很是方便，而数据库集群则不同，它必须保证事务一致性，并实现事务级别切换和必定程度上的网格计算能力，中间比较复杂的也在内存这块，由于它的数据读入到内存中要将多个主机的内存配置得像一个内存同样（经过心跳完成），并且须要获得动态扩展的能力，这也是数据库集群下扩展性收到限制发展的一个缘由之一。

App难道没有和数据库同样的困难吗？有，可是粒度相对较小，app集群通常不须要考虑事务，由于一个用户的session通常在不出现宕机的状况下，是不会出现复制要求的，而是一直会访问指定的一台机器，因此它们之间几乎不须要通讯；而耦合的粒度在于应用自己的设计，有部分应用系统会本身写代码将一些内容初始化注入到内存中，或者注入到app本地的一个文件中做为文件缓存；这样当这些数据发生改变时他们先改数据库，再修改内存或者通知内存失效；数据库因为集群使用心跳链接，因此保持一致性，而app这边的数据因为只修改掉了自身的内存相关信息，没有修改掉其余机器的内存信息，因此必然致使访问其余数据的机器上的内容是不一致的；至于这部分的解决方案，根据实际项目而定，有经过通讯完成的，也有经过共享缓冲区完成（但这种方式又回到共享池资源征用产生的锁了），也有经过其余方式完成。

大型系统架构最终数据分布，集中式管理，分布式存储计算，业务级别横向切割，同业务下app垂直分隔，数据级别散列+range+位图分布结构，异地分流容灾，待命机组和资源调配的整合，这一切的基础都来源于多线程的设计思想架构在分布式机组上的实现。

六、WEB应用的多线程以及长链接原理

WEB应用中会对一些特殊的业务服务作特殊的服务器定制，相似一些高并发访问系统甚至于专门用于瞬间高并发的系统（不少时候系统不怕高并发，而是怕瞬间高并发）但他们的访问每每比较简单，主要用于事务的处理以及数据的一致性保障，他们在数据的处理上要求在数据库端也不容许有太大的计算量，计算通常在app中去完成，数据库通常只是作存、取、事务一致性动做，这类通常属于特殊的OLTP系统；还有大分类一类是属于并发量不算太大，但每次处理的数据和计算每每比较多，一把说的是OLAP类的系统，而数据的来源通常是OLTP，OLAP每次处理的数据量可能会很是大，通常在类型收集和统计上进行数据dump，须要将OLTP中的数据按照某种业务规则方面查询和检索的方法提取出来组织为有效信息存储在另外一个地方，这个地方有可能仍是数据库，但也有可能不是（数据库的计算能力虽然是数据上最强的可是它在实际应用中它是最慢的一种东西，由于数据库更多的是须要保证不少事务一致性和锁机制问题，以及一些中间解析和优化等等产生的开销是很是大的，并且应用程序与之交互过程是须要经过网络完成，因此不少数据在实际的应用中并不必定非要用数据库）；这两类系统在设计和架构上都有很大的区别，但普通系统二者都有特征，可是都不是那么极端，因此不用考虑太多，这里须要提到的是一类很是特殊的系统，是实时性推送数据并高并发的系统，到目前为止我我的不知道将它归并到哪一类系统中，这的确很特殊的一类系统。

这类系统如：高并发访问中，并且须要将同一个平台下的数据让客户端较为实时的获得内容，这类网站不太可能一次获取很是多的内容到客户端再访问，而确定是经过不少异步交互过程来完成的，下面简单说下这个异步交互。

Web异步交互的全部框架基础都是ajax，其他的相似框架都是在这个基础上完成的；那么此时ajax应该如何来控制交互才能获得几乎接近于实时的内容呢？难道经过客户端不断去刷新相同的URL？那要是客户端很是多，相似于一个大型网站，可能服务器端很快会宕机，除非用比正常状况高出不少倍的服务器成本去作，并且更多的服务器可能在架构上也须要改造才能发挥出他们的性能（由于在服务器的架构上，1 + 1永远是小于2的性能，更多的服务器在开销）。

想到的另外一种办法就是从服务器端向客户端推送数据，那么问题是如何推送，这类操做是基于一种长链接机制完成，长链接即不断开的链接，客户端采用ajax与后端通讯时，后端的反馈信息只要不曾断开就可视为一种长链接的机制；不少是经过socket与服务器端通讯，也可使用ajax，不过ajax须要在其上面作不少的处理才行。

服务器端也是必须使用对应的策略，如今较多的是javaNIO，相对BIO性能要低一点，可是也是很不错的，它在获取到用户请求时并非立刻为用户请求分配线程去处理，而是将请求进行排队，而排队的过程能够本身去控制粒度，而线程也将做为线程池的队列进行分配处理，也就是服务器端对客户端的请求是异步响应（注意这里不是ajax单纯的异步交互，而是服务器端对请求的异步响应），它对不少请求的响应并不是及时，当发生数据变化时，服务器第一时间经过请求列表获取到客户端session列表并与之输出内容，相似于服务器端主动推送数据向客户端；而异步交互的好处是服务器端并不会为每个客户端分配或新申请一个线程，这样会致使高并发时引发的资源分配不过来致使的内存溢出现象；解决了上述两个问题后，另外还有一个问题须要解决的是，当一个线程在处理一个请求任务时，因为线程处理一个任务完成前除非死掉或者焊住，不然是不会断开下来的，这个是确定的（咱们能够将一些大任务切割为一些小任务，线程就处理的速度就会快不少了），可是有一个问题是，服务器端的这个线程可能很快处理好了须要处理的数据内容并向客户端推送，可是客户端因为各种网络通讯问题，致使迟迟不能接受完成，此时该线程也会被占用些没必要要的时间，那么是否在这个中间须要进一步作一层断点传送的缓存呢？缓存不只仅是属于在断点数据须要时取代应用服务器的内容，异步断点向客户端输出信息，同时将应用服务器处理的时间几乎所有集中在数据和业务处理，而不是输出网络上的不少占用，有关网络缓存有不少种作法，后续有机会和你们一块儿探讨关于网络缓存的知识吧。