弱一致系统的理想用例是什么？

Question

我一直在阅读有关分布式数据库等提供弱和强一致性保证的文章，但也许我缺乏想象力--您什么时候想使用一个弱一致性的系统？

大多数实际用例--在分布式系统中共享状态的服务，或者用户可以访问的读写服务--似乎需要很强的读写一致性。

什么样的情况对弱一致的系统有用？

Answer 1

并发

弱一致性只适用于插入或更新不依赖于先前选择的应用程序。

例如，考虑以下常见工作流：

1. 读记录
2. 让用户编辑它
3. 根据原始记录+用户的更改计算新记录
4. 保存记录

这种工作流在弱一致性下不能很好地工作，因为步骤1中读取的记录可能已经过时，保存记录可能会踩到另一个已经在运行中的更改。如果您更改FIRST_NAME而其他人更改了LAST_NAME，您中的一个可能会丢失您的更改。

另一方面，如果您插入100%的数据来自外部源的记录，则弱一致性可能是可以的。下面是一些例子：

1. 一种爬行web并在发现时存储页面信息的应用程序。
2. 发出调试日志的应用程序。
3. 一种火灾和遗忘式审计日志机制

R/I

如果有大量的R/I，弱一致性可能就不能很好地工作--例如，如果要插入包含外键的记录，则无法确定在更新传播之前，带有这些外键的记录是否仍然存在。

如果您的数据库不允许删除，这就不是什么问题了。例如，如果需要使用UserID的外键插入会话记录，并且不允许物理删除用户，则只允许禁用。

恒等式与碰撞

弱一致性数据库中的任何代理键都必须是全局唯一的；包含分区键的GUID或复合键。否则，不同的节点最终可能会插入相同的标识值，并且在数据传播时会发生冲突。

Answer 2

我们想到的唯一一个用例是Google这样的系统，它进行模糊匹配，对性能要求很高，对数据分析有总体兴趣，但并不特别担心会丢失少量的个别数据点，因为它们不会有什么关系。

在这种情况下，由于放弃数据的绝对持久性，您将获得巨大的性能好处，从而大大超过了少量数据完整性的损失。