資料庫一致性（database consistency）
是指事務執行的結果必須是使資料庫從乙個一致性狀態變到另乙個一致性狀態。
保證資料庫一致性是指當事務完成時，必須使所有資料都具有一致的狀態。在關係型資料庫中，所有的規則必須應用到事務的修改上，以便維護所有資料的完整性。
保證資料庫的一致性是資料庫管理系統的一項功能.比如有兩個表(員工\職位),員工表中有員工**、姓名、職位**等屬性，職位表中有職位**、職位名稱、職位等級等屬性。你在其中員工表中進行了插入操作,你插入了乙個新員工的資訊，而這個新員工的職位是公司新建立的乙個職位。如果沒有一致性的保證，就會出現有這麼乙個員工，但是不知道他到底擔當什麼職責！這個只是它的乙個小小方面。
讀一致性也是資料庫一致性的乙個重要方面,在實際中,我們會遇到這種情況:我們對乙個表中的某些資料進行了更新操作,,但是還沒有進行提交,這時另外乙個使用者讀取表中資料.這個時候就出現了讀一致性的問題:到底是讀什麼時候的資料呢?是更新前的還是更新後的?在dbms中設有臨時表,它用來儲存修改前的值,在沒有進行提交前讀取資料,會讀取
臨時表中的資料,這樣一來就保證了資料是一致的.(當前使用者看到的是更新後的值)
但是還有一種情況:使用者user1對錶進行了更新操作,使用者user2在user1還沒有進行提交前讀表中資料,而且是大批量的讀取(打個比方:耗時3分鐘)而在這3分鐘內user1進行了提交操作,那又會產生什麼影響呢?這個時候怎麼保證讀寫一致性呢?這個時候dbms就要保證有足夠大的臨時表來存放修改前的數值,,以保證user2讀取的資料是修改前的一致資料.然後下次再讀取時候就是更新後的資料了.
資料庫的強一致性和弱一致性
強一致性可以理解為在任意時刻，所有節點中的資料是一樣的。同一時間點，你在節點a中獲取到key1的值與在節點b中獲取到key1的值應該都是一樣的 弱一致性 相當於非同步 系統並不保證續程序或者執行緒的訪問都會返回最新的更新過的值。系統在資料寫入成功之後，不承諾立即可以讀到最新寫入的值，也不會具體的承諾...
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
快取和資料庫一致性
對應比較常用的資料，比如鑑權資料一般會放在快取中 比如 redis 這樣能夠跟快的實現讀取，所以一般讀取流程如下 目前網上有很多關於快取和資料庫怎麼保持一致性的文件，主要可以總結為如下幾點 1 先更新資料庫，在更新快取 2 先刪除快取，在更新資料庫 3 先更新資料庫，在刪除快取 下面將對著幾種機制作...