[转]架构一个可承受千万级访问量的动态扩展CMS

作者: aries 分类: PHP 发布时间: 2013-11-01 09:22 ė 44334次浏览 6 0评论

目前CMS种类大致可分为两种,一种是通用CMS,还有一种是根据自身需求开发的私有CMS。 通用CMS比如dedecms、phpcms等CMS开源项目,适合技术实力不强的中小企业使用。 私有CMS,则结合自身需求,还定制开发的CMS,往往性能比通用型CMS要高。

开源通用型的CMS,虽然功能很强大,但是也有一些致命的缺点

  1. 静态页面管理. 当文章数据达到 百万级别的时候,生成静态页面的速度不仅慢,而且加重磁盘IO负载。容易让硬盘坏
  2. 不能实现页面片段缓存。 一般页面都会有几个公共片段,比如header和footer。 一般要更新公共片段的数据的时候,都会要全部生成静态页面。才能更新。
  3. 支持多站点的CMS,还需要配置FTP,利用FTP把静态页面发布到前端服务器上。这么做麻烦。

一般大型门户网站的CMS,都是靠CDN来加速的。 所以我设计的这款CMS架构是基于CDN模式来设计的,姑且把这款CMS叫做CDN-CMS。

先看一下服务器的架构图:

粗看这个服务器架构图很常见,没什么大不了。这个得结合CMS来看,就是另外一种感觉了。

先简单的说一下这个访问流程, 用户首先访问智能DNS SERVER。然后再由DNS把域名解析到相应的单线线路的Varnish 服务器上, Varnish 根据URL,看看有没有缓存该页面,没有就去数据中心,抓取一份数据,缓存起来。再返回给用户。

CDN-CMS主要还是用PHP来开发,但是抛弃了PHP自身的一些功能。比如上传、session等功能。 和 Nginx、Varnish进行紧密的结合起来。还有使用了leveldb来进行 文章表的储存,就不用那么麻烦分表。 下面说一下CMS的特性

  1. CMS本身不生成静态页,前端显示的页面由Varnish 来接管,Varnish使用内存来cache页面。避免磁盘IO的负载。刷新页面数据,用正则的语法发送给Varnish就行。 CMS避免了繁琐的静态页面生成,静态页面更新等问题。
  2. 后端使用 nginx upload module,前端使用swfupload,轻松实现几百M的打文件上次,比PHP自身的上传效率的多。
  3. 使用自己的session module, 把session数据 存储到Redis上(单机版存储到Xcache)。实现多服务器session 共享
  4. CMS framework采用简单的MVC模式, 在第一次运行的时候,Init.php会把经常使用的class文件打包成一个php文件,避免include IO开支。 需要的数据从mysql加载到内存里。
  5. 基于内存的 用户权限控制系统。
  6. 全文检索采用 XunSearch,,xunsearch相对Sphinx,对使用者更简单方便,简单的配置,完善的API。
  7. 文章article表,使用google开源的LevelDB来存储。LevelDB是一款Key-Value数据引擎。能轻松存储上亿条数据,数据插入、更新很具有效率。 article表的分页显示,搜索。均使用xunsearch来find出相应ID,再从leveldb get出相应数据。

总结:目前这套CMS系统,已经稳定的在色影无忌 www.xitek.com 网站上运行。每天承受几百万的访问量。 目前正在开发QuickDB。这套存储引擎基于LevelDB。加上btree索引。能够实现简单的SQL多条件查询、排序、Limit。实现一个单机版的MongoDB。 Leveldb的各方面效率都比TokyoCabinet好。在千万级数据 查询和插入 ,速度还是杠杠的。TokyoCabinet就慢的不行了

相关链接

XunSearch http://www.xunsearch.com/

LevelDB入门教材 http://www.slideshare.net/sunzhidong/google-leveldb-study-discuss

varnish ESI http://www.varnish-cache.org/wiki/ESIfeatures

作者Blog : http://www.cellphp.com/

0 cms
换一个
暂无评论
Ɣ回顶部