开业闲话:

少数单月没写篇了,从9月15哀号发布新浪“微博粉丝精灵”V1.0后,持续的几乎单月都于磨它,现在犹折腾到V3.4本了。

据此,本篇迟来了三单月了,同时,本篇也是依照系列的终极一篇了,也是秋色园末尾杀手锏,霸气总该是要是发的。

 

上节回顾:

上节  秋色园QBlog技术原理分析:性能优化篇:读写分离与公事数据库(十八)

秋色园
[
QBlog](http://www.cyqdata.com/) 将部分大概频繁之数据,借用文本外储,来分减一些压力,从而为出现降温,保障网站的得手运转

 

本节大概:

文件外储,在一定程序及化解了问题,但是,由于这技术的懦弱,文本存储无法处理查询排序等题材,导致重心文章表明还在access黄金4K问题。

于压力之下,又如处理查询排序等复杂动作,于是苦冥三日,终得千篇一律招。

说到底的招数:Access与SQLite合体,最后之AOP策略。

 

本节情[AOP+数据库组合+策略分析+最终兑现]:

 

一:CYQ.Data
数据框架中的AOP思路简述

 

1:关于最初期CYQ.Data数框架实现AOP的思索文章,见:AOP
你想干什么 IOC
你服务啊

2:简单的再描述一下:

CYQ.Data数据框架通过以中装有数据库的操作方法中,内置2鲜单AOP方法,来实现方式的阻碍调整,简单的方法体如下:

public bool Fill(object where, params object[] aopInfo)
{
            _Aop.Begin(Aop.AopEnum.Fill,_TableName, aopInfo);//AOP开始时之阻
            bool result = 正常的方式体代码及操作结果

            _Aop.End(Aop.AopEnum.Fill, result, aopInfo);//AOP在措施了时更一个调用
            return result;
}

经如此的简练的阻碍,可以轻松的当数据库操作前,先处理事情,在数据库操作后,再处理工作。

详情代码可下载:CYQ.Data
V3.0
 免费开源版本。

 

二:QBlog数据库的决择

 

首先:秋色园主体数据库是Access,当然是看似每个表1独数据库,因此,是大抵独access数据库。

然后:秋色园再陪伴在“文本数据库”,来分压一些简读写的数目。

最后:决择是SQLite数据库,以分压用户的章压力(没事多体会下别数据库)。

眼下秋色园的内存情况是:VPS总体是512M内存。

秋色园QBlog占用200M以下内存。

微博粉丝精灵占用200M以下内存。

网默认支出也得占用200M左右。

剩余渣都无的残存了,连“爱说说”也因内存不足,暂时停掉了,当然不容许选用外大型数据库了。

 

老三:实际状况的设想

 

秋色园是一个多用户博客,而博客系统,每一个用户之数,基本上是并行独立的,简单的游说:多用户可化整为0,变成无数个单用户博客,然后多单单用户博客,组合起来,就改成多用户博客。

业已发出这样一种植考虑:

1:有那么一个数量挂靠平台,博客只要来相同客即可。

2:当自家来到另外平台交流时常,我只要选授权挂靠就哼了。

大凡勿是发出接触像微博?博客园发展吗多少平台,像51cto,csdn等,只要变成API开发者平台虽执行了,授权后数直接连通过去,也省的少数止发文章,是勿?

故此,如果叫自家再也设计一个初的博客系统,我也许会见设想[单]用户组装形式,这样方便数据独立[进展外挂、内接、或私有成独立单用户博客系统]。

思的粗多,回到正常的笔触上考虑:

冲“文本数据库”减压方案的延申,如果,把每个用户的文章独立分散,而每个用户之篇章以会随意的查询排序,最终之法力就是:否每个用户建一个sqlite数据库文件保留数据。

这样的话,等于每个用户发生一个1单独立数据库,因此,除了首页,其它访问都改成了单用户博客系统,基本上也就算不曾什么压力了。

 

思由这么想,总会带来有狐疑的:

1:数据库文件会无见面起最多?

实际上也不多,十万只文件未算是吗,按下日期、用户ID、哈唏、用户名等多种方式分布及不同文件夹下,一个文书夹也至不了有点只公文。再说,有10万用户若都过博客园了,估计起偷笑了。

2:聚合内容怎么收拾?如网站首页聚合多独用户的稿子显示?

本条从未啥,因为除去每个用户独立的数据库文件,还有总的access数据库,聚合时读access即可。

3:这么说多少化一式两份?

是对,是成稀卖了,不过当下政策,文章的内容(数据比较多)独立仅1卖,因此占有不了有点空间。

4:两个数据库,如何共同?同时写少卖?

写少卖是设,当然就未容许而写了,因为以写,对原本的access还是有多用户并发操作,具体看下面的详情。

5:这样系统未会见转移的很乱吧?

“最后的AOP策略”以插件的方法处理这种问题,一插入,搞定,一拔,还是好端端的,所以本着系统完全不影响。

 

季:最后之AOP策略的贯彻

 

1:创建新的类型,开始AOP切换项目。

出于AOP内置以反射调用DLL插件式注入,因此原有逻辑代码不改变,只要开始新的色处理即可。

图片 1

下一场配置文件配置一下系的调用即可,各家实现不同,仅供参考说明:

<add key=”Aop”
value=”Web.Aop,Web.Aop.AopAction”/>

2:为每个用户创建SQLite数据库

首要也老三步:

1:创建SQLite数据库;

2:创建文章表明结构;

3:将主表的旧的用户文章复制一份到新数据库去。

以下也代码节选:

图片 2

双重接下去,就是处理各种“增删改查”的数据库同步问题:

3:增加多少的拍卖流程:

先行押一个安插代码AOP的伪方法:

public bool Insert(params object[] aopInfo)
{
            _Aop.Begin(Aop.AopEnum.Insert,_TableName, aopInfo);//AOP开始时之阻挠,写SQLite数据库
            bool result = 正常的主意体代码及操作结果//
常规的写Access数据库
            _Aop.End(Aop.AopEnum.Insert, result, aopInfo);//AOP在艺术了时再也一个调用SQLite数据库
            return result;
 }

及时果按这老的AOP逻辑,将促成同种状态,写了SQLite数据后,同时还要拿继续写Access数据库,这肯定是出问题之,假而多单用户发布篇,虽然SQLite是形容在不同的数据库,可是以写主数据库Access,必然以出现并发4K问题。

否这,对于主Access,必须下新的法来促成,再借文本,定时插入:

实现原理:

A:当写了SQLite数据库后,将文章内容写成json输入到即文本中。

B:写了直接跨越了写Access数据库,直接回到。

C:定时器,定时从文本中遵循梯次执行插入或改动的情。

粗略的游说:把并发写Access数据库,变成队列式,1修连接1条之插,如此一来,并作写就迎刃而解了。

以适应这种转变,原有的AOP必须稍的精益求精,AOP.Begin方法要加返回值,以便作为标准,可以超越了下面的实施,为夫,增加了返回值的枚举:

    ///
<summary>
    /// Aop函数的处理结果
    /// </summary>
    public enum AopResult
    {
        /// <summary>
        /// 本结果将实施原事件,但超过了Aop.End事件
        /// </summary>
        Default,
        /// <summary>
        /// 本结果将继续执行原有事件以及Aop.End事件
        /// </summary>
        Continue,
        /// <summary>
        /// 本结果用跨越了原来事件,但会执行Aop End事件
        /// </summary>
        Break,
        /// <summary>
        /// 本结果以直接跳出原有函数的履
        /// </summary>
        Return,

产生矣回到值,插入后,跳了Access的插执行,返回成功即可。

参照代码:

图片 3

4:删除数据的处理流程:

当用户操作删除文章时,默认Begin不履,先走原来流程,删除主表,再从End事件删除SQLite表。

参照代码:

图片 4

5:修改数据的处理流程:

鉴于Access已改装成队列式执行,因此更新流程需于插入多了同样步而考虑的:

而:用户更新了A字段,这时队列还未曾更新上数据库,然后用户以创新了B字段。

这儿,只能有2独更新文件及行列中,后者B不可知一直复盖A,不然会促成A的改动丢失。

参照代码:

图片 5

6:数据的询问功能:

据悉标准判断,如果是单用户的数码,直接Begin方法查了SQLite后回去即可。

以身作则的查询代码:

图片 6

从那之后,整体的末梢之AOP策略处理就着力结束了。

 

总结

通过AOP策略,将用户博客变成单纯数据库查询,直接跨越了主数据库Access查询,基本消灭掉了Access被出现的机率,同时新的政策,将Access数据库的并发写,变更成队列式写,因此不再发生起锁库出现,对于急需综合数据查询的,仍然返回Access数据库查询综合数据,由于整是插件式操作,如果发生一天access升级换成其他数据库,不需SQLite配合时,只要注释配置文件代码用插件去丢,依旧是常规的运行,如果用户想单独出来做个域名,直接将sqlite数据库下载回去即可。

 

顶之,秋色园技术原理系列估计即使描写到此地了,本网的技艺内幕,基本也突显完了。

 

感网友对随系列的支持!!!

 

史篇章回顾:

1:
秋色园QBlog技术原理分析:开篇:整体认识(一)
–介绍完文件夹和文书之图

2:
秋色园QBlog技术原理分析:认识整站处理流程(二)
–介绍秋色园业务处理流程

3:
秋色园QBlog技术原理分析:UrlRewrite之无后缀URL原理(三)
–介绍如何促成无后缀URL

4:
秋色园QBlog技术原理分析:UrlRewrite之URL重定向体系(四)
–介绍URL如何稳定到处理程序

5:
秋色园QBlog技术原理分析:Module之页面基类设计(五)
–介绍创建基类和于定义生命周期

6: 秋色园QBlog技术原理分析:Module之页面基类-生命周期流程(六) –介绍基类生命周期内部业务

7:
秋色园QBlog技术原理分析:Module之基类生命周期-页面加载(七) –介绍界面html加载原理

8:
秋色园QBlog技术原理分析:Web之页面处理-内容填充(八)
–介绍html的始末是怎样填写

9:
秋色园QBlog技术原理分析:独创的多语言翻译机制(九) –介绍html多语言翻译原理

10:秋色园QBlog技术原理分析:页面内容填充及多语言翻译流程演示示例(十) –总结演示示例代码

11:秋色园QBlog技术原理分析:页面Post提交机制(十一) –介绍如果Post提交数据

12:秋色园QBlog技术原理分析:性能优化篇:字节与缓存与产出(十二) –介绍性优化:字节,并发及缓存

13:秋色园QBlog技术原理分析:性能优化篇:全局的SQL语句优化(十三)–介绍全局掌握SQL,进行针对优化

14
:秋色园QBlog技术原理分析:性能优化篇:缓存总起失效时,构造持续的缓存方案(十四) –介绍二糟缓存方案

15:秋色园QBlog技术原理分析:性能优化篇:数据库文章表分表及分库减压方案(十五) –介绍内容分库减压

16:秋色园QBlog技术原理分析:性能优化篇:access的出现极限和分库分散并发方案(十六) –介绍access并作上限定

17:秋色园QBlog技术原理分析:性能优化篇:用户与文章计数器方案(十七) –介绍用户与文章访问的计数优化方案

18:秋色园QBlog技术原理分析:性能优化篇:读写分离及公事数据库(十八)–介绍简单的文件分压策略

附章:

1:秋色园QBlog技术原理分析:博客一键安装工具技术实现[附源码下载] –开源秋色园安装工具原理

2:哪些设置配置秋色园CYQBlog站点

3:Windows7下蛋怎么设置配置秋色园CYQBlog站点

PS:秋色园QBlog下载地址:http://www.cyqdata.com/download/article-detail-427

 

相关文章

网站地图xml地图