[转]架构一个可承受千万级访问量的动态扩展CMS
目前CMS种类大致可分为两种，一种是通用CMS，还有一种是根据自身需求开发的私有CMS。 通用CMS比如dedecms、phpcms等CMS开源项目，适合技术实力不强的中小企业使用。 私有CMS，则结合自身需求，还定制开发的CMS,往往性能比通用型CMS要高。
开源通用型的CMS,虽然功能很强大，但是也有一些致命的缺点
- 静态页面管理. 当文章数据达到 百万级别的时候，生成静态页面的速度不仅慢，而且加重磁盘IO负载。容易让硬盘坏
- 不能实现页面片段缓存。 一般页面都会有几个公共片段，比如header和footer。 一般要更新公共片段的数据的时候，都会要全部生成静态页面。才能更新。
- 支持多站点的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的特性
- CMS本身不生成静态页，前端显示的页面由Varnish 来接管，Varnish使用内存来cache页面。避免磁盘IO的负载。刷新页面数据，用正则的语法发送给Varnish就行。 CMS避免了繁琐的静态页面生成，静态页面更新等问题。
- 后端使用 nginx upload module，前端使用swfupload，轻松实现几百M的打文件上次，比PHP自身的上传效率的多。
- 使用自己的session module, 把session数据 存储到Redis上(单机版存储到Xcache)。实现多服务器session 共享
- CMS framework采用简单的MVC模式, 在第一次运行的时候，Init.php会把经常使用的class文件打包成一个php文件，避免include IO开支。 需要的数据从mysql加载到内存里。
- 基于内存的 用户权限控制系统。
- 全文检索采用 XunSearch,，xunsearch相对Sphinx,对使用者更简单方便，简单的配置，完善的API。
- 文章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/