最终的一致性

Question

我正处于设计应用程序的早期阶段,该应用程序必须具有高可用性和可扩展性.出于多种原因,我想为此使用最终的一致性数据模型.我知道并理解为什么这是许多解决方案不受欢迎的架构选择,但在我的案例中这很重要.

我正在寻找真实世界的建议,最佳实践以及在处理分布式/文档式数据库时需要注意的问题.尤其是电子商务(购物车风格)应用程序周围的区域,传统上更容易与关系数据库组合在一起.

我知道使用这些类型的数据库具有挑战性,但是嘿,Google和E-bay使用它们所以它们不能那么难;-)任何建议都会受到赞赏.

Answer 1

如果你想拥有一个分布式系统(即"最终一致性"的东西),你需要人,建立,维护和操作它.

我发现有三类人对"最终一致性"的问题很少:

在分布式系统中具有扎实背景的人.他们已经了解了最终的一致性拜占庭失败等等.如果您了解Paxos与假期无关,那么您可能就是其中之一.
有网络编程经验的人.他们可能会错过理论背景,但对异步性和"无全局时钟和计数器"范例有直观的理解.如果你拥有Richard Stevens至少8本书,你可能就是其中之一.
非常有经验的编码员几乎没有接触过RDBMS.考虑到内核人员,科学计算和游戏行业的人们.

总而言之,这些人在就业市场上非常受欢迎.例如,分布式系统中75%左右的学者会选择运行大型自行设计的分布式系统的机构,例如证券交易所.

使用Hardoop,SimpleDB和CouchDB等产品,整个过程变得更加简单,但在分布式系统技术上构建东西仍然是一个巨大的挑战.

另一方面,RDBMS是一个非常精细的工程方法.他们很了解,就业市场上也有专业知识.有很多不错的工具,教育机会和许多高技能专家可以按小时租用.因此,三思而后行无法继续采用RDBMS方法 - 可能还会加上一些聪明的作弊行为.我通常会将学生指向Lifejournal架构.

对于分布式数据库,经验要少得多.这正是你到目前为止找到这么少建议的原因.

如果您决定使用"最终一致性",我认为除了不成熟的工具之外,主要的挑战是每个参与者的心态.您的API用户(编码人员)和应用程序用户(您的员工和您的客户)是否愿意并且能够接受不一致？你能从某些类别的用户中隐藏它吗？我们不习惯计算机不一致的心态.有东西有货或不是."也许"不是用户期望的答案.

还要记住,"最终"对算法设计者来说意味着很长的时间.您有多长时间可以接受不一致？

对于购物车应用程序,您可能希望真正分布式:使用客户端浏览器作为数据存储.在结账时,您可以将购物车提交到服务器端批处理系统.这意味着对于目录,您需要只读高可用性(更容易),并且购物车提交是一个非常狭窄的界面,不需要交易.后来处理订单没有(软)实时要求,因此更容易.

顺便说一句:上次我检查过E-Bay架构时,他们在RDBMS中占据了很大的位置,但从那时起它可能已经发生了变化.(编辑:它确实发生了变化 - 见评论)

Answer 2

解决您的问题的唯一方法是确定CAP 定理中的哪些权衡适合您，然后开始实施它。

mdorseif 有一个很好的观点。有多种配置可以在多大程度上权衡一致性、可用性和分区。您有两个主要选择。

这可能是一种过度简化。真正的生产就绪管道是一个生态系统。它至少会让你走上正轨。

Appnexus是一个使用hbase实现高可用性和最终一致性的广告平台。他们在这里谈论了很多。

http://highscaleability.com上的一篇文章概述了纽约时报如何通过 WAN与Cassandra一起实施RabbitMQ以实现容错和高可用性。

MongoDB提供了很大的灵活性，可以在一致性与可用性之间以及写入关注的实现之间取得平衡。他们有出色的文档，准确地强调了如何使用所有问题（包括分区）来实现它。他们实施两阶段提交以维护整个网络的状态（在他们的配置服务器上）。

谷歌在这个主题上有一篇很棒的论文，他们的光子项目实现了一个高度可扩展、高度可靠的系统，其核心是 paxos 算法以及其他一些技术。它也恰好非常一致（端到端延迟约为 10 秒）和容错，能够承受区域故障。

Answer 3

如何使用关系数据库实现高可用性和可扩展性是众所周知的，并且有大量关于如何做到这一点的知识！

谷歌是一个特例，不适用于大多数网站、非常非常大量的查询、非常非常大量的数据，而且最重要的是，它与大多数用户没有服务级别协议。网络搜索没有正确的答案，只有更好的答案，对于普通用户来说，Google 已经足够好了，如果 Google 错过了搜索列表中的重要页面，作为用户，您不能抱怨。

eBay 是一个相当不同的例子，他们以某种方式说服了那里的用户和客户接受糟糕的服务，以换取理论上较低的价格——这对他们来说很好，但这并不是每个企业的选择。