1樓：brightpig
consistent: 多個replicas之間的資料相同；
defined：每個client最初寫入指定offset的資料和後來從offset讀出的資料相同；
對於Write：
並行寫時，client-A和client-B同時寫乙個檔案的同乙個offset時，GFS能保證A和B都先後寫入成功。假設A先寫，B後寫，那麼A的資料就被覆蓋掉，A從offset讀出的資料不是最開始寫入的。因為GFS能保證每個replica的資料相同，所以這時是 consistent but undefined.
2樓：
一致性（consistent）：無論從哪個副本上讀取，讀到的資料都一樣。
己定義（defined）：每一次的修改（寫入或追加）都是可追溯的（通過日誌檔案），即一組修改操作（mutation）可以序列化。
序列成功：即滿足一致性，又本身是序列化的。
並行成功（寫入）：由於是應用程式指定寫入偏移位置，就算結果是一致的了，也無法讀到每一次寫入的中間資料。
並行成功（追加）：由GFS分配寫入的偏移量，通常結果是一致的，中間的修改過程也一致。
但是在一些情況下，GFS會在文間中插入填充資料或者重覆記錄，也被認為是不一致。
3樓：
Writer
::Write
(handle
,offset
,data
)// thread 0
WriterA;
A.Write
(handle,0
,"rofl"
);a_data
=ReadFrom
(handle
);// thread 1
WriterB;
B.Write
(handle,0
,"imfao"
);b_data
=ReadFrom
(handle);
4樓：左若塵
一致指的是不同客戶端看到的檔案內容一樣，但是可能這些檔案內容不是最新的，這樣就屬於未定義。
已定義是指客戶端看到的內容不僅全部一樣，而且是經過修改後最新的檔案內容。
修改很早回答，有些沒說清楚，defined其實更深層的含義在於乙個客戶端寫檔案，之後讀能否讀出之前寫的檔案，也就是說和自己的寫的是否一致。
在追加模式下，這個是可以做到的，因為每次的記錄追加都是原子操作。但是在write中，並行寫可能造成資料交叉，那麼對於客戶端來說，不同客戶端讀到的資料是一致的，但是讀出來的內容是一種未定義的狀態。追加模式由於保留了每個客戶端的原子追加，由於存在追加失敗之類的異常情況，同為副本的資料伺服器上存有的資料可能並不一致（因為空洞或者是重複資料）。
所以我認為這個地方，一致應該從資料伺服器來考慮，定義要從客戶端來考慮。
flink中一致性檢查點，這個一致性怎麼理解，是什麼和什麼一致，跟分布式中一致性演算法一樣嗎？
歡歌 從物理意義上，checkpoint 分布式快照是乙個有意義的系統狀態，但不一定對應某個時刻的狀態 沒法讓所有節點在同乙個時刻拍照 一致性的含義是 不違背事件間固有的因果關係，即如果系統裡面有兩個事件 e1 和 e2，且 e2 依賴於 e1，那麼快照不能只包含了 e2，但是卻沒有包含 e1。舉個...
如何評價一致性演算法 PacificA ？
辛塞凱諾卡密 有一點我覺比較爽，省去了集群自選舉的邏輯，把這件事交給Nameserver做，直接判斷PreparedList的完整性以及First Win即可。 laliliu 個人覺得PacificA沒有Paxos，Raft流行，可能跟msra沒有強力推廣也有關，另外，感覺PacificA有不少v...
關於kafka的一致性的疑問？
胡明 可以看一下這個 huxihx 說說我的淺見 kafka的old leader由於gc等原因soft fail的時候選舉了新的leader，那麼old leader回來時會發生什麼情況？如果broker因為某些原因 像你所說的long gc 導致與Zk的會話斷開，那麼依託於Zk的watch機制，...