26

I am considering a noSQL solution for a current project, but I'm hesitant about the 'eventual consistency' clause in many of these databases. Is eventual consistency different than dealing with a mySQL database where replication lags? One solution I have used in the past with lagging replication is to read from the master when immediate data consistency is needed.

However, I am confused then as to why relational database claim to have strong data consistency. I guess I should use transactions and that will give me strong consistency. Is it a good practice then to write applications assuming mySQL replication may lag?

4

2 回答 2

63

在 ACID 中使用的意义上的一致性意味着在任何更改之前和之后都满足所有约束。当系统确保您无法读取不一致的数据时，他们会说，例如，您将永远不会读取子行引用不存在的父行的数据，或者已经应用了一半事务但另一半尚未应用（教科书示例是借记一个银行帐户但尚未记入收款人银行帐户）。

MySQL 中的复制默认是异步的，或者充其量是“半同步”的。当然，在任何一种情况下它都会滞后。事实上，复制副本总是滞后至少几分之一秒，因为主服务器在事务提交之前不会将更改写入其二进制日志，然后副本必须下载二进制日志并转发事件。

但这些变化仍然是原子的。您无法读取部分更改的数据。您要么读取已提交的更改，在这种情况下满足所有约束条件，要么尚未提交更改，在这种情况下，您会看到事务开始之前的数据状态。

因此，您可能会在滞后的复制系统中临时读取旧数据，但不会读取不一致的数据。

而在“最终一致”的系统中，您可能会读取部分更新的数据，其中一个帐户已被借记，但第二个帐户尚未记入贷方。所以你可以看到不一致的数据。

没错，如果您的应用程序需要绝对最新的数据，您可能需要小心从副本中读取数据。每个应用程序对复制延迟的容忍度不同，实际上在一个应用程序中，不同的查询对延迟的容忍度不同。我对此做了一个演示：MySQL 和 PHP 的读/写拆分（Percona 网络研讨会 2013）

于 2014-09-05T18:27:53.350 回答
3

为了完整起见，我还将从 CAP 定理的角度回答这个问题。哦，ACID 中的一致性与 CAP 中的一致性不同。

就 CAP 定理中的一致性而言，即每次读取都会收到最近的写入或错误（这称为线性一致性，又名强一致性，又名原子一致性），默认情况下 MySQL 不是强一致性，因为它使用异步复制。因此，在一段时间内，组中的某些节点具有最近的写入，而某些节点仍然没有。

此外，如果您的 MySQL 版本是 8.0.14 或更高版本，那么 group_replication_consistency 是可配置的，但它的默认值仍然是 EVENTUAL（这是不可配置的，并且是我相信大多数应用程序运行的以前 MySQL 版本中的默认值）。详情：https ://dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-consistency-guarantees.html

此外，如果您使用的是 MySQL 集群（这是一种不同的产品/技术，我觉得他们称之为集群令人困惑），MySQL 文档本身说它只保证最终的一致性。详情：https ://dev.mysql.com/doc/mysql-cluster-manager/1.4/en/mcm-eventual-consistency.html

所以我们可以肯定地说这是一个最终一致的系统。并且每个异步复制的系统最终都按照定义是一致的。

于 2021-09-10T17:44:31.593 回答