隨著業務複雜性逐漸增強，專案的主體架構也從原本的all in ona 的單體結構，轉化為現在流行的微服務架構，隨著業務的拆分，隨之而來的便是資料一致性問題，當資料庫拆分後，便很難通過事務機制對資料做統一管理，那麼在分布式開發中，資料一致性問題都有那些那，今天我們一起來看一下吧！在分布式資料系統開發過程中，有乙個繞不開的話題，那便是著名的cap理論，在 cap原理中，有三個要素， 在cap理論中，這三個要素最多只能同時實現兩點，不可能三者兼顧，今天我們要聊是便是資料一致性問題。
一致性就是資料保持一直，可以理解為多個節點中資料的值是一致的，一致性又可以分為強一致性與弱一致性。對於一致性，可以分為從客戶端和服務端兩個不同的視角。
從客戶端來看：一致性主要指的是多併發訪問時更新過的資料如何獲取的問題。多程序併發訪問時，更新過的資料在不同程序如何獲取的不同策略，決定了不同的一致性。
從服務端來看：則是更新如何複製分布到整個系統，以保證資料最終一致。一致性是因為有併發讀寫才有的問題，因此在理解一致性的問題時，一定要注意結合考慮併發讀寫的場景。對於關係型資料庫，要求更新過的資料能被後續的訪問都能看到，這是強一致性。如果能容忍後續的部分或者全部訪問不到，則是弱一致性。如果經過一段時間後要求能訪問到更新後的資料，則是最終一致性。
也稱為原子一致性、線性一致性。強一致性可以理解為在任意時刻，所有節點中的資料是一樣的。同一時間點，你在節點a中獲取到key1的值與在節點b中獲取到key1的值應該都是一樣的。任何一次讀都能讀到某個資料的最近一次寫的資料，系統中的所有程序，看到的操作順序，都和全域性時鐘下的順序一致。
任何一次讀都能讀到某個資料的最近一次寫的資料，系統的所有程序的順序一致，而且是合理的。即不需要和全域性時鐘下的順序一致，錯的話一起錯，對的話一起對。
弱一致性包含很多種不同的實現，目前分布式系統中廣泛實現的是最終一致性。
最終一致性是弱一致性的一種特例，保證使用者最終能夠讀取到某操作對系統特定資料的更新。但是隨著時間的遷移，不同節點上的同乙份資料總是在向趨同的方向變化。也可以簡單的理解為在一段時間後，節點間的資料會最終達到一致狀態。
分布式一致性
分布式一致性是指在分布式環境中對某個副本資料進行更新操作時，必須確保其他副本也會更新，避免不同副本資料不一致。分布式系統乙個重要的問題時解決資料複製,一是為了增加系統的可用性防止單點故障，二是提高系統可用性，通過負載聚恆，使分布在不同位置的資料副本能夠提供服務。理想狀態下，當然希望分布式系統能夠實現...
分布式一致性
分布式系統的乙個重要問題是資料的複製。對資料的複製一般有兩個原因 資料複製的主要難題是保持各個副本的一致性。即在更新乙個副本時，必須確保同時更新其他的副本，否則資料的各個副本將不再相同。一致性模型實質上是程序和資料儲存之間的乙個約定。正常情況下，乙個資料項上執行讀操作時，它期待該操作返回的是該資料在...
一文了解學習分布式追蹤系統 Zipkin
zipkin 基本原理架構介紹，簡單入門示例和 zipkin ui 介紹 幾種收集器 collector http rabbitmq 和 kafka 配置介紹 幾種儲存器 storage memory mysql elasticsearch 和 cassandra 配置介紹 本地日誌列印追蹤資訊配置...