Eventual Consistency and Strong Consistency
https://www.keboola.com/blog/eventual-consistency
What is eventual consistency and why should you care about it?
The anatomy of distributed storage
分布式数据库，将数据副本存储在世界上不同的地区。
Distributed storage is achieved via database replication. The data is replicated across several distinct nodes or servers. The nodes communicate with each other through network and data replication protocols that are specific to the database architecture.
Each replica has a copy of (all) the data. And therefore has the resources to serve all the read and write requests client applications send to that node.
这种数据冗余的设计，拥有以下优点：
低时延
高性能
高可用
With this redundancy (data being kept in multiple copies) distributed databases achieve their advantage: low latency happens because clients can access data closer to them instead of querying across the globe, high performance and high availability are achieved by distributing the query loads across the system instead of burdening just one node, and scaling is made simple and affordable - just add another node.
The CAP theorem and the trade-off between high availability and high consistency
分布式存储系统有三个被希望的品质：
一致性
可用性
分区容错性
Distributed storage systems have three desirable qualities:
- Consistency - any given data item within the system looks and behaves the same irrespective of which node we query to access said item.
- Availability - the system will always return a valid response, even if nodes are unavailable or shut off from the system.
- Partition tolerance - the system performs well even when parts of the system get cut off due to network or other issues (these are called network partitions).
The CAP theorem states that a distributed system can guarantee at most two out of three at all times. So for the majority of the time, distributed systems work great. But when they malfunction, we need to make a design choice of which two desirable characteristics to keep.
What exactly is the trade-off?
CP 强调一致性 优先于 可访问性
AP 强调 可访问性 优先于 一致性
“Building reliable distributed systems at a worldwide scale demands trade-offs between consistency and availability.” - Werner Vogels
Handling partition cases is the foundation of distributed databases. So we cannot sacrifice the partition tolerance when we talk about distributed databases.
A consequence of the CAP theorem, therefore, is that we either have CP systems, consistent and partition tolerant, or AP systems, available and partition tolerant systems.
Systems that prioritize high availability over consistency will make the system available for read and write requests at all times. Even if the node being queried is out of sync (due to network partitions - read: failures) and it returns stale data that does not reflect the system-wide new updates, the system will respond.
On the other hand, systems that prioritize consistency over system availability will reject read or write requests rather than accept or send data that would be inaccurate with the other nodes in the system.
The two design patterns - CP and AP - are not completely inconsistent. Because partition tolerance is observed, the systems still operate a kind of consistency, despite not being the one specified by the CAP theorem.
CP systems employ a type of consistency called “strong consistency”. While AP systems guarantee a type of consistency called “eventual consistency”
Two types of consistencies: strong consistency v eventual consistency
https://levelup.gitconnected.com/eventual-consistency-and-strong-consistency-d0b882133ca5
Eventual Consistency
Eventual consistency guarantees that if an update is made to the data of a node (say node N), then the updated value will eventually be propagated to all the replicas of that node and eventually all the replica will become consistent to the original node(N). Nodes will get eventually consistent means it will take time for updates to reach other replicas.
Hence eventual consistency is a consistency model used to achieve high availability and is a weak consistency model.
Nodes that have achieved eventual consistency is often said to have converged, or achieved replica convergence.
Eventual Consistency
Eventual consistency offers high availability(low latency) at the risk of returning stale data.
The most popular system that implements eventual consistency is DNS (Domain Name System). Updates to a domain name are distributed according to a configured pattern and in combination with time-controlled caches; eventually, all clients will become consistent or see the update.
Strong Consistency
In contrast to eventual consistency, Strong consistency guarantee that if an update is made to a node (say N), then the updated value will be propagated to all the replicas(N1 & N2) of the node(N), immediately in other words after the update completes, any subsequent access (to N, N1, or N2) will always return the updated value.
Note during the time these replicas are being updated with new data, any read/write request to any of these replicas will get delayed as all replicas are busy in keeping each other consistent and once they will become consistent with the original node they will start accepting read/write request again.
As opposed to eventual consistency in strong consistency, always only one consistent state will be observed.
Strong Consistency
Eventual consistency offers low availability(high latency) but always returns fresh/updated data.
Strong/eventual consistency vs consistency in ACID
ACID中的一致性，是说数据操作过程和结果的性质。
强/最终一致性 是说数据在不同节点之前的内容之间的同步的行为。
We should not mistake strong/eventual consistency with the consistency guarantee of ACID databases.
In an ACID-compliant system, transactions - aka changes to the database - have the properties of atomicity, consistency, isolation, and durability.
The consistency guarantees in ACID mean that any transaction executed over the database will leave the database in a valid or consistent state after the transaction has been committed.
The “valid or consistent state” refers to business rules specified as integrity, referential, not null, or other SQL constraints.
For example, if the entity table customers has a not-null constraint over the customer_email field, an operation that tries to insert a new row into the table with customer_email=null will be aborted and rolled back.
On the other hand, strong/eventual consistency refers to data consistency over nodes (not databases) at any given time. Aka, whether different nodes have the same information for a given data item at all times.
Eventual consistency in practice
DNS服务器，就是最终一致性的
一些金融交易数据，是要求强一致性的
其它非关键数据，一般要求最终一致性就可以了，例如 点赞数据。
How acceptable eventual consistency is, depends on the client application.
The trade-off between the system’s non-responsiveness but strong consistency on one hand versus a highly responsive system with eventual consistency, on the other hand, is purely a business one.
Popular systems have been built with eventual consistency. For example, the Domain Name System (DNS) resolving domain names into web addresses is based on eventual consistency. Without DNS the internet would not run as smoothly as it does.
Generally, people put forward the argument that financial transactions (shopping carts, order processing, etc.) need to be strongly consistent, while product features, like Facebook’s feed, Twitter’s recommendations, etc. do not need to reflect the universally last updated value in the database and can be eventually consistent. Because we can enjoy the Facebook feed even if we do not see the latest friends’ posts. While a sluggishly updated banking account could cause financial problems.
But in reality, even financial institutions often deploy eventually consistent systems with warnings in their terms and conditions stating it might take up to 24h to fully process a transaction.
This is because eventual consistency is consistent for the majority of the time. And the frustration of service unavailability in highly consistent systems usually causes more grumpy customers.
Ultimately, though, the design choice of whether you will deploy a strongly consistent system or an eventually consistent system will reflect your business needs.
