很多Web系統(tǒng)的瓶頸在網絡IO，所以很多系統(tǒng)都采用多Web服務器負載均衡，雙DB做雙機熱備（其實就是只有一個DB，兩臺只有一臺真正工作，死掉一臺另一臺頂上）的方式部署，在這個時候很多原本不是問題的系統(tǒng)也會產生很多的問題。

這里我們假設有表Product，其定義如下：

假設很不湊巧的，3個管理員P1,P2,P3同時操作了這個表，且P1 update StoreCount=50,P2 update StoreCount=49,P3 update StoreCount=48。這個時候問題就來了，如果是讓他們都同時提交進去，當然沒問題，但是如果這個時候N個Web程序在讀的時候就會產生每臺服務器上讀出來的數(shù)據都可能不一樣，A服務器讀出來是48，B服務器讀出來是50，C服務器讀出來是49。

如果我們采用數(shù)據庫鎖可以避免這個問題，但是隨之而來的是系統(tǒng)效率降低和無可避免的異常，而hibernate等實現(xiàn)的樂觀鎖呢，呵呵，對不起了，在多Web服務器的時候還能起作用嗎？

由此產生了以下的解決方案：

和樂觀鎖的實現(xiàn)相反，我們不反對任何一個客戶端的提交，樂觀鎖對讀取的數(shù)據增加版本號，那么這個解決方案中對提交的數(shù)據增加“版本號”其實也就是時間戳。針對上面的Product表作為例子，為了實現(xiàn)無鎖的提交，我們需要增加一個表Product_Dirty，以后我們將稱其為臟表，Product表我們稱之為主表。臟表的結構和主表幾乎完全一致，只是增加了一個時間戳字段用于記錄詳細的插入時間：

在發(fā)生任何update的時候都將數(shù)據直接插入這個表，不要猶疑，沒鎖，所以可以快速的，盡情的插入數(shù)據。這里還是保持最初的假設，P1，P2，P3同時修改，所以插入了三條數(shù)據。所謂的同時插入其實在毫秒這個級別還是有差距的，所以三條記錄的時間戳是不同的。好了這個時候數(shù)據進來了，但是主表的列數(shù)據還是沒有改變，先在假設A服務器和B，C服務器都同時開始讀數(shù)據了。在主表的時候，如果發(fā)現(xiàn)臟表有數(shù)據則表明主表數(shù)據為臟（已經修改過了）這個時候我們就開始合并數(shù)據，當然這個操作是需要在一個事務里實現(xiàn)。合并的操作其實很簡單，就是取時間戳最大的（也就是最近一次修改）更新主表的數(shù)據，同時刪掉臟表里的和主表ID相等的所有數(shù)據。如果發(fā)現(xiàn)主表關聯(lián)的臟表沒數(shù)據，那么就說明主表數(shù)據正常，就直接讀取主表的內容。

此解決方案來自電信營帳系統(tǒng)的設計，由于省電信眾多系統(tǒng)都是由分布很廣的地市州電信業(yè)務人員操作，所以修改的時候經常存在本文要解決的問題，由于操作的人多，鎖表的話會造成嚴重的擁塞，故產生了這個解決方案，由于電信的業(yè)務需要后臺跑了一個服務來合并數(shù)據，并且每秒定時運行，故每秒為一個業(yè)務周期。我將其修改成在讀取的時候合并，更加靈活一些。

好處：不用鎖表，樂觀鎖也不用，可以在N多服務器操作的時候使用，且大家都不會報錯，簡化了異常處理。

壞處：增加了表，結構復雜，如果是用于修改原有業(yè)務如果只是幾個關鍵表的話還好，全部都采用這個方式工作量巨大（好在電信不缺錢）。

弱點：和樂觀鎖類似，在某些場景下仍然可能臟讀，所以如果對這方面有很高的要求，還是用悲觀鎖吧。

it知識庫：不用鎖表，沒有異常：在高并發(fā)網絡中高效的更新數(shù)據庫數(shù)據的方式，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。