[webdriver]

首先看看道友提出的一個問題：
用戶甲的操作
1.開始事務
2.訪問表A
3.訪問表B
4.提交事務
乙用戶在操作
1.開始事務
2.訪問表B
3.訪問表A
4.提交事務

如果甲用戶和乙用戶的兩個事務同時發生，甲事務鎖住了表A未釋放(因為整個事務未完成)，正在准備訪問B表，而乙事務鎖住了表B未釋放(因為整個事務未完成)，正在准備訪問A表，可是A表被甲事務鎖住了，等甲事務釋放，而甲事務真正等待乙事務釋放B表，陷入了無限等待，也就是死鎖Dead Lock。

也有道友使用多線程來模擬存儲過程：http://www.jdon.com/45727，每個線程裡開啟一個事務，類似上述問題也會出現死鎖。

問題出在哪裡？

[webdriver]

是我們的思路方向出現問題：

其實無論是使用數據庫鎖 還是多線程，這裡有一個共同思路，就是將數據喂給線程，就如同計算機是一套加工流水線，數據作為原材料投入這個流水線的開始，流水線出來後就是成品，這套模式的前提是數據是被動的，自身不復雜，沒有自身業務邏輯要求。適合大數據處理或互聯網網站應用等等。

但是如果數據自身要求有嚴格的一致性，也就是事務機制，數據就不能被動被加工，要讓數據自己有行為能力保護實現自己的一致性，就像孩子小的時候可以任由爸媽怎麼照顧關心都可以，但是如果孩子長大有自己的思想和要求，他就可能不喜歡被爸媽照顧，他要求自己通過行動實現自己的要求。

數據也是如此。

只有我們改變思路，讓數據自己有行為維護自己的一致性，才能真正安全實現真正的事務。

數據+行為=對象，有人問了，對象不是也要被線程調用嗎？

[webdriver]

例如下述代碼，因為對象的行為要被線程調用，我們要使用同步鎖synchronized ：

代碼:

public class A {         private volatile int lower, upper; //兩個狀態值         public int getLower() { return lower; }         public int getUpper() { return upper; }         public synchronized void setAUpper(int value){              if (value < a.getUpper())                     a.setLower(value);         }         public asynchronization void setALower(int value){             if (value > a.getLower())                    a.setUpper(value);          }    }

上面這段代碼業務邏輯是想實現lower<upper：

1. lower和upper的初始值是(0, 5)，
2.一個客戶端請求線程A: setLower(4)
一個客戶端請求線程B: setUpper(3)
3. lower和upper是 (4, 3)

這個結果破壞了lower<upper這個邏輯一致性，所以，用鎖並不能保證邏輯一致性，而且還帶來了堵塞。鎖用錯了地方，不但沒有得到想要的，而且還失去更多。

[webdriver]

下圖展示了鎖帶來堵塞，每個時刻只能允許一個線程工作，如同只能允許一個人蹲馬桶一樣。

[webdriver]

從歷史上看，鎖的問題如鬼魂一直伴隨著我們：
1.用數據表一個字段來表示狀態，比如1表示已付款未發貨，2表示已付款已發貨，然後用戶來一個請求用SQL或存儲過程修改，這時使用的數據庫鎖。

2.用ORM實現，比如Hibernate JPA來修改狀態，雖然不用SQL了，但是Hibernate的悲觀鎖和樂觀鎖也讓人抓狂。

3.徹底拋棄數據庫，直接在內存緩存中進行修改，使用Java的同步鎖，性能還是不夠，吞吐量上不去。如上圖提示，只能一個廁所蹲位一個人用，其他人必須排隊。

[webdriver]

4.Actor模型。

Actor模型原理
Actor模型=數據+行為+消息。

Actor模型內部的狀態由自己的行為維護，外部線程不能直接調用對象的行為，必須通過消息才能激發行為，這樣就保證Actor內部數據只有被自己修改。

[webdriver]

Actor模型如何實現？

Scala或ErLang的進程信箱都是一種Actor模型，也有Java的專門的Actor模型，這裡是幾種Actor模型比較

明白了Actor模型原理，使用Disruptor這樣無鎖隊列也可以自己實現Actor模型，讓一個普通對象與外界的交互調用通過Disruptor消息隊列實現，比如LMAX架構就是這樣實現高頻交易，從2009年成功運行至今，被Martin Fowler推崇。

回到本帖最初問題，如何使用Actor模型解決高並發事務呢？

轉賬是典型的符合該問題的案例，轉賬是將A帳號到B帳號轉賬，使用Actor模型解決如下：

發出是否可轉出消息--->消息隊列--->A

A作為一個對象，注意不是數據表，對象是有行為的，檢查自己余額是否可轉賬，如果可以，凍結這部分金額，比如轉賬100元，凍結100元，從余額中扣除。因為外部命令是通過消息順序進來的，所以下一個消息如果也是扣除，再次檢查余額是否足夠......

具體詳細流程可見：REST和DDD

[webdriver]

那麼，既然Actor模型如此巧妙，而解決方向與我們習慣的數據喂機器的方式如此不同，那麼如何在實戰中能明顯發現某個數據修改應該用Actor模型解決呢？因為我們習慣將數據喂機器的思路啊？

使用DDD領域驅動設計或CQRS架構就能明顯發現這些特殊情況，CQRS是讀寫分離，其中寫操作是應領域專家要求編寫的功能，在這類方向，我們都有必要使用Actor模型實現，因為在這個方向上，領域專家的要求都表達為聚合根實體，聚合根就是用Actor模型實現最合適不過了。而讀方向，比如大數據處理，報表查詢，OLTP等等都是數據喂機器的方式。

有的道友會疑問，我們經常使用SSH，也就是Spring + Hibernate架構，這個默認是哪種方向呢？很顯然，默認是數據喂機器的方向，所以在實現寫操作時，特別警惕高並發發生死鎖等影響性能問題，當然也包括EJB架構。

有一種togaf架構，將企業軟件架構分為數據架構和應用架構等，實際是EJB或SSH的變相描述，這種架構的問題我們已經一目了然了，特別這樣的系統如果從面向內部管理轉向到SaaS模型時，這類高並發死鎖問題就特別容易發生，幾乎不具備可用性。前期12306火車票系統是這類問題的典型體現。

(the end)