我正处于设计必须具有高可用性和可扩展性的应用程序的早期阶段。出于多种原因，我想为此使用最终一致性数据模型。我知道并理解为什么对于许多解决方案来说这是一个不受欢迎的架构选择，但在我的情况下它很重要。
我正在寻找现实世界的建议、最佳实践和在处理分布式/文档式数据库时要注意的问题。尤其是围绕电子商务（购物车风格）应用程序的领域，这些应用程序传统上更容易与关系数据库组合在一起。
我知道使用这些类型的数据库具有挑战性，但是，嘿，谷歌和 E-bay 使用它们，所以它们不会那么难；-) 任何建议都将不胜感激。
如果你想拥有一个分布式系统（即“最终一致性”的东西），你需要人来构建、维护和操作它。
我发现有三类人对“最终一致性”的问题很少：
总而言之，这些人在就业市场上很受追捧。例如，75% 左右的分布式系统学者离开了运行大型、自行设计的分布式系统的机构，例如证券交易所。
借助 Hardoop、SimpleDB 和 CouchDB 等产品，整个事情变得更加简单，但在分布式系统技术上构建一些东西仍然是一个巨大的挑战。
另一方面，RDBMS 是一个非常好的工程。他们广为人知，他们的专业知识可在就业市场上获得。有很多不错的工具、教育机会和许多高技能的专家可以按小时租用。因此，请三思而后行，您无法继续使用 RDBMS 方法——也许再加上一些巧妙的作弊。我通常会向学生介绍 Lifejournal 架构。
对于分布式数据库，经验要少得多。这正是您迄今为止发现的建议如此之少的原因。
如果您决心使用“最终一致性”，我认为除了不成熟的工具之外，主要挑战是每个相关人员的心态。您的 API 用户（编码人员）和应用程序用户（您的员工和客户）是否愿意并且能够接受这种不一致？您可以对某些类别的用户隐藏它吗？我们不习惯计算机不一致的心态。有货或没有货。“也许”不是用户期望的答案。
还要记住，“最终”对算法设计者来说可能意味着很长一段时间。你能接受多长时间的不一致？
对于购物车应用程序，您可能希望真正实现分布式：使用客户端浏览器作为数据存储。在结帐时，您可以将购物车提交到服务器端批处理系统。这意味着对于目录，您需要只读高可用性（更容易），并且购物车提交是一个非常狭窄的界面，不需要交易。稍后处理订单没有（软）实时要求，因此更容易。
顺便说一句：上次我检查 E-Bay 架构时，它们在 RDBMS 中的位置很大，但从那时起它可能已经发生了变化。（编辑：它确实改变了 - 见评论）
解决您的问题的唯一方法是确定CAP 定理中的哪些权衡适合您，然后开始实施它。
mdorseif 有一个很好的观点。有许多配置可以在多大程度上权衡一致性、可用性和分区。您有两个主要选择。
这可能过于简单化了。真正的生产就绪管道是一个生态系统。它至少会让你走上正轨。
Appnexus是一个使用hbase实现非常高可用性和最终一致性的广告平台。他们在这里谈了很多。
http://highscaleability.com上的一篇文章概述了《纽约时报》如何在 WAN 上实现RabbitMQ和Cassandra以实现容错和高可用性。
MongoDB在平衡一致性和可用性以及写入问题的实现方面提供了很大的灵活性。他们有优秀的文档，准确地强调了如何使用所有的陷阱（包括分区）来实现它。他们实现了两阶段提交来维护整个网络的状态（在他们的配置服务器上）。
谷歌在这个主题上有一篇很棒的论文，他们的光子项目实现了一个高度可扩展、高度可靠的系统，其核心是 paxos 算法以及其他一些技术。它也恰好是非常一致的（端到端延迟约为 10 秒）和容错性，能够承受区域故障。
所有建立在分布式计算模型上的系统都建立在 CAP 和 BASE 之上。这里主要关注的是，如果我们的系统提供可用性和分区容错性，我们就不能拥有真正的一致性，但我们可以拥有最终的一致性。
最终一致性背后的想法是每个节点始终可用于服务请求。作为权衡，数据修改在后台传播到其他节点。这意味着系统在任何时候都可能不一致，但数据在很大程度上仍然是准确的。
资料来源：http ://www.techspritz.com/eventual-consistency-and-base-model/
如何使用关系数据库实现高可用性和可扩展性是众所周知的，并且有大量关于如何做到这一点的知识！
谷歌是一个特例，它不适用于大多数网站，查询量非常大，数据量非常大，最重要的是，它的大多数用户都没有服务水平协议。网络搜索没有正确的答案，只有更好的答案，对于普通用户来说，谷歌已经足够好了，如果谷歌错过了搜索列表中的重要页面，你作为用户就不能抱怨。
E-Bay 是一个相当不同的例子，他们以某种方式说服用户和客户接受低劣的服务以换取理论上更低的价格——这对他们来说很好，但这并不是每个企业都可以选择的。