开篇闲话:

好多少个月没写小说了,从四月一五号发表今日头条“果壳网听众Smart”V一.0后,持续的多少个月都在折磨它,现在都折腾到V3.肆本子了。

故此,本篇迟来了三个月了,同时,本篇也是本类别的末尾一篇了,也是秋色园最后杀手锏,霸气总该是要流露的。

 

上节回首:

上节  秋色园QBlog技术原理分析:品质优化篇:读写分离与公事数据库(拾捌)

秋色园
[
QBlog](http://www.cyqdata.com/) 将一些简短频仍的数据,借用文本外储,来分减1些压力,从而为出现降温,保险网址的风调雨顺运转

 

本节差不离:

文本外储,在早晚程序上消除了难点,可是,由于当时技能的软弱,文本存款和储蓄不可能处理查询排序等题材,导致重心文章表依旧存在access黄金4K标题。

在压力之下,又要处理查询排序等复杂动作,于是苦冥30日,终得壹招。

终极的招数:Access与SQLite合体,最后的AOP策略。

 

本节内容[AOP+数据库组合+策略分析+末了达成]:

 

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

 

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

贰:不难的再描述一下:

CYQ.Data数据框架通过在其间有着数据库的操作方法中,内置二八个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在点子甘休时再1个调用
            return result;
}

由此如此的简易的阻挠,能够轻松的在数据库操作前,先拍卖工作,在数据库操作后,再处理业务。

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

 

二:QBlog数据库的决择

 

率先:秋色园主体数据库是Access,当然是类似每种表2个数据库,由此,是多少个access数据库。

接下来:秋色园再陪伴着“文本数据库”,来分压一些简练读写的数额。

谈起底:决择是SQLite数据库,以分压用户的文章压力(没事多体会下其余数据库)。

近来秋色园的内部存储器情状是:VPS总体是51二M内部存款和储蓄器。

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

乐乎观众Smart占用200M以下内部存款和储蓄器。

系统暗许支出也得占用200M左右。

剩下渣都没的剩了,连“爱说说”也因内部存储器不足,一时停掉了,当然不容许采纳别的大型数据库了。

 

3:实际境况的设想

 

秋色园是3个多用户博客,而博客系统,各类用户的数码,基本上是相互独立的,简单来讲:多用户可以化整为0,变成无数个单用户博客,然后众多少个单用户博客,组合起来,就变成多用户博客。

曾经有如此一种怀想:

一:有那么1个数额挂靠平台,博客只要有一份即可。

二:当本人来到其它平台沟通时,笔者只要选拔授权挂靠就好了。

是或不是有点像今日头条?和讯发展为数量平台,像51cto,csdn等,只要变成API开发者平台就行了,授权后数据直接对接过去,也省的两边发小说,是不?

故此,即使让本身再度规划三个新的博客系统,小编或者会思考[单]用户组装情势,那样便于数据独立[进展外挂、内接、或私有成独立单用户博客系统]。

想的多少多,回到平常的思路上考虑:

传说“文本数据库”减压方案的延申,即便,把各种用户的稿子独立分散,而各样用户的文章又能自由的查询排序,最后的功能便是:为每个用户建四个sqlite数据库文件保留数据。

那样的话,等于各类用户发生二个3个独立数据库,由此,除了首页,其余访问都改为了单用户博客系统,基本上也就没怎么压力了。

 

想归这么想,总会拉动1些狐疑的:

一:数据库文件会不会发生太多?

实质上也不多,八万个文件不算吗,按下日期、用户ID、哈唏、用户名等多样主意分布到不一致文件夹下,三个文件夹也顶不住多少个文件。再说,有70000用户你都超越微博了,猜想起头偷笑了。

二:聚合内容如何做?如网址首页聚合八个用户的作品呈现?

以此没啥,因为除开每一种用户独立的数据库文件,还有总的access数据库,聚合时读access即可。

3:这么说数目变成1式两份?

其一正确,是成两份了,可是当下方针,作品的始末(数据相比较多)独立仅一份,因而占不了多少空间。

4:多个数据库,怎么样同步?同时写两份?

写两份是要,当然就不恐怕还要写了,因为与此同时写,对本来的access照旧存在多用户并发操作,具体看上面包车型大巴详情。

五:那样系统不会变的很乱吧?

“最后的AOP策略”以插件的方法处理那种题材,1插,化解,一拔,照旧如常的,所以对系统完全不影响。

 

四:最后的AOP策略的兑现

 

一:创立新的种类,开头AOP切换项目。

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

json 1

然后配置文件配置一下辅车相依的调用即可,各家达成分化,仅供参考表明:

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

2:为各样用户创立SQLite数据库

驷不比舌为三步:

1:创建SQLite数据库;

贰:创造作品表结构;

三:将主表的本来面指标用户小说复制一份到新数据库去。

以下为代码节选:

json 2

再接下去,正是处理各样“增加和删除改查”的数据库同步难点:

三:扩充数量的拍卖流程:

先看1个插入代码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逻辑,将导致1种景况,写完SQLite数据后,同时又将一连写Access数据库,那显明是有题指标,倘若四个用户公布文章,即使SQLite是写在不一样的数据库,但是还要写主数据库Access,必然又出现并发4K难点。

为此,对于主Access,必须采用新的诀要来达成,再借文本,定时插入:

贯彻原理:

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

B:写完直接跳过写Access数据库,直接重返。

C:定时器,定时从文本中按梯次执行插入或修改的内容。

简单来说:把并发写Access数据库,变成队列式,壹条接壹条的插入,如此一来,并发写就消除了。

为了适应那种转变,原有的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的插入执行,重临成功即可。

参照代码:

json 3

四:删除数据的拍卖流程:

当用户操作删除小说时,暗中同意Begin不执行,先走原来流程,删除主表,再从End事件删除SQLite表。

参考代码:

json 4

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

出于Access已改装成队列式执行,因而更新流程需比插入多了一步要思虑的:

如:用户更新了A字段,这时队列还没更新进数据库,然后用户又立异了B字段。

此刻,只可以发出2个更新文件到行列中,后者B无法一向复盖A,不然会促成A的修改丢失。

参照代码:

json 5

陆:数据的查询功效:

根据规则判断,假诺是单用户的数量,直接Begin方法查完SQLite后回来即可。

以身作则的询问代码:

json 6

迄今停止,全体的尾声的AOP策略处理就着力停止了。

 

总结

透过AOP策略,将用户博客变成单数据库查询,直接跳过主数据库Access查询,基本灭掉了Access被出现的机率,同时新的策略,将Access数据库的并发写,变更成队列式写,由此不再有出现锁库出现,对于急需综合数据查询的,依旧再次回到Access数据库查询综合数据,由于全部是插件式操作,假若有1天access升级换到此外数据库,不供给SQLite合营时,只要注释配置文件代码将插件去掉,还是是常规的运营,要是用户想单独出来弄个域名,直接把sqlite数据库下载回去即可。

 

到此,秋色园技术原理类别推测就写到那里了,本系统的技术内幕,基本也暴露完了。

 

多谢网上好友对本体系的支撑!!!

 

正史篇章回想:

1:
秋色园QBlog技术原理分析:开篇:全体会认识识(壹)
–介绍全部文件夹和文书的机能

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

3:
秋色园QBlog技术原理分析:UrlRewrite之无后缀UXC60L原理(3)
–介绍怎样促成无后缀UEscortL

4:
秋色园QBlog技术原理分析:UrlRewrite之ULANDL重定向类别(4)
–介绍UEscortL如何定位各处理程序

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

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

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

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

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

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

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

12:秋色园QBlog技术原理分析:品质优化篇:字节与缓存与出新(⑩二) –介绍品质优化:字节,并发及缓存

13:秋色园QBlog技术原理分析:质量优化篇:全局的SQL语句优化(十叁)–介绍全局精通SQL,举办针对优化

14
秋色园QBlog技术原理分析:品质优化篇:缓存总有失效时,构造持续的缓存方案(104) –介绍二遍缓存方案

15:秋色园QBlog技术原理分析:品质优化篇:数据库小说表分表及分库减压方案(拾5) –介绍内容分库减压

16:秋色园QBlog技术原理分析:品质优化篇:access的出现极限及分库分散并发方案(十陆) –介绍access并发上限

17:秋色园QBlog技术原理分析:品质优化篇:用户和小说计数器方案(十7) –介绍用户和小说访问的计数优化方案

18:秋色园QBlog技术原理分析:品质优化篇:读写分离与公事数据库(拾8)–介绍简单的文本分压策略

附章:

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

2:什么设置配备秋色园CYQBlog站点

3:Windows七下何以设置配备秋色园CYQBlog站点

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

 

相关文章

网站地图xml地图