1. 并發(fā)中如何無鎖。
一個很簡單的思路，把并發(fā)轉(zhuǎn)化成為單線程。Java的Disruptor就是一個很好的例子。如果用java的concurrentCollection類去做，原理就是啟動一個線程，跑一個Queue，并發(fā)的時候，任務(wù)壓入Queue，線程輪訓(xùn)讀取這個Queue，然后一個個順序執(zhí)行。
在這個設(shè)計模式下，任何并發(fā)都會變成了單線程操作，而且速度非常快。現(xiàn)在的node.js, 或者比較普通的ARPG服務(wù)端都是這個設(shè)計，“大循環(huán)”架構(gòu)。
這樣，我們原來的系統(tǒng)就有了2個環(huán)境：并發(fā)環(huán)境 + ”大循環(huán)“環(huán)境
并發(fā)環(huán)境就是我們傳統(tǒng)的有鎖環(huán)境，性能低下。
"大循環(huán)"環(huán)境是我們使用Disruptor開辟出來的單線程無鎖環(huán)境，性能強大。

2. ”大循環(huán)“環(huán)境 中如何提升處理性能。
一旦并發(fā)轉(zhuǎn)成單線程，那么其中一個線程一旦出現(xiàn)性能問題，必然整個處理都會放慢。所以在單線程中的任何操作絕對不能涉及到IO處理。那數(shù)據(jù)庫操作怎么辦？
增加緩存。這個思路很簡單，直接從內(nèi)存讀取，必然會快。至于寫、更新操作，采用類似的思路，把操作提交給一個Queue，然后單獨跑一個Thread去一個個獲取插庫。這樣保證了“大循環(huán)”中不涉及到IO操作。

問題再次出現(xiàn)：
如果我們的游戲只有個大循環(huán)還容易解決，因為里面提供了完美的同步無鎖。
但是實際上的游戲環(huán)境是并發(fā)和“大循環(huán)”并存的，即上文的2種環(huán)境。那么無論我們怎么設(shè)計，必然會發(fā)現(xiàn)在緩存這塊上要出現(xiàn)鎖。

3. 并發(fā)與“大循環(huán)”如何共處，消除鎖？
我們知道如果在“大循環(huán)”中要避免鎖操作，那么就用“異步”，把操作交給線程處理。結(jié)合這2個特點，我稍微改下數(shù)據(jù)庫架構(gòu)。
原本的緩存層，必然會存在著鎖，例如：

這個結(jié)構(gòu)是必然的了，保證了在并發(fā)的環(huán)境下能夠準(zhǔn)確的操作緩存。但是”大循環(huán)“卻不能直接操作這個緩存進行修改，所以必須啟動一個線程去更新緩存，例如：

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

4. 如何保證并發(fā)環(huán)境下緩存數(shù)據(jù)的唯一正確？
我們知道，如果只有讀操作，沒有寫操作，那么這個行為是不需要加鎖的。
我使用這個技巧，在緩存的上層，再加一層緩存，成為”一級緩存“，原來的就自然成為”二級緩存“。有點像CPU了對不？
一級緩存只能被”大循環(huán)“修改，但是可以被并發(fā)、”大循環(huán)“同時獲取，所以是不需要鎖的。
當(dāng)發(fā)生數(shù)據(jù)庫變動，分2種情況：
1）并發(fā)環(huán)境下的數(shù)據(jù)庫變動，我們是允許有鎖的存在，所以直接操作二級緩存，沒有問題。
2）”大循環(huán)“環(huán)境下數(shù)據(jù)庫變動，首先我們把變動數(shù)據(jù)存儲在一級緩存，然后交給異步修正二級緩存，修正后刪除一級緩存。
這樣，無論在哪個環(huán)境下讀取數(shù)據(jù)，首先判斷一級緩存，沒有再判斷二級緩存。
這個架構(gòu)就保證了內(nèi)存數(shù)據(jù)的絕對準(zhǔn)確。
而且重要的是：我們有了一個高效的無鎖空間，去實現(xiàn)我們?nèi)我獾臉I(yè)務(wù)邏輯。

最后，還有一些小技巧提升性能。
1. 既然我們的數(shù)據(jù)庫操作已經(jīng)被異步處理，那么某個時間，需要插庫的數(shù)據(jù)可能很多，通過對表、主鍵、操作類型的排序，我們可以刪除一些無效操作。例如：
a）同一個表同一個主鍵的多次UPdate，取最后一次。
b）同一個表同一個主鍵，只要出現(xiàn)Delete，前面所有操作無效。
2. 既然我們要對操作排序，必然會存在一個根據(jù)時間排序，如何保證無鎖呢？使用
private final static AtomicLong _seq = new AtomicLong(0);
即可保證無鎖又全局唯一自增，作為時間序列。