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

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

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

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

由此產(chǎn)生了以下的解決方案：

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

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

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

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

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

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

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

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