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

2年前 (2022) 程序员胖胖胖虎阿
195 0 0

开篇闲话:

好几个月没写文章了,从9月15号发布新浪“微博粉丝精灵”V1.0后,持续的几个月都在折腾它,现在都折腾到V3.4版本了。

因此,本篇迟来了三个月了,同时,本篇也是本系列的最后一篇了,也是秋色园最后杀手锏,霸气总该是要外露的。

 
上节回顾:

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

秋色园 QBlog 将一些简单频繁的数据,借用文本外储,来分减一些压力,从而为并发降温,保障网站的顺利运行

 

本节概要:

文本外储,在一定程序上解决了问题,但是,由于当时技术的薄弱,文本存储无法处理查询排序等问题,导致主体文章表依旧存在access黄金4K问题。

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

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

 

本节内容[AOP+数据库组合+策略分析+最终实现]:

 

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

 

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

2:简单的再描述一下:

CYQ.Data数据框架通过在内部所有数据库的操作方法中,内置2两个AOP方法,来实现方法的拦截调整,简单的方法体如下:

public bool Fill(object whereparams 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插件式注入,因此原有逻辑代码不改变,只要开新的项目处理即可。

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

然后配置文件配置一下相关的调用即可,各家实现不一,仅供参考说明:

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

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

主要为三步:

1:创建SQLite数据库;

2:创建文章表结构;

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

以下为代码节选:

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

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

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的插入执行,返回成功即可。

参考代码:

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

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

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

参考代码:

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

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

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

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

这时候,只能产生2个更新文件到队列中,后者B不能直接复盖A,不然会造成A的修改丢失。

参考代码:

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

6:数据的查询功能:

根据条件判断,如果是单用户的数据,直接Begin方法查完SQLite后返回即可。

示例的查询代码:

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

至此,整体的最后的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

 

相关文章

暂无评论

暂无评论...