我正在设计一个需要高可用性和可扩展性的应用程序，希望采用事件一致性数据模型来实现。出于多种原因，我知道并理解为什么这不是许多解决方案中受欢迎的架构选择，但在我的情况下很重要。
我正在寻找处理分布式/文档式数据库时需要注意的实际建议、最佳实践和问题点，特别是与电子商务（购物车样式）应用程序相关的领域，这些应用程序传统上使用关系型数据库更容易实现。
我知道使用这些类型的数据库具有挑战性，但 Google 和 Ebay 使用它们，所以它们肯定不是那么难 ;-) 任何建议都将不胜感激。
4个回答
18
如果您想要一个分布式系统（那个"最终一致性"的东西），则需要人来构建、维护和操作它。
我发现有三类人对"最终一致性"几乎没有什么问题：
- 有坚实分布式系统背景的人。他们学习了有关"最终一致性"拜占庭容错之类的知识。如果你了解Paxos不是关于假期的，那么你可能是其中之一。 - 有网络编程经验的人。他们可能错过了理论背景，但对异步和"无全局时钟和计数器"范例有直观的理解。如果你至少拥有 Richard Stevens八本书，那么你可能是其中之一。 - 非常有经验的程序员，但几乎没有接触过关系数据库管理系统(RDBMS)。内核开发人员、科学运算以及游戏行业的人都会被考虑在内。
总的来说，这些人在就业市场上非常受欢迎。例如，大约75%的分布式系统学者会去为运行大型自定义分布式系统的机构工作，例如证券交易所。
像Hadoop、SimpleDB和CouchDB这样的产品使整个事情变得更加简单了，但是基于分布式系统技术构建东西仍然是一个巨大的挑战。
另一方面，关系型数据库管理系统是非常出色的工程。它们被广泛理解，并且在就业市场上有相关专业知识。有很多不错的工具、教育机会和许多高技能专家可以按小时租用。因此，如果您无法使用关系型数据库管理系统方法，可以考虑再想一想——也许加上一些聪明的欺骗手段。我通常会向学生们介绍Lifejournal architecture。
对于分布式数据库，经验要少得多。这正是迄今为止您找到的建议很少的原因。
如果您决定使用"最终一致性"，除了不成熟的工具之外，主要挑战是每个人的思维方式。您的API用户（编码人员）和应用程序用户（您的员工和客户）是否愿意并能够接受不一致性？您能否将其隐藏在某些用户类别中？我们不习惯计算机不一致的思维方式。某物库存有或没有。"可能"不是用户所期望的答案。
还要记住，“最终”对于算法设计者来说可能意味着很长时间。您可以接受多长时间的不一致性？
对于购物车应用程序，您可能希望真正地进行分布式处理：使用客户端浏览器作为数据存储。在结帐时，您可以将购物车提交给服务器端批处理系统。这意味着对于目录，您需要只读高可用性（更容易），而购物车提交是一个非常窄的接口，不需要事务。稍后订单的处理没有（软）实时要求，因此更容易。
我发现有三类人对"最终一致性"几乎没有什么问题：
- 有坚实分布式系统背景的人。他们学习了有关"最终一致性"拜占庭容错之类的知识。如果你了解Paxos不是关于假期的，那么你可能是其中之一。 - 有网络编程经验的人。他们可能错过了理论背景，但对异步和"无全局时钟和计数器"范例有直观的理解。如果你至少拥有 Richard Stevens八本书，那么你可能是其中之一。 - 非常有经验的程序员，但几乎没有接触过关系数据库管理系统(RDBMS)。内核开发人员、科学运算以及游戏行业的人都会被考虑在内。
总的来说，这些人在就业市场上非常受欢迎。例如，大约75%的分布式系统学者会去为运行大型自定义分布式系统的机构工作，例如证券交易所。
像Hadoop、SimpleDB和CouchDB这样的产品使整个事情变得更加简单了，但是基于分布式系统技术构建东西仍然是一个巨大的挑战。
另一方面，关系型数据库管理系统是非常出色的工程。它们被广泛理解，并且在就业市场上有相关专业知识。有很多不错的工具、教育机会和许多高技能专家可以按小时租用。因此，如果您无法使用关系型数据库管理系统方法，可以考虑再想一想——也许加上一些聪明的欺骗手段。我通常会向学生们介绍Lifejournal architecture。
对于分布式数据库，经验要少得多。这正是迄今为止您找到的建议很少的原因。
如果您决定使用"最终一致性"，除了不成熟的工具之外，主要挑战是每个人的思维方式。您的API用户（编码人员）和应用程序用户（您的员工和客户）是否愿意并能够接受不一致性？您能否将其隐藏在某些用户类别中？我们不习惯计算机不一致的思维方式。某物库存有或没有。"可能"不是用户所期望的答案。
还要记住，“最终”对于算法设计者来说可能意味着很长时间。您可以接受多长时间的不一致性？
对于购物车应用程序，您可能希望真正地进行分布式处理：使用客户端浏览器作为数据存储。在结帐时，您可以将购物车提交给服务器端批处理系统。这意味着对于目录，您需要只读高可用性（更容易），而购物车提交是一个非常窄的接口，不需要事务。稍后订单的处理没有（软）实时要求，因此更容易。
顺便说一句：上次我查看E-Bay的架构时，他们在关系型数据库方面很强大，但自那以后可能已经发生了变化。（编辑：确实发生了变化-请参见评论）
- mdorseif
3
2我认为这部分是半开玩笑的：根据他自己的网页，W. Richard Stevens 只出版了七本书！ - James A. Rosen
2我不知道为什么在“可能”这部分笑了起来...一直想象着亚马逊告诉我他们可能有某个库存，而我可能已经被收费了，但他们会回复我。 - Merritt
@Merritt 这正是后台发生的事情，但除非您真的遇到碰撞（两个人同时下单）并且他们无法快速补货，否则他们不会告诉您。 - max
5
你的问题唯一的解决方案就是决定在CAP定理中做出哪些权衡，然后开始实施。
mdorseif有一个很好的观点。一致性、可用性和分区的权衡有许多配置选项。你有两个主要选择。
1.走内部分布式系统的路线（需要大量专业知识和研究）。 2.审核和尝试一些分布式数据库，以确定哪些可以处理你的规模需求。
这可能是一个过度简化的描述。一个真正的生产就绪的管道是一个生态系统。至少能让你走上正确的轨道。 Appnexus是一个广告平台，使用hbase进行高可用性和最终一致性。他们在这里谈论了很多。
mdorseif有一个很好的观点。一致性、可用性和分区的权衡有许多配置选项。你有两个主要选择。
1.走内部分布式系统的路线（需要大量专业知识和研究）。 2.审核和尝试一些分布式数据库，以确定哪些可以处理你的规模需求。
这可能是一个过度简化的描述。一个真正的生产就绪的管道是一个生态系统。至少能让你走上正确的轨道。 Appnexus是一个广告平台，使用hbase进行高可用性和最终一致性。他们在这里谈论了很多。
一篇文章在http://highscaleability.com上概述了纽约时报如何在WAN上实现RabbitMQ和Cassandra以实现容错和高可用性。
MongoDB通过写入关注点的实现提供了很大的灵活性，可以平衡一致性和可用性。他们有出色的文档，详细介绍了如何使用它以及所有的注意事项（包括分区）。他们实施两阶段提交来维护网络上的状态（在其配置服务器上）。
谷歌在这个主题上有一篇很棒的论文，他们的photon项目实现了一个高度可扩展、高度可靠的系统，其中心是paxos算法和其他几种技术。它也恰好非常一致（端到端延迟约为10秒），容错性强，可以抵御区域性故障。- KeatsKelleher
0
所有基于分布式计算模型的系统都建立在CAP和BASE之上。这里的主要问题是，如果我们的系统提供可用性和分区容错性，我们就无法实现真正的一致性，但我们可以实现最终一致性。
最终一致性背后的思想是，每个节点始终可用于服务请求。作为权衡，数据修改会在后台传播到其他节点。这意味着系统随时可能不一致，但数据仍然大体准确。
来源: http://www.techspritz.com/eventual-consistency-and-base-model/
- Ananda
-1
如何使用关系型数据库实现高可用性和可扩展性是众所周知的，有大量的知识可以用来指导如何做到这一点！
谷歌是一个特殊情况，不适用于大多数网站，它有非常高的查询量、非常大量的数据，并且最重要的是，与大多数用户没有服务级别协议。在Web搜索中没有正确答案，只有更好的答案，对于普通用户来说，谷歌已经足够好了，如果谷歌在搜索列表中漏掉了一个重要页面，作为用户你也不能抱怨。
E-Bay是一个相当不同的情况，他们以理论上更低的价格换取用户和客户接受较差的服务 - 这对他们来说很好，但这并不是每个企业的选择。
- James Anderson
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接