秋色园QBlog技术原理分析:序列终结篇:最后的AOP策略(十九)

开业闲话:

一点个月没写作品了,从七月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地图