架构一个可承受千万级访问量的动态扩展CMS
2014-05-05 21:34
429 查看
目前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/
私有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/
相关文章推荐
- 【WEB静态页面架构经典】架构一个可承受千万级访问量的动态扩展CMS
- MySQL千万级访问量架构
- MySQL千万级访问量架构(转)
- YII千万级PV架构经验分享--俯瞰篇--YII扩展演变(2)
- Python 中的线性优化,第 2 部分: 在云中构建一个可扩展的基础架构
- 采用什么架构,才能够承受大访问量
- 看到人问CSDN的采用了什么架构,能够承受这么多访问,就回复了个,这里把自己的的经验也发下,算是给。NET新手一个帮助
- ActiveRecord 访问 同架构动态表 例如多表 表名 按日期 扩展
- 网站动态属性的一个架构
- .NET : 如何动态根据一个业务实体类型创建XSD架构文件
- YII千万级PV架构经验分享--俯瞰篇--业务扩展演变(3)
- .NET : 如何动态根据一个业务实体类型创建XSD架构文件
- 采用什么架构,才能够承受大访问量(引)
- C#中动态扩展一个新类型的实现
- 采用什么架构,才能够承受大访问量
- Atitit.一个cms有多少少扩展点,多少api wordpress cms有多少api。。扩展点
- [心得]高并发访问量下采用SOA架构异步交互的解决方案 - 纪念一个项目
- 用 consul + consul-template + registrator + nginx 打造真正可动态扩展的服务架构
- EF架构~扩展一个分页处理大数据的方法
- 动态属性的一个架构