首页 > 科技数据 > 架构一个可承受千万级访问量的动态扩展CMS
2018
08-20

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

千淘万漉博客阿里云大使推广链接

 

目前CMS种类大致可分为两种,一种是通用CMS,还有一种是根据自身需求开发的私有CMS。 通用CMS比如dedecmsphpcms等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 条评论

留下一个回复