大數據中如何徹底解決分布式系統一致性問題

大數據中如何徹底解決分布式系統一致性問題，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

        要想解決一致性問題，就要先搞明白，什么是一致性問題，一致性問題是分布式常見問題，還可以再分為最終一致性和強一致性，但通常指強一致性，書中表示"你中有我，我中有你，渾然一體"；人多力量大，引申出分而治之的思想和邏輯。

        水平拆分：這里所說的水平，我理解為橫向的空間維度拆分，不單指數據庫表的拆分和緩存的拆分，特指了池化技術，可以類比集群的概念，既：多個相同的服務部在同一個服務上。分布式既：一個服務拆分為不同的服務。

        垂直拆分："專業的人干專業的事"，這樣簡單單一，好維護，類比設計模式的單一職責原則，設計模式的單一職責指的是引起類變的原因只有一個。

        一致性指：分布式服務化系統之間的弱一致性，包括應用系統的一致性和數據的一致性。

        根據這個概念也可以細分下高并發的方向，細分為數據的高并發和請求的高并發來提出解決方案。

        一致性問題

        案例一：下訂單和扣庫存

        電商系統中，如何保持下訂單和扣庫存的操作一致性。如果先下訂單扣庫存失敗，會出現超賣；如果下訂單不成功，扣庫存成功，會導致少賣。

        案例二：同步調用超時

        系統A調用系統B超時，A得到反饋，但無法保證B是是否完成預設功能，導致A無法反饋調用方。

        案例三：異步回調超時

        大多數支付都是做的異步回調

        A調用B，B異步通知A，但A遲遲收不到成功信息，導致無法跳到訂單頁面

        案例四：緩存和數據庫不一致

        為了應對高并發讀操作，訪問數據庫之前，先加一層緩存，比如電商商品詳情頁面展示，那么緩存和數據庫之間的數據如何保持一致性？如果對數據有強一致性要求，不能放緩存

        案例一共8個，這里摘出我感興趣的4個，特別是最后一個。

        解決一致性問題的模式和思路

        根據拋出的問題，進行分析和提出解決方案。

        ACID原理

  原子性(Atomicity)：原子意為最小的粒子，或者說不能再分的事物。數據庫事務的不可再分的原則即為原子性。組成事務的所有查詢必須：要么全部執行，要么全部取消。

 一致性(Consistency)：指數據的規則,在事務前/后應保持一致。

 隔離性(Isolation)：簡單點說，某個事務的操作對其他事務不可見的.

 持久性(Durability)：當事務提交完成后，其影響應該保留下來，不能撤消。

CAP原理

C：一致性

A：可用性

P：分區容錯性

任何分布式系統無法同時滿足三點，淘寶雙11滿足的就是AP原則，zookeeper與Eureka的區別也是zookeeper滿足CP，Eureka滿足AP原則

       BASE模型

       BA：基本可用

       S：軟狀態，狀態可以在一段時間內不同步

       E：最終一致

       BASE思想可以解決案例一一致性問題

       那么我們是如何解決案例四中緩存與數據庫的一致性問題呢？

       現在的大多數方案都是先清緩存，再寫庫，再更緩存的操作，但高并發帶來的問題還是無法真正解決，只是出現的條件比較苛刻。

        兩階段提交，三階段提交，TCC、

        兩階段提交協議：準備階段，提交階段

        三階段提交協議：詢問階段，準備階段，提交階段

        TCC協議：Try，Confirm，Cancel，先執行try，沒問題執行confirm，如果出現問題執行Cancel。

關于大數據中如何徹底解決分布式系統一致性問題問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。