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

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

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

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

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

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

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

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

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

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

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

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

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