什麼是ACID？

　　事務的定義和實現一直隨著資料管理的發展在演進，當計算機越來越強大，它們就能夠被用來管理越來越多資料，最終，多個使用者可以在一臺計算機上共享資料，這就導致了一個問題，當一個使用者修改了資料而另外一個還在使用舊資料進行計算過程中，這裡就需要一些機制來保證這種情況不會發生。

　　ACID規則原來是在1970被Jim Gray定義，ACID事務解決了很多問題，但是仍然需要和效能做平衡協調，事務越強，效能可能越低，安全可靠性和高效能是一對矛盾。

　　一個事務是指對資料庫狀態進行改變的一系列操作變成一個單個序列邏輯元操作，資料庫一般在啟動時會提供事務機制，包括事務啟動 停止 取消或回滾。

　　但是上述事務機制並不真的實現“事務”，一個真正事務應該遵循ACID屬性，ACID事務才真正解決事務，包括併發使用者訪問同一個資料表記錄的頭疼問題。

ACID的定義：

• Atomic原子性: 一個事務的所有系列操作步驟被看成是一個動作，所有的步驟要麼全部完成要麼一個也不會完成，如果事務過程中任何一點失敗，將要被改變的資料庫記錄就不會被真正被改變。
• Consistent一致性: 資料庫的約束 級聯和觸發機制Trigger都必須滿足事務的一致性。也就是說，通過各種途徑包括外來鍵約束等任何寫入資料庫的資料都是有效的，不能發生表與表之間存在外來鍵約束，但是有資料卻違背這種約束性。所有改變資料庫資料的動作事務必須完成，沒有事務會建立一個無效資料狀態，這是不同於CAP理論的一致性"consistency".
• Isolated隔離性: 主要用於實現併發控制, 隔離能夠確保併發執行的事務能夠順序一個接一個執行，通過隔離，一個未完成事務不會影響另外一個未完成事務。
• Durable永續性: 一旦一個事務被提交，它應該持久儲存，不會因為和其他操作衝突而取消這個事務。很多人認為這意味著事務是持久在磁碟上，但是規範沒有特別定義這點。

什麼是CAP？

CAP是分散式系統中進行平衡的理論，它是由 Eric Brewer釋出在2000年。

• Consistent一致性: 同樣資料在分散式系統中所有地方都是被複製成相同。
• Available可用性: 所有在分散式系統活躍的節點都能夠處理操作且能響應查詢。
• Partition Tolerant分割槽容錯性: 在兩個複製系統之間，如果發生了計劃之外的網路連線問題，對於這種情況，有一套容錯性設計來保證。

一般情況下CAP理論認為你不能擁有上述三種中兩種，這是一個實踐總結，當有網路分割槽情況下，也就是分散式系統中，你不能又要有完美一致性和100%的可用性，只能這兩者選擇一個。在單機系統中，你則需要在一致性和延遲性latency之間權衡。

CAP和ACID一致性區別

　　ACID一致性是有關資料庫規則，如果資料表結構定義一個欄位值是唯一的，那麼一致性系統將解決所有操作中導致這個欄位值非唯一性的情況，如果帶有一個外來鍵的一行記錄被刪除，那麼其外來鍵相關記錄也應該被刪除，這就是ACID一致性意思。

　　CAP理論的一致性是保證同樣一個數據在所有不同伺服器上的拷貝都是相同的，這是一種邏輯保證，而不是物理，因為光速限制，在不同伺服器上這種複製是需要時間的，叢集通過阻止客戶端檢視不同節點上還未同步的資料維持邏輯檢視。

　　當跨分散式系統提供ACID時，這兩個概念會混淆在一起，Google’s Spanner system能夠提供分散式系統的ACID，其包含ACID+CAP設計：

言盡於此，完結

無論是一個初級的 coder，高階的程式設計師，還是頂級的系統架構師，應該都有深刻的領會到設計模式的重要性。

• 第一，設計模式能讓專業人之間交流方便，如下：

程式設計師A：這裡我用了XXX設計模式

程式設計師B：那我大致瞭解你程式的設計思路了

• 第二，易維護

專案經理：今天客戶有這樣一個需求…

程式設計師：明白了，這裡我使用了XXX設計模式，所以改起來很快

• 第三，設計模式是程式設計經驗的總結

程式設計師A：B，你怎麼想到要這樣去構建你的程式碼

程式設計師B：在我學習了XXX設計模式之後，好像自然而然就感覺這樣寫能避免一些問題

• 第四，學習設計模式並不是必須的

程式設計師A：B，你這段程式碼使用的是XXX設計模式對嗎？

程式設計師B：不好意思，我沒有學習過設計模式，但是我的經驗告訴我是這樣寫的

從設計思想解讀開源框架，一步一步到Spring、Spring5、SpringMVC、MyBatis等原始碼解讀，我都已收集整理全套，篇幅有限，這塊只是詳細的解說了23種設計模式，整理的檔案如下圖一覽無餘！

資料領取方式：點選這裡下載

蒐集費時費力，能看到此處的都是真愛！