话接前文《网站、数据库的衍变之路(一) 》。上回说到为了提高网站负载而进行静态化处理。
一、静态化的处理方案（特指生成文件方式）
图1.1
1、html静态方案
图1.1是最常用的静态化处理方式。IIS得到请求交给ASP.Net，根据路径ASP.Net判断是否已经生成这个请求的静态文件，如果存在，则直接输出文件，如果不存在，则读取数据生成静态页，并输出。这种方式最容易理解，准入门槛低，很容易就想到了。
这样似乎解决了问题，但是新的问题来了。生成静态后的页面，所有人看到的都是一样的，并且现在数据库的数据更新了，现在怎么办？这个时候，如果不想对系统进行大的变动的话，最好的办法是用一段js替换掉需要按用户显示不同的地方，至于数据更新后静态文件更新的方法，制定一套策略就可以了。当然，这样并没有解决所有问题，例如，现在网站的整体风格都需要改变，难道全部生成一遍吗？
前几年出了一个xml+xslt静态方案，可以解决网站风格变化问题。csdn的论坛改版（具体忘记哪年了），就使用过这种方案。这种方案是对html静态方案的发展。不过似乎效果并不是很理想，具体会遇到什么问题，贫道没用过，也说不清楚。==!
2、动态页面作载体的静态方案
这种方案是图1.1衍生品，把静态文件换成aspx文件。现在好了，可以解决更新风格、模板的问题了。因为生成的文件是aspx，就可以使用.net自带的模板解决方案了！当然，像某些部分需要显示用户相关数据的话，那没办法，还是得用js调用的方法。这个方案主要是用来解决统一风格网站更新风格问题的。
经过上面的处理，一台web加一台数据库也能承受一定压力的访问了。压力是多大？按我的经验是15分钟4000PV左右是可以支撑的，再多的话，例如8000，那就很有难度了。当然前提是你的网页中，或者说被主要访问的网页中不能有iframe。当然，还要受具体带宽多少，机器配置是否足够，用户操作是否分布均匀等因素影响。
二、缓存式方案
ASP.Net就提高了现成的页面缓存方案，用起来感觉还不错。这种页面缓存式方案本质上也是静态化处理，不过这部分静态内容是放到了内存中。由上篇文章讲到的内存与硬盘速度的状况，就可以想到这种方案，速度比静态化的快。这种方案也存在局部区域需要特定显示问题，可以用局部静态化，或者也可以用js调用的方式处理。这种方式也不是完美的，主要表现在，一旦缓存了很大的内存，当ASP.Net进程池回收时，IIS容易死掉。
于是乎，衍生出了进程外缓存。进程外缓存，是把缓存的数据放置到另外一个进程中，脱离了IIS。这种应用一般是windows service。本机的话可以用匿名管道，联网机器的话可以用Remoting、socket等方式与ASP.Net交换数据。这种方式效率没有放在IIS内部解决快，但是运行稳定是它的特点。最著名的应用就是MemCached。这种方式是缓存了数据而不是页面，数据在内存中，拿到ASP.Net页面进行数据绑定。这点是这种应用与前面三种最大的区别。
到了这里，该松一口气了，所有问题都让我们解决了。但是随着网站的发展，用户的增加，访问量不断加大，系统又遇到瓶颈了。