一致性問題的模式和思路

一.酸鹼平衡理論數據庫

ACID在英文中的意思是「酸」,BASE的意思是鹼網絡

1.ACID(酸)併發

     關係型數據庫天生用於解決具備復瑣事務場景的問題,徹底知足ACID的特性。分佈式

 ACID指以下內容。高併發

A: Atomicity原子性性能

C:Consistency 一致性大數據

I:Isolation  隔離性日誌

D:Durability 持久性事務

       具備ACID特性的關係型數據庫支持強一致性,強一致性表明數據庫本省不會出現強一致性。每一個事務都是原子的,事務是徹底隔離的互相徹底不受影響,而且最終狀態是持久落盤的。ci

       所以在交易的相關係統進行技術選型,則交易的存儲應該只考慮關係型數據庫,對於核心系統,若是須要較好的性能,則能夠考慮使用更強悍的硬件,這種向上擴展(升級硬件)雖然成本很高,可是確實最簡單最有效的。NoSQL則不適合交易場景,主要用來作數據分析,挖掘,日誌等的處理。

      然而在當前的互聯網項目大多具備大規模、高併發的的特色,必須使用拆分的概念,對高併發的壓力。分而治之、大而化小。不然難以知足動輒上億的流量的需求,即時使用關係型數據庫,單機也難以知足存儲和吞吐上的性能需求。對於訂單和扣庫存,應儘可能保證將訂單和庫存放入同一數據庫分片,這就經過關係型數據看保證了數據的一致性型。可是有些時候也是事與願違,因爲業務規則的限制,咱們沒法將相關數據放在一個數據庫分片,這時候就須要實現最終一致性。

 

2.CAP  

     因爲對系統或者數據進行拆分,咱們的系統再也不是單機系統,而是分佈式系統,針對分佈式系統的CAP原理包含以下三個元素。

     C:Consistency,一致性。在分佈式系統中的全部數據備份,在同一時間有相同的值。全部節點獨到的數據都是數據的最新副本。

    A:Availabitity,可用性,好的相應性能。徹底的可用性指的是在任何故障模型下,服務都會在有限的時間內處理完成並進行響應。

    P:partition tolerance,分區容忍性。 儘管網絡上有部分數據丟失,系統仍然能夠繼續工做。

CAP原理證實,任何分佈式系統只可同時知足以上兩點,沒法三者兼顧。而分佈式系統都要知足分區容忍性,那麼咱們必須在一致性和可用性之間進行權衡。

       若是在網絡上有消息丟失,也就是出現了網絡分區,則複製操做可能被延後,若是這時候咱們的適用方在等待複製完成後在返回,則可能致使在有限時間內不能返回,就失去了可用性。而若是適用法不等待複製完成,而在主分片完成後直接返回,則具備可用性,可是失去了一致性。

 

3.BASE    

       BASE思想解決了CAP提出的分佈式一致性和可用性不可兼得的問題。基於ACID和BASE的理論,簡單來講就是在不一樣的場景下,能夠分別使用ACID和BASE來解決分佈式服務化的一致性問題。

       BASE思想和ACID原理大相徑庭,它知足CAP原理,經過犧牲強一致性得到可用性。通常應用於服務化系統的應用層和大數據處理系統中,經過達到最終一致性來儘可能知足業務的絕大多數需求。包含下面三個元素:

     BA:Basicallly Avaiablitity,基本可用

     S:Soft state,軟狀態,狀態能夠在一段時間內不一樣步.

     E: Eventually Consistent,最終一致性,在必定的時間窗口內,最終數據達成一致性。

軟狀態是實現BASE思想的方法,基本可用和最終一致性是目標。系統因爲不保證強一致性,因此係統在請求處理的過程當中能夠存在短暫的不一致,在短暫的不一致的時間窗口內。請求處理處於臨時狀態中,系統中進入每步操做時,記錄每一個臨時狀態。在系統出現故障時能夠從這些中間狀態繼續處理未完成的請求或者退回到原始狀態,最終達到一致性。

       有了BASE思想做爲基礎,咱們對複雜的分佈式事務進行拆解,對其中的每一個步驟都記有狀態,有問題以後能夠經過記錄的狀態來繼續任務,達到最終一致性。

解決一致性問題三條實踐經驗:

1.使用向上擴展(強悍的硬件)並運行專業的關係型數據庫(Oracle,DB2或者MySQL).可以保證強一致性,能用向上擴展解決問題都不是問題。

2.向上擴展的成本很高,可對開源的關係型數據庫進行水平擴展和分片,將相關數據分到數據庫的同一片上,任然可以使用關係型數據庫保證事務。

3.若是業務規則限制,沒法將相關數據放在同一分片中,就須要實現最終一致性,在記錄事務的軟狀態(中間狀態,臨時狀態)時,若出現不一致,則能夠經過系統自動化或者人工干預修復不一致的問題。

相關文章
相關標籤/搜索