Distributed Systems 7.3: Eventual consistency
Vložit
- čas přidán 9. 07. 2024
- Accompanying lecture notes: www.cl.cam.ac.uk/teaching/212...
Full lecture series: • Distributed Systems le...
This video is part of an 8-lecture series on distributed systems, given as part of the undergraduate computer science course at the University of Cambridge. It is preceded by an 8-lecture course on concurrent systems for which videos are not publicly available, but slides can be found on the course web page: www.cl.cam.ac.uk/teaching/212...
I already immensely enjoyed the DDIA book, but for me being more of a visual/interactive learner this is just a total gem. Thanks a lot for making those lectures public, Martin!
Good stuff martin! Please keep updating new lectures from DDIA
Eventual consistency
Linearizability advantages
Linearizability Downsides [0:32]
(calendar app example) [2:13]
(phone airplane mode conflict) [3:08]
The CAP theorem [4:59]
Eventual consistency [6:31]
Strong eventual consistency [7:55]
Eventual delivery
Convergence [8:23]
Properties [9:13]
Summary of minimum system model requirements [11:01]
atomic commit
consensus | total order broadcast | linearizable CAS
linearizable get/set
eventual consistency | causal broadcast | FIFO broadcast
That calendar example was so good sir. Thanks!
You have an outstanding ability to explain things, thanks for the effort. I hope to see more from you.
I am preparing for system design interviews and this video is one of the gems in my collection now
Great presentation ! Thank you for sharing.
Very well explained.thanks for sharing.
Great Content Shree Martin .. thanks for sharing such good insights across all your videos.
I really liked the presentation of the calendar example. I‘ve heard this example before but not as well presented as here.
13:40 Linearizable get/set would need quorum + _synchronous_ read repair right? If the read repair is done asynchronously, another get operation could execute before the read repair happens and get an older value from stale replicas thus violating linearizability.
exactly what i was thinking about, how it need a quorum and async ?
the calendar example was impressive
Excellent material.
In case of eventual consistency where read and writes are processed at local, how we can guarantee durability if local crashes after acknowledgement of write but further disseminating to other nodes?
If the isolated node in the Quorum receives user update and crash (by example hard vm & disk crash, you are not lucky), it means that the Eventual Consistensy implies data loss when network failures happens ? In the example of the Calendar, it could lead to a calendar entry totaly removed.
Good point, although it doesn't seem like a proper formal definition of eventual consistency was given, it sounds like that situation would violate the invariant that all replicas end up in the same state. Eventual delivery fixes this by only talking about non-faulty replicas.
Interesting point! Maybe a new data object being created locally in an isolated/partitioned node involves some bit updates/logging to the local permanent storage? Since otherwise not having an internet connection would mean the calendar app loses a perfectly valid new entry after a crash.
No it won't, because if it was written to the oplog of the replica before the crash, then it would reflect the change in the replica, and if it's not written in the oplog, the replica would copy all the transactions until it's oplog looks same as the oplog of the master node.
Anyone know the "AVD" algorithm that he's talking about? Hard to google
How the last write win policy working?
Last write was made by iphone and not mac!
I think this is kind of misleading, as the info got lost just because the network was cut off and could not even make a write to server.
Last write was made by the Mac (edit: iPhone) only if write order is defined by actual time of the day (physical clock). It it is instead defined by logical clocks, like Lamport clocks, it could be the case that both writes had the same Lamport clock, but the Mac won out because it had a lesser node ID, for example.
@@vhscampos1 I am a little confused about the first part of your answer. According to the physical clock, isn't the case that the last write was made by iPhone, not Mac? I think it makes sense that it's actually "defined by logical clocks". And when logical clocks are the same, they compare node ID to decide who makes the last write.
@@florayym My mistake indeed. I meant iPhone where I wrote Mac.
@@yihanwu3823 Agreed. It was offline. Zero communication with any replicas. So when it came back online it got updated with the latest. The offline phone update was a never written. So there is no such thing as LAST WRITE in this case. So yes, I agree with you that this example was off, and misleading.