多级智能缓存(静态化)机制

缓存系统的设计,直接决定了系统的运行效能。就像我们下了一个订单,送货方如果从悉 尼发货和同其在上海的仓库发货相比,速度完全是两个等级。缓存的设计就在于一个“就近原 则”。将数据靠近使用者。

ECOS的前端站点组件site, 对缓存有着极为精细的把控,完全发挥现代浏览器和HTTP协 议的性能。

ECOS的site有3层缓存结构,按顺序触发:

层次	缓存名称	存放位置
1	基于http协议的浏览器缓存	用户浏览器本地
2	前台全页缓存	kvcache
3	末班缓存	kvstore

基于http协议的浏览器缓存

现代浏览器都很聪明,他们尽量不会把同样的数据从网上下载两次。但是只有同样聪明的服务器程序才能给予配合。

如果用户访问过这个网站,那么ECOS-site会在系统的header头里放一个Etag标签。 这个Etag数据是和页面的内容相关的,如果页面内容变了,Etag也会不同。

这个过程被写在RFC2616文档中:

http://tools.ietf.org/html/rfc2616 ECOS-site有一个完整的实现 , 流程如下:

而 ECOS-Site 有一个完整的实现, 流程如下图所示:

服务器端缓存设计

现在聚焦到上图中"生成页面内容..."这个环节中, 此时系统并不是为每次生成页面内容的 请求都重新运行一次, 而是将页面的结果整体缓存下来,如果该页面所包含的数据都没有更新, 则是直接输出被缓存下来的内容。

ECOS-site在数据库的操作底层设置了一个触发动作,当有任何表的更新,插入,删除操 作时,将当时的时间和被操作的表明记录在一个特殊的表里: sdb_cachemgr。例如某时刻该表 的数据如下:

表名	最后时间
sdb_goods	2009-11-21 16:20:26
sdb_goods_cat	2009-11-20  05:25:21
sdb_setting	2009- 11-23 19:40:13
sdb_member	2009-11-23 08:36:23
sdb_order	2009-11-22 20:46:20
sdb_payments	2009-11-24 05:20:27
...	...

实际上,真实系统里表的时间都是unix时间戳格式,那个数字的意思是1970-01-01 00:00:00之后 的秒数。在这里,为了方便理解,我们在此用实际时间表示。

在处理前台请求时,数据库底层会记录在这个过程中用到的数据表,包括页面挂件,流程 插件,自动机器人,模块,以及各种子流程。 同时会记录用到的修改时间,存到最终生成的缓存 条目头部。

假设过了5分钟,又有人访问同样的网址,系统发现存在针对这个url的缓存。 此时会读出 这个缓存条目用到的表名列表: sdb_goods,sdb_goods_cat,sdb_setting 并到 sdb_cachemgr中检查这些表当前的状态,如果发现有以上表里有任何一个在上次缓存保存之后 被修改过了,则宣布该缓存作废, 重新生成页面。

而这个过程是在core/include/cachemgr这个类 管理的。