第五章 資料一緻性

　　關系型資料庫：強一緻性；

　　NoSQL： CAP原理與 最終一緻性。

5.1 更新一緻性

　　在單伺服器資料庫中，用序列化的方式保證一緻性。

　　在叢集環境中，資料有多分拷貝，必須要用“順序一緻性”保證所有節點以相同的順序執行。

5.2 讀取一緻性

　　關系資料庫用“事務”來解決讀取一緻性的問題。（不讓一個讀取操作讀取到另外一個操作的中間結果。）

　　部分NoSQL資料庫不支援事務。

　　面向聚合的資料庫通常支援“原子操作”，但僅限于單一聚合内部。如果把訂單、運費、商品全部放入一個訂單聚合中，則可以避免“邏輯不一緻”

　　我們不能把資料都放在一個聚合中，是以在執行影響多個聚合的操作時，會有一段“不一緻視窗”，資料最終會一緻，叫做“最終一緻性”。在資料存在備援的叢集中，這個不一緻視窗可能比較長。

　　“黏性會話”：保證情況都發到一個節點。

5.3 放寬“一緻性”限制

　　事務影響性能，很多資料庫棄用事務，放寬一緻性需求。

　　CAP定理：一緻性，可用性，分區耐受性(發生通信故障，導緻整個叢集被分割成多個無法互相通信的分區時，也就是腦裂，叢集任然可用。)

　　不一緻的問題，一般是可以容忍的，不能完全以來開發，更需要業務領域專家。

 5.4 放寬“持久性”限制

　　把一些資訊存儲到記憶體中（比如使用者會話）以提高相應速度 ，帶來的問題是，記憶體資料可能丢失。