一個在線2k的游戲，每秒鐘并發都嚇死人。傳統的hibernate直接插庫基本上是不可行的。我就一步步推導出一個無鎖的數據庫操作。

?

1. 并發中如何無鎖。

一個很簡單的思路，把并發轉化成為單線程。Java的Disruptor就是一個很好的例子。如果用java的concurrentCollection類去做，原理就是啟動一個線程，跑一個Queue，并發的時候，任務壓入Queue，線程輪訓讀取這個Queue，然后一個個順序執行。?

在這個設計模式下，任何并發都會變成了單線程操作，而且速度非常快。現在的node.js, 或者比較普通的ARPG服務端都是這個設計，“大循環”架構。

這樣，我們原來的系統就有了2個環境：并發環境 + ”大循環“環境

并發環境就是我們傳統的有鎖環境，性能低下。

”大循環“環境是我們使用Disruptor開辟出來的單線程無鎖環境，性能強大。

?

2. ”大循環“環境?中如何提升處理性能。

一旦并發轉成單線程，那么其中一個線程一旦出現性能問題，必然整個處理都會放慢。所以在單線程中的任何操作絕對不能涉及到IO處理。那數據庫操作怎么辦？

增加緩存。這個思路很簡單，直接從內存讀取，必然會快。至于寫、更新操作，采用類似的思路，把操作提交給一個Queue，然后單獨跑一個Thread去一個個獲取插庫。這樣保證了“大循環”中不涉及到IO操作。

?

問題再次出現：

如果我們的游戲只有個大循環還容易解決，因為里面提供了完美的同步無鎖。

但是實際上的游戲環境是并發和“大循環”并存的，即上文的2種環境。那么無論我們怎么設計，必然會發現在緩存這塊上要出現鎖。

?

3. 并發與“大循環”如何共處，消除鎖？

我們知道如果在“大循環”中要避免鎖操作，那么就用“異步”，把操作交給線程處理。結合這2個特點，我稍微改下數據庫架構。

原本的緩存層，必然會存在著鎖，例如：

public TableCache

{
　　private HashMap<String, Object> caches = new ConcurrentHashMap<String, Object>();
}

這個結構是必然的了，保證了在并發的環境下能夠準確的操作緩存。但是”大循環“卻不能直接操作這個緩存進行修改，所以必須啟動一個線程去更新緩存，例如：

private?static?final?ExecutorService?EXECUTOR?= Executors.newSingleThreadExecutor();

EXECUTOR.execute(new?LatencyProcessor(logs));

class?LatencyProcessor implements Runnable

{

　　public void run()
　　{　

　　　　// 這里可以任意的去修改內存數據。采用了異步。
　　}
}

OK，看起來很漂亮。但是又有個問題出現了。在高速存取的過程中，非常有可能緩存還沒有被更新，就被其他請求再次獲取，得到了舊的數據。

?

4. 如何保證并發環境下緩存數據的唯一正確？

我們知道，如果只有讀操作，沒有寫操作，那么這個行為是不需要加鎖的。

我使用這個技巧，在緩存的上層，再加一層緩存，成為”一級緩存“，原來的就自然成為”二級緩存“。有點像CPU了對不？

一級緩存只能被”大循環“修改，但是可以被并發、”大循環“同時獲取，所以是不需要鎖的。

當發生數據庫變動，分2種情況：

1）并發環境下的數據庫變動，我們是允許有鎖的存在，所以直接操作二級緩存，沒有問題。

2）”大循環“環境下數據庫變動，首先我們把變動數據存儲在一級緩存，然后交給異步修正二級緩存，修正后刪除一級緩存。

這樣，無論在哪個環境下讀取數據，首先判斷一級緩存，沒有再判斷二級緩存。

這個架構就保證了內存數據的絕對準確。

而且重要的是：我們有了一個高效的無鎖空間，去實現我們任意的業務邏輯。

?

最后，還有一些小技巧提升性能。

1. 既然我們的數據庫操作已經被異步處理，那么某個時間，需要插庫的數據可能很多，通過對表、主鍵、操作類型的排序，我們可以刪除一些無效操作。例如：

a）同一個表同一個主鍵的多次UPdate，取最后一次。

b）同一個表同一個主鍵，只要出現Delete，前面所有操作無效。

2. 既然我們要對操作排序，必然會存在一個根據時間排序，如何保證無鎖呢？使用

private?final?static?AtomicLong?_seq?=?new?AtomicLong(0);

即可保證無鎖又全局唯一自增，作為時間序列。

一級緩存只會被“大循環”操作。
當數據庫數據變動，“大循環”首先更新一級緩存，然后交給異步更新二級緩存，最后刪除一級緩存。
讀取的時候，先讀取一級緩存，如果沒有再讀取2級緩存。

在一個極短的時間內，當“大循環”內存修改了數據還沒有來得及更新一級緩存，這個時候并發需要讀取操作，自然從二級緩存獲取，那就有臟數據。

這個時候有2種策略：
1. 悲觀鎖，從數據被獲取的時候一直加鎖。這個方法我不推薦，性能低下并且容易有死鎖。
2. 樂觀鎖。當需要修改數據的時候，判斷是否臟數據，如果是就拋異常。這個做法推薦，而且現在大部分的高并發都是這個做法。

轉載于:https://www.cnblogs.com/feiye512/p/5379403.html

總結

以上是生活随笔為你收集整理的如何在高并发环境下设计出无锁的数据库操作（Java版本） 转载的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。