性能优化篇：access的并发极限及超级分库分散并发方案(十六)

　　本节内容：

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

　　描述说明：

　　在进行上了上节的分库方案后，虽然感觉一度秋色园QBlog的访问速度是花拉拉的。

　　[PS：当然国际线路引起的丢包或DNS域名解析缓慢就另一回说了，特别是最近ping www.cyqdata.com 经常性超时，我很纠结;

　　另外：有些地区在域名解析上也出现访问速度慢的，所以特别增加了IP访问方式，于是现在用IP也可以直接访问秋色园了。]

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

　　第二天早上10点多，睡梦中，带着一丝忧心，用手机访问了一下秋色园QBlog，发觉竟然访问不了。

　　于是一下子又从床上跳了起来，赶紧开机，进vps，一看：QBlog.ldb文件产生了，黄金4K的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：特别适合单用户的：因为就一个人发信息，不可能产生并发写问题，加上前面静态化，很合适。

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

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

　　5：其它的你自己想了......

　　复制代码

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

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

原文转自：http://www.ltesting.net