性能優化篇：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.anti-gravitydesign.com