Eventual Consistency

Giriş

Eventual Consistency BASE Properties For Distributed Database Transactions özelliklerinden bir tanesi. Diğer consistency seviyeleri şöyle

1. Strict Serializability

2. Linearizability

3. Sequential Consistency

4. Causal Consistency

5. Eventual Consistency

Eventual Consistency Nedir?
Eventually Consistency bir güncelleme işleminden sonra, eğer bir başka güncelleme işlemi daha olmazsa, yeni verinin hemen olmasa bile ileri bir zamanda yani önünde sonunda tüm düğümlerde aynı değere sahip olması demek. Açıklaması şöyle.

One of these challenges is eventual consistency, which is a consistency model used in distributed computing to achieve high availability. It guarantees, informally, that if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value. The problem with this model is that many systems need an always consistent model because the data always needs to show the most recent value. If we take for example a bank account, we cannot build the system on top of a solution that will at some point be inconsistent.

Apache Cassandra bu konuya bir örnek olarak verilebilir. Açıklaması şöyle.

The disadvantage of non-transactional platforms (Cassandra, for example) is that although one could avoid the locking of shared resources by linearly scaling out the data across the cluster (assuring availability), it comes at the cost of consistency.

Yani yazma işleminin sonucunu okuma işleminde hemen görmeyebiliriz. Açıklaması şöyle

Eventually consistent implies the read-after-write of a value may not yield the latest value written.

Eventual Consistency bir sistemin/iletişimin sadece dağıtık olması durumunda değil aynı zamanda yavaş olması durumunda da kullanılır. Açıklaması şöyle.

How did bank transactions (or “data” transactions) work when it took people weeks to travel vast distances?
...
No attempt was made at "atomicity", rather, the goal was "eventual correctness", where the money eventually ended up in the correct place.

Örnek - DNS Sistemi

Açıklaması şöyle. DNS güncellemelerinin sonucu hemen görülmez.

There are many use cases where eventual consistency is okay as strict data consistency is not required. For example, Domain Name System (DNS) is based on an eventual consistency model. Multiple intermediate caches contain the DNS entries. If someone updates a DNS entry, these are not immediately updated, but rather, the DNS queries are done after a cache timeout is done on the local entries. Since an update on DNS entry is not frequent, doing a new DNS query for every name resolve is just overkill and will be a major network performance bottleneck. So having an outdated entry in DNS for a user is tolerable. In the same way, there are many other real-world situations where we would do this. We will implement other workarounds to detect this type of outdated data or inconsistencies and take appropriate action at that point, rather than being pessimistic and making all the operations fully consistent and incurring a considerable performance hit.

Örnek - Hava Sıcaklığı

Açıklaması şöyle

Practically, this consistency model is fine for use cases where they are only concurrent value updates and there are no connections between the values when they are updated; users don’t care about the intermediate values, just the final stable value it ends up with. For example, let’s take a website that posts the current temperature for each city. These values change from time to time. At some point, some users may see the latest temperature value, while others have still not been updated. However eventually, the data update will be caught up with all the users of the website. So this possible propagation delay of a distributed database that stores these values is not a big issue as long as in the end, all users will eventually see the same temperature values.