开篇闲话:
好几个月没写文章了,从9月15号发布新浪“微博粉丝精灵”V1.0后,持续的几个月都在折腾它,现在都折腾到V3.4版本了。
因此,本篇迟来了三个月了,同时,本篇也是本系列的最后一篇了,也是秋色园最后杀手锏,霸气总该是要外露的。
上节回顾:
秋色园 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 where, params object[] aopInfo)
{
_Aop.Begin(Aop.AopEnum.Fill,_TableName, aopInfo);//AOP开始时的拦截
bool result = 正常的方法体代码及操作结果
_Aop.End(Aop.AopEnum.Fill, result, aopInfo);//AOP在方法结束时再一个调用
return result;
}
{
_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插件式注入,因此原有逻辑代码不改变,只要开新的项目处理即可。
然后配置文件配置一下相关的调用即可,各家实现不一,仅供参考说明:
<add key="Aop" value="Web.Aop,Web.Aop.AopAction"/>
2:为每个用户创建SQLite数据库
主要为三步:
1:创建SQLite数据库;
2:创建文章表结构;
3:将主表的原有的用户文章复制一份到新数据库去。
以下为代码节选:
再接下来,就是处理各种“增删改查”的数据库同步问题:
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.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,
/// Aop函数的处理结果
/// </summary>
public enum AopResult
{
/// <summary>
/// 本结果将执行原有事件,但跳过Aop.End事件
/// </summary>
Default,
/// <summary>
/// 本结果将继续执行原有事件和Aop.End事件
/// </summary>
Continue,
/// <summary>
/// 本结果将跳过原有事件,但会执行Aop End事件
/// </summary>
Break,
/// <summary>
/// 本结果将直接跳出原有函数的执行
/// </summary>
Return,
有了返回值,插入后,跳过Access的插入执行,返回成功即可。
参考代码:
4:删除数据的处理流程:
当用户操作删除文章时,默认Begin不执行,先走原来流程,删除主表,再从End事件删除SQLite表。
参考代码:
5:修改数据的处理流程:
由于Access已改装成队列式执行,因此更新流程需比插入多了一步要考虑的:
如:用户更新了A字段,这时队列还没更新进数据库,然后用户又更新了B字段。
这时候,只能产生2个更新文件到队列中,后者B不能直接复盖A,不然会造成A的修改丢失。
参考代码:
6:数据的查询功能:
根据条件判断,如果是单用户的数据,直接Begin方法查完SQLite后返回即可。
示例的查询代码:
至此,整体的最后的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技术原理解析:博客一键安装工具技术实现[附源码下载] --开源秋色园安装工具原理
本文转自cyq1162 51CTO博客,原文链接:http://blog.51cto.com/cyq1162/739559,如需转载请自行联系原作者