QBlog官方博客

本博将记录与秋色园成长相关的历史路程及秋色园的开发进展等相关情况。
公告信息
欢迎光临秋色园官方博客,欢迎:下载与使用CYQBlog系统,并提出您的意见与建议。
文章档案
文章
秋色园QBlog技术原理解析:性能优化篇:access的并发极限及分库分散并发方案(十六)
2011/7/13 10:38:14

上节 秋色园QBlog技术原理解析:性能优化篇:数据库文章表分表及分库减压方案(十五) 中,

介绍了 秋色园QBlog 在性能优化方面,从技术的优化手段,开始步入数据库设计优化,并从数据的使用情况上进行了分析,从而将文章内容进行分离,得到新的分表,由于内容比较大,进而分了库,达到一种基础减压。

本节内容:

本节将介绍秋色园 QBlog 的Super分库方案,以及何以如此Super分库的原因

描述说明:

在进行上了上节的分库方案后,虽然感觉一度秋色园QBlog的访问速度是花拉拉的[当然国际线路引起的丢包或DNS域名解析缓慢就另一回说了]。

但是,那仅是外在的表现,在晚上三四点优化好方案后,感觉速度花拉拉,终于可以安心入睡了。

第二天早上10点多,睡梦中,带着一丝忧心,用手机访问了一下秋色园QBlog

发觉竟然访问不了,于是一下子又从床上跳了起来,赶紧开机,进vps,一看:QBlog.ldb文件产生了。

而且看样子似乎已经N小时不退了,那个纠结,仅有重启IIS,短暂性的解决了这问题,接下来又得忙碌了。

对于秋色园QBlog的当前情况,我们可以进行以下的想象:

当内存回收时:[就算用户访问不多,搜索引擎也会来访问,而且是到处抓的]

根据秋色园QBlog的方案,将产生很多读取access数据库的操作:比如:

A:失去缓存的抵抗,虽然首次访问有静态html挡着,但是,后台线程产生新的界面生成的随机概率增大了,也即时说,后台线程操作数据库的开始频繁了。

B:有部分页面是没有设置生成静态页面的,因此,直接就产生数据库的操作。

C:用户计数器和文章点击计数器,也在不时的概率性更新着数据库。

于是:当这些操作集中发生在一很小的时间段的时候,小小的access将同时产生很多的并发操作。

再于是:4K的QBlog.ldb文件产生了,内部死锁解不开了。

于是的于是:纠结的悲剧的一幕产生了,秋色园QBlog打不开了。

于是的于是的结果:又再一次悲催着优化的步伐,你得继续优化。

Access并发极限的分析

在写此文前,我做了一个小小的代码测试,通过这个小测试,终于解惑了我对access究竟支持的是怎样的并发和4K的.ldb文件的概念。

这个测试很简单:

1:每Open打开一个Access链接后,我就让它Sleep100秒:就是打开就不关闭了。

2:开多个线程,同时去Open链接:模拟并发请求。

3:观看产生的.ldb文件:结论靠观察。

终于,我看到了一个直观的过程:

1:打开1个链接时,产生一个.ldb文件,而且这个.ldb文件大小是64个字节。

2:打开2个链接时,产生一个.ldb文件,而且这个.ldb文件大小是128个字节。

3:打开3个链接时,产生一个.ldb文件,而且这个.ldb文件大小是192个字节。

......省略......

4:打开64个链接,产生一个.ldb文件,而且这个.ldb文件大小是4K。

5:打开65个链接,报错了,再往后,全错了。

如果这是access单个数据库极限并发的答案,总结就是:

access最大支持同时打开64个链接,每个链接产生64个字节,看到黄金4K的.ldb文件,说明极限到了。

而且,这是一个数据库的极限,因此,你想获得更大的并发数,不是分表,而是分库。

以上是对一个数据库的最大极限测试,那会不会对数据库的单个表存在着最大极限并发?

带着些许疑问,我又把示例稍为改了一下,进行单表的最大并发测试:

1:产生64个线程,即同时打开最大的数据库并发链接。

2:每个链接,都内建死循环,while中不断的更新着同一条记录。

3:观看有没有异常产生,同时数据库记录是不是正常更新着。

终于,我又看到了一个直观的过程:

1:没有异常产生。

2:记录在正常被更新着。

如果这是access单个表极限并发的答案,总结就是:

access的单表并发处理机制,没有限制,当然,最大并发数仍取决单个数据库链接数的最大并发64。

PS:如果一个链接内,再开N个线程去更新,结论又会是怎样呢?这问题似乎不太重要,有需要知道的大伙自己写示例了。

写到这里,大伙能理解access了吧,你想象一下:

1:一个页面从上到下,那得open几个链接?当然,如果没忘了关链接,一般是顺序下来的算1个。

2:能支持同时并发打开几个页面呢?1个页面算1个,最大64个?是64个,但这个不是1秒,而是取决于1个页面的执行时间,如果你5秒打开1个页面,基本就是64/5=13了。

4:那些没完没了的搜索引擎,也是和正常用户一样不断的请求的,你别忘了?除却搜索引擎,你还剩下几个请求?如果同时来了6家搜索引擎,那就剩下13-6=7,也就是有8个人访问,你就挂了。

当然了,瞎扯扯就这么算并发,实际也没算的这么准。

所以,用access的基础策略是:

1:静态化:特别适合实时性不强的,一次生成终生不变的。

2:特别适合单用户的:因为就一个人发信息,不可能产生并发问题,加上前面静态化,很合适。

2:特别情况-缓存技术:一般用access的都会弱化用户统计或文章统计,因为这个更新,意味着占用一个链接,多来几个也会挂,因此文章统计和用户访问统计,要么关闭,要么动点手脚。

3:分库策略:能增加并发最大数,1个64,我用100个,就是64*100了,团结就是力量啊,当然这么大个军团,不好管理,需要一定的管理策略和算法。

4:其它的你自己想了......

 

秋色园QBlog的超级分库分案:

先看一张图片,看一下秋色园QBlog 现在有几个access数据库:

说明:

数了一下,有8个,常用的基本都是一个表一个数据库,不常用的就还在一起一个数据库。

其实,秋色园QBlog 的分库,都是在写这篇文章之前分的,也既时说,当初分库的时候,我并不知道access的最大极限,虽然我曾一度的百度及google过access的并发数或性能上限,但是,出来的网页结果,都没有答案,于是我仅靠猜。

每次我见到秋色园QBlog打不开时,我都可以清楚的见到qblog.ldb文件,于是我也曾搜索去找到ldb的相关答案,可惜,找不到我要的答案,但是我知道ldb文件这个问题很严重。

于是,在那个过程,我是一步一步的分的库,因为缺少真实的理解,我靠想象与猜测是某个表产生了死锁引起的,因此我的第一理念,是把某个表分离出来。

因此,虽然现在你看到有8个库,其实这不是一次分出来的:

实际是某当qblog.mdb这个主库遇到4K最大锁时,我就在怀疑某个表,然后就把某个表分出一个库出来;

然后感觉又好了,再过不久,又出来4K最大锁,我又在怀疑是不是某表又锁了,又分出了一个库;

于是过了好长时间的重复,才最终形成这样的分库结果。

PS:在发布的CYQ.Blog(QBlog) V3.0 单用户版本中,虽然发布的是一个数据库,但是,隐藏着更高性能的分库功能,即是说,如果想再提升性能,你还可以分库,然后分一个库补充1个链接即可。不过单用户版本,V3.0的性能已经够强悍了,而且同时还支持着多种数据库。

分库的功臣,Access链接表

在分库的过程中,不得不提到Access的链接表,如果没有它,分库真的难以想象的复杂。

复杂在何处?当然是代码的修改了,你能想象分布在两个数据库间的表链接查询?

用链接表,代码不用改,逻辑不用变,SQL语句仍照样兼容,有点神奇。

分库步骤(示例分库用户表Blog_User):

1:新建一数据库:qbloguser.mdb。

2:打开qbloguser.mdb,菜单:文件->获取外部数据->导入,选择qblog数据库,将用户表导进来,完成表的分库转移。

3:打开qblog.mdb,删除用户表,然后菜单:文件->获取外部数据->链接表,从qbloguser.mdb中将用户表链接过来。

OK,1分钟内完成分库并链接表,至此,并没有代码逻辑的修改,但是,仅是这样的分库,是无意义的。

因为并有没散链接,操作用户表时,还是操作的qblog.mdb数据库,压力并没有分散。

代码调整,分散单表操作的压力

代码还是需要调整,首先将表枚举分出来:

    public enum U_QBlogUserEnum
    {
             Blog_User,
    }

因据 CYQ.Data  的多数据库应用的约定,此表的数据库链接将转向配置项为QBlogUserConn项。

因此,仅需要多配置多一条数据库链接指向qbloguser.mdb即完成了。

当然了,原来TableNames.Blog_User语句,批量替换成U_QBlogUserEnum.Blog_User就可以了。

再当然的话,代码也不可能只改动这么小,因为,必须兼容一个库的情况,比如CYQ.Blog(QBlog) V3.0发布时,

实际是支持分库操作的,但是最终发布是一个库发布的,因此,兼容的链接也必须处理。

再有一个提示,就是CYQ.Data  的ResetTable切换表操作功能,由于链接取的上一个,因此在分库的情况下,每个表都是不同的链接,因此ResetTable的表操作,必须独立出来操作。

强大的 CYQ.Data 数据框架,仅靠提取表枚举头部,就能自动切换数据库,达到多数据库应用。

于是,秋色园 QBlog 的Super分库的策略,由此轻松的完成了。

最终形成的数据库链接如下:

压力分散是什么情况:

1:单表操作,分散到独立的数据库链接中,如qbloguser.mdb。

2:多表操作,直接操作的qblog.mdb的链接表。

3:每个库都能同时支持64个并发链接。

总结

虽然秋色园 QBlog 整个的分库策略,是长时间一步一步分的库,由于原理是一致的,因此此文就一次性上齐了。

而且写此文前进行的示例测试,有效的为自己和大伙解开access的并发上限之惑,

同时也解答了,多数库分库的确带来并发上的好处。

然而分库再怎么厉害,一个库也是支持最大64个链接并发打开。

虽然:CYQ.Data 用Lock锁住插入/更新/删除,这些步骤,使的同一时间只出现一个链接打开。

但是,通过今天的示例,发现了,读取,也是要打开链接的。

因此,优化并没有止步,本系列还在继续,请继续关注。

下一篇:秋色园QBlog技术原理解析:性能优化篇:用户和文章计数器方案(十七)

 

历史文章回顾:

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技术原理解析:性能优化篇:数据库文章表分表及分库减压方案(十五)  --介绍内容分库减压

附章:

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

2:如何安装部署秋色园CYQBlog站点

3:Windows7下如何安装部署秋色园CYQBlog站点

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

秋色园是QBlog的官方站点,由路过秋天创建,基于cyqdata数据层框架开发的支持多用户、多语言、多数据库(access,mssql,oracle)、目录级url等功能强大的博客系统
新浪微博粉丝精灵,刷粉丝、刷评论、刷转发、企业商家微博营销必备工具"
游客[注册][222.128.117.*] : 2017/12/8 11:58:27
可以
  
Copyright © 2010-2020 power by CYQ.Blog - 秋色园 v2.0 All Rights Reserved