秋色园QBlog技术原理解析：性能优化篇：缓存总有失效时，构造持续的缓存方案(十四)
转载自：http://www.cyqdata.com/qblog/article-detail-38993
文章回顾：
1： 秋色园QBlog技术原理解析：开篇：整体认识(一) --介绍整体文件夹和文件的作用
2： 秋色园QBlog技术原理解析：认识整站处理流程(二) --介绍秋色园业务处理流程
3： 秋色园QBlog技术原理解析：UrlRewrite之无后缀URL原理(三) --介绍如何实现无后缀URL
4： 秋色园QBlog技术原理解析：UrlRewrite之URL重定向体系(四) --介绍URL如何定位到处理程序
5： 秋色园QBlog技术原理解析：Module之页面基类设计(五) --介绍创建基类和自定义生命周期
6： 秋色园QBlog技术原理解析：Module之页面基类-生命周期流程(六) --介绍基类生命周期内部业务
7： 秋色园QBlog技术原理解析：Module之基类生命周期-页面加载(七) --介绍界面html加载原理
8： 秋色园QBlog技术原理解析：Web之页面处理-内容填充(八) --介绍html的内容是如何填充
9： 秋色园QBlog技术原理解析：独创的多语言翻译机制(九) --介绍html多语言翻译原理
10：秋色园QBlog技术原理解析：页面内容填充及多语言翻译流程演示示例(十) --总结演示示例代码
11：秋色园QBlog技术原理解析：页面Post提交机制(十一) --介绍如果Post提交数据
12：秋色园QBlog技术原理解析：性能优化篇：字节与缓存与并发(十二) --介绍性能优化：字节，并发及缓存
13：秋色园QBlog技术原理解析：性能优化篇：全局的SQL语句优化(十三) --介绍全局掌握SQL，进行针对性优化
附章：
1：秋色园QBlog技术原理解析：博客一键安装工具技术实现[附源码下载] --开源秋色园安装工具原理
PS：秋色园QBlog下载地址：http://www.cyqdata.com/download/article-detail-427
上[2]节回顾：
上两节中，介绍了 秋色园QBlog 在性能优化方面所做的基础工作：
减少字节输出大小、写并发控制、缓存控制等。
特别是对缓存的处理，做到全局把握，优化内存资源，合理调优化。
CYQ.Data 在性能调优方面表现出一定的优势。
同时又介绍了另一种优化方案：通过打印页面SQL，捕捉耗时语句长的进行针对性优化。
本节介绍：
秋色园 QBlog 一直用Access，目前已超过600M的大小：
曾经尝试更换数据库：如：2011年03月14日---随说秋色园QBlog从Access升迁到MSSQL过程，不过最后还是没换成，原因文中有说到，就不重复了。
前不久买了个VPS，把秋色园搬到赌城“拉斯维加斯”，同时也进行了多种数据库测试，先后跑了下：Access/mssql2000/2005/oracle/mysql/sqlite，等 CYQ.Data 数据框架 支持的数据库。
借助 CYQ.Data 数据框架 对一些不同数据库差异性函数和方法做了多数据库解析，秋色园无需修改代码仅靠切换数据库链接，就轻松转移数据库顺利跑完，这个以后再介绍。
虽然各种数据库都能跑，但目前还是没有更换数据库，持续的跑access：
为了Access 10万文章的坚持，也是为了最大化的优化程序。
其实，最重要的原因，是VPS的512M的内存，经不起大数据的折腾。
Access其实速度并不快：
当Access上到单表几万的数据之后，单从查询想要快，很难。
基本速度为大约3秒左右执行完一个秋色园 QBlog 首页，分页，会慢一些5秒左右。
提速靠程序优化：
缓存失效背后的方案：
方案一：
产生后补缓存：接替快要失效的缓存，保持持续的缓存，同时保障页面的及时更新。
说明：
不过只是简单的考虑了一下，并没有深入去研究和实现这种方案。
实现是肯定可以的，需要点技术手段，大伙多想想。
不足处：
对于应用程序池内存回收时，会整体缓存失效，后补自然也失效，此时还会产生空白期。
所以，后来考虑了另一种方案。
方案二：
生成静态页面：临时接替失效的缓存，同时再产生新的缓存。
说明：
如此一来，静态页面当了临时缓冲，这样就可以持续的保持高速的访问机制。
同时也可以避开内存回收的空白期，这是秋色园目前采用的方案。
不足处：
比较难以控制新页面的产生，实时性不强。
所以后面又想了很多招，来跳过静态页面的加载。
静态化的技术手段与难点：
1：如何生成静态页面？批量？后台程序？No...
2：静态页面如何呈现？直接访问xxx.html？No...
3：如何保障页面的更新？定时批量更新？No...
4：静态化甘愿做缓存的后补？不好说，说不好，不说好......
静态化技术解析：
一：如何生成静态页面
1：写个后台程序，点下按钮，批量生成？
以前做电子商务的时候，就是这么处理的。
因为产品基本信息不怎么变，而且编辑人员就那么几个，重新编辑时就再生成一次html。
不过秋色园不是这种方式，也不太适用。
2：第一次受访问时，生成HTML
秋色园目前采用这种方式，因为将HTML当Xml方式的加载方式，要生成静态页面，太简单。
只要在页面结束输出之前，将Xml的InnerXml保存到指定路径就可以了。
于是问题就简化成如何指定保存路径了。
二：静态页面如何呈现
想象一下，当访问：http://www.cyqdata.com/qblog/article-detail-37431 的时候，
第一接手的：URLRewrite，它需要解析完URL，然后决定跳转路径。
跳转有两条路：
1：增加一种逻辑，判断是否已生成html，根据条件跳转到静态化的html进行访问。
不过秋色园没有采用这种方式。
2：将HTML当成缓存，直接读取并加载，然后继续后面的页面生命流程
基本逻辑如下：
if ( 尝试读取缓存) { 从缓存返回Document }
else if ( 尝试读取html){加载html返回Document ，并概率性线程，请求更新数据，同时产生新缓存}
else {原始的加载方式，依旧读取数据库，同时生成HTML页面}
三：如何保障页面的更新
1：原始的加载方式，上面的最后的 else 事件中，会生成HTML。
2：上面的 else if 事件中，有概率性事件请求，对于概率性事件，仍旧请求当前页面。
不过需要加标识，让它直接定位到最后的 else 事件，这样就可以产生新的更新页面了。
PS：
首页比如缓存3分钟，失效时，进入 else if 事件中读取html，同时产生概率性事件，
如果第一次就中了，加上再次产生的新缓存3分钟，则实际6分钟更新一次数据呈现。
四：平衡静态化与缓存的功效
基本一个页面就100K，512M能缓存多少文章呢？还有系统其它N种开销，能省就省了。
因此不能大面积的使用缓存，因此需要平衡使用，将静态化提升到一个重要位置使用。
目前秋色园的基本策略是：
1：首页：开启缓存+HTML
2：用户首页：开启缓存，关闭HTML
3：用户文章：关闭缓存，开启HTML
4：用户图片：关闭缓存，关闭HTML，少人用啊。
5：文章分类：开启缓存，关闭HTML
总结：
本节介绍了秋色园QBlog 实际中保持访问速度的策略，下节继续介绍优化策略的再后续部分，敬请关注。
