使用XML缓存减低数据库的读取次数和服务器压力

saturn

spt119 发表于 2011-7-26 12:18
回楼上：
之所以设计成XML，而不是文本形式的序列化数组，主要目的是兼顾AJAX在前端的操作。否则数据库的读 ...

从你这个角度来看，也有道理；那么为什么不用Json？

另外，XSLT嵌入你说的统计之类的脚本（如果我理解没错的话），实际上普通模式开发没有区别的，只是设计思路不同（这个我有实际开发经验）。

实际上，XSLT的最大问题和CSS/JS兼容性问题是一样的。由于是在客户端进行DOM转换，不同的浏览器所支持的XML解析引擎也不同（比如IE系列），所以可能会导致一些兼容性问题。而这种兼容性破坏所导致的结果是严重的，那就是页面直接显示不了。

具体的例子也是有的，原来的暴雪官方和国内的射手网（老版本）都是采用这种模式，不过现在都回到普通开发阵营。

各有优劣。再次支持spt119的探索精神，呵呵。

spt119

感谢楼上谬赞！
JSON方式有编码兼容的问题，GBK与UTF-8之间的转换需要大量的iconv操作，代码变得庞杂不说，而且iconv本身的内存消耗也不小。
正如楼上所言，因为浏览器领域的差异化，把软件的最终表现（HTML及AJAX）全部交给客户端浏览器，是需要承担很大风险的。本文的XML缓存的基本目的，就是把客户端的工作细化。
如果以“原因-->结果”的模式来概括客户端在程序运行的参与程度（因为需要很多的统计操作），这种缓存的设计模式则是把“原因”部分甩给客户端浏览器，杜绝客户端浏览器参与任何“结果”操作。
另外，DOM也是需要考虑的问题之一，因为JS和XML都可以操作DOM。

BruceWolf

首先，要赞扬楼主“按需缓存，主动更新”的缓存思想。缓存是为了提高数据的获取性能，既然是缓存，就会以数据的实效性为代价，可能造成数据失真，缓存适用于楼主说的大前提，变更较少的数据，不然更新过于频繁、生成缓存的成本过高或者更新太慢、数据实效性大打折扣的话缓存就没有意义了。主动更新，可以较好的控制缓存生成成本、保障数据的实效性。

不过 xml 格式的文本文件并不适合做底层数据的数据缓存，从以下几点说明：
1. 就单个的平文本格式而言，并不适用于大规模的结构数据的管理，除非是不用删、改的 log 数据。或者本身就没几条数据记录。楼主说不是缓存整个数据库，但是缓存的是整张表，表的数据量是多少？这是一个需要面对的问题，如果只是缓存 category 表，目前来说，可以。
2. 楼主说采用 xml 的目的之一是对前端的兼容，作为底层数据存储，即使只是缓存层，过多的考虑对浏览器端的兼容没有多大意义，除非是 HTML 缓存，不然数据就要交给浏览去再加工。一味的将数据处理留在服务器端没有必要，C/S 构架其实就是为了避免所有工作都丢给服务器，让客户端和服务器端各司其职。
3. 至于转码问题，xml 也规避不了，就不能当作优势了。并不是因为你写了编码标签就不出现乱码，如果你用 ANSI 编码存储了中文文本，加上了这个标签一样是乱码。说这个是优势是因为你忽略了自己已经使用 utf8 编码来存储数据这个事实。
4. 效率方面真心不行，不如 json，更不如 include php array。

xml 是一种能简便在以文本文件的形式的实现结构化数据的方案，自然人也能编辑，却是一种重数据结构，只适用于小量的结构化数据，效率低也是业界公认的。但 xml 有其自己的用途，xml 大规模的用于数据传输和配置文件，不过在数据传输方面浏览器与服务器间的数据交互形式正在慢慢向效率更高的 json 转移，服务器和服务器之间的数据交互则向二进制数据形式转移，facebook 和 google 都有相关的开源产品。

楼主的思想很好，下一步产生的解决方案会更适合产业环境。

lampcool

为啥子不用memcached?考虑站长的环境吗?

lou0011

{:soso__17244907116850545055_3:}{:soso__17244907116850545055_3:}

幽蓝冰魄

值得借鉴，我开始的设想是用 js 来载入的。等待权衡。

saturn

话题扯的有些远了，我来总结一下吧。

spt119所提出方案的核心价值是：

将本来“同步”提取数据库的操作，先“异步”的通过xml保存起来，然后“按需”提取和显示。这是我认为该方案的最大价值和思想所在。

狼大大所补充方案的核心价值是：

在大型项目上，spt119所提出的方案可能需要商榷，或者说需要根据实际情况进行调整。

我认为：
1. 如果一定将话题上升到“缓存”这个高度，那么肯定需要遵从“离CPU越近，速度越快”的准则。所以，无论是xml/json/文本，只要他们保存在硬盘上，我想它们都是一个数量级的（benchmark肯定比不了将数据放在内存中），因为有磁盘I/O做限制。
2. xml和json这类标准的最大优势在于数据交换和友好化数据存储，它们经常被充当不同语言间或者平台间的黏合剂（glue）。在这里，我们将它作为缓存的一种存在形式当然没有问题，而且我在上面提到了另一个妙用（xslt + xml）。
3. 技术之间没有优劣，任何技术的存在都有它的必然性。

希望以后能有同类优秀的帖子出现。

BruceWolf

saturn 发表于 2011-8-2 15:02
话题扯的有些远了，我来总结一下吧。

spt119所提出方案的核心价值是：

确实是“离CPU越近，速度越快”，I/O 性能确实会影响程序效率，但是不意味着相同的 I/O 机制效率就是一样，不然也有“优化”这个词的出现。大型项目的开发中，性能优化的开发成本不低于功能的开发成本。
程序的效率不仅仅是看 I/O 性能，相同硬件前提下，程序性能产生数量级的差别是正常的，产生这个差别不是说自己代码能写多好，很大程度取决于自己代码有多糟。另外，即使不是数量级的性能提升，再榨干硬件性能时提升一倍就意味着省下一半的硬件支出以及局域网络的扩容成本，此时效优化自己的解决方案很有必要。而对于程序员而言，能否习惯性的设计高效的程序，不仅仅是成本问题，更是能力的表现。
技术之间无优劣，因为它是死的，程序员提出的解决方案会有优劣，或者说会有更适合某个场景的解决方案。黑格尔的原话是这样的：“存在即合理，凡是合乎理性的东西都是现实的，凡是现实的东西都是合乎理性的。”xml 的存在是合理的，仅当它存于合乎理性的地方，否则就不是黑格尔所说的“存在即合理”了。所以合适的时候用合适的技术是才是“合理”的。

chf007

个人也认为存成JSON更好些

yunnysunny

一般大家做应用前端、后端都是用同一种编码吧，如果用两种编码，岂不是自找麻烦。楼主说的json有可能需要gbk和utf-8之间进行转码，这是什么个情况呢？难道前端的数据不是自己的应用发送过来的？
不就是生成个category嘛，我认为做缓存的时候，既不用xml，也不用json，用php做缓存是最简单高效的方法。首先你查询数据库，然后将查询的数据写入一个php文件，假设叫catetory.php,里面就保存一个数组。

PHP复制代码

 
$catetory = array(
    array('id' => 1,
          'title'=>'主分类1',
          'children' => array(
                array('id'=>2,'title'=>'子分类11'),
                array('id'=>3,'title'=>'子分类12')
           )
    ),
    array('id'=>4,'title'=>'大分类2')
);
 

复制代码

你每次修改了分类的数据库，就重新生成这个catetory.php，你每次想在页面上更新分类的界面的时候。你可以解析这个数据，生成html返回给界面，也可以将数组转化为json，让js来生成html。
我认为可以使用xml的场合：第一种，你要和其他的语言进行交互，要给这门语言发送复杂数据，但是这门语言默认只支持xml形式，例如actionscript，它的api中是不支持json的（虽然你可以通过第三方json类库来获得支持），这种情况下当然要首选xml。第二种，你的系统足够复杂，复杂到你的系统要接入各种应用，而且你跟这些应用间传递的数据信息的结构来比较复杂，这种情况下推荐使用xml，因为xml的可读性好，你在调试的时候可以直接在浏览器中看到交互的xml信息。而且这些应用是有可能是跨平台的，xml在不同平台间的支持程度要好于json。