大數據怎么徹底解決分布式系統(tǒng)一致性問題

大數據怎么徹底解決分布式系統(tǒng)一致性問題，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

  其實個人理解的時候，更希望能夠得到代碼層面的實現，單純的理論知識還是不夠落地，總結容易，真正實現起來還是需要項目的積累。

  保證最終一致性的模式

  1.查詢模式

  任何服務操作都需要提供一個查詢接口，用來向外輸出操作執(zhí)行的狀態(tài)。即：單筆查詢，為了使查詢操作有一個唯一標識，需要一個分布式環(huán)境下的ID，可用分布式鎖,redis 遞增,機器的唯一碼 拿出幾位存為機器id,這樣一來每次查詢操作相對更快?？山鉀Q同步調用超時問題異步回調超時問題。

  2.補償模式

  再操作失敗，我們需要修正有問題的操作，是分布式系統(tǒng)達到一致，為了讓系統(tǒng)達到一致而做出的努力都叫做補償操作。這個場景就和出水問題一樣?。。?！補償操作分為：自動回復，通知運營，和技巧運營。

  3.異步確保模式

  再對響應時間要求不高的場景，通過異步的方式處理，再把結果告知使用方，這個方案最大的好處就是能對高并發(fā)流量進行消峰，例如電商中的物流，配送，支付系統(tǒng)的計費，入賬。

  4.定期校對模式

  再操作主流系統(tǒng)間執(zhí)行校對操作，再時候異步批量校對操作的狀態(tài)，如果不一直進行補償，這句話有點不太理解，定期校對系統(tǒng)如圖

定期校對系統(tǒng)多用于金融系統(tǒng)，針對于數據的準確性。

  5.可靠消息模式

  利用消息隊列實現異步化

  ①消息的可靠發(fā)送

  發(fā)送消息之前先將消息持久化到數據庫，將狀態(tài)標記為未發(fā)送，然后發(fā)送消息，如果發(fā)送成功，則標記，定時從數據庫撈取一定時間內未發(fā)送的消息并發(fā)送。

  ②消息處理器的冪等性

  冪等性，冪等性，面試和刷題你總會遇到，要想解決，就得先知道啥叫冪等性。

  在網絡延遲傳輸中，會造成消息隊列重試，在充實過程中，消息會存在重復

  解決方案：

  1.如果是數據庫的插入操作，給消息做一個主鍵，避免出現臟數據。

  2.使用第三方做消費記錄，例如Redis，全局id為K，消息為V，寫入到Redis，消費之前先去查Redis是否存在

  3.使用數據庫的行級鎖

  6.緩存一致性模式

  如果面對億級讀需求，需要非關系型數據庫抗住流量，這里有個問題？啥叫關系型數據庫？(能夠互相連接的列表式數據庫)

  讀的順序是先讀緩存，讀不到再讀數據庫，寫的順序是先寫數據庫，后寫緩存。

  超時處理模式

  1微服務的交互模式

  ①同步調用模式

  服務1調用服務2，服務1等待服務2返回結果

  ②異步調用模式

  服務1調用服務2，服務2處理后，反向通知服務2

  ③消息隊列異步處理模式

  服務1傳遞給服務2，不需要關心返回結果

  ①同步調用模式解決方案

  兩狀態(tài)

    三狀態(tài)

  ②異步調用模式解決方案

   ③消息隊列異步處理模式解決方案

文章對服務化系統(tǒng)中同步調用，異步調用，消息隊列等應用場景進行了分析，個人理解還是不到位，還有一些疑問，例如什么時候會導致消息重發(fā)？消息重發(fā)仍然失敗怎么辦？失敗次數超過預期怎么辦？還有就是怎么樣從代碼層面實現，這些在面試中都太籠統(tǒng)了，根本解決不了實際問題，還是要從實際場景解決問題。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業(yè)資訊頻道，感謝您對億速云的支持。