最终的一致性

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

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

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

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

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

在分布式系统中具有扎实背景的人.他们已经了解了最终的一致性拜占庭失败等等.如果您了解Paxos与假期无关,那么您可能就是其中之一.

有网络编程经验的人.他们可能会错过理论背景,但对异步性和"无全局时钟和计数器"范例有直观的理解.如果你拥有Richard Stevens至少8本书,你可能就是其中之一.

非常有经验的编码员几乎没有接触过RDBMS.考虑到内核人员,科学计算和游戏行业的人们.

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

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

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

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

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

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

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

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