系统架构师角色的一个关键方面是权衡冲突的需求并决定解决方案,通常是通过将一个方面与另一个方面进行权衡。 随着系统变得越来越大,越来越复杂,越来越多关于如何构建应用程序的传统智慧正在受到挑战。 例如,去年3月在伦敦召开的QCon会议上,Dan Pritchard就eBay的架构发表了演讲。 从他的演讲中获得大量后续报道的主要内容之一是eBay不使用事务,事务丢失简单的数据一致性,以显着改善其系统的整体可扩展性和性能。
在他的演讲之后,InfoQ与Dan Pritchard进行了交谈,以获取更多信息:
为什么eBay不使用交易,或者如何决定应用程序级交易?
并不是我们不使用事务。我们只是不使用跨物理资源的事务,因为它跨多个组件创建了依赖关系。组件可以是应用程序服务器和数据库(例如客户端管理的事务),因为客户端故障可能会占用数据库资源的时间超过我们可以容忍的时间。我们也不使用分布式事务,因为使应用程序依赖于多个数据库会降低客户端的有效可用性。相反,我们选择设计缺少事务并构建故障模式,即使在数据库可用性问题的情况下,客户端也能成功。
应用程序级别的事务总是有些问题。无论何时您要求开发人员管理资源生命周期,您都将面临管理出错时出现的错误。事务与内存没什么不同,我们看到语言的一般趋势是由于生命周期问题而从开发人员那里消除内存管理的责任。声明性事务(例如EJB中的事务)是[a]简化事务管理的大锤方法,假设bean背后的每个数据库操作都同等重要。
决定是否使用事务实际上取决于您的可伸缩性和可用性目标。如果您的应用程序需要每秒达到数百个事务,那么您将发现分布式事务不会削减它。如果要在可用性的第3个9之后添加另一个数字,您将无法假设所有数据库提交都必须在网页的上下文中完成,或者在某些情况下完成。不幸的是,没有简单的公式可以何时退出应用程序级别的事务。相反,作为架构师,您必须决定系统上的一个约束何时需要您放松另一个约束。
你是如何为“放置出价”(Place bid)之类的东西建立自己的原子性的?
单独出价是一个有趣的问题,因为它不是关于原子性的,而是更多关于在拍卖的关键后几秒没有阻止任何竞标者。事实证明,如果您决定在展示时间而不是出价时间计算高出价者和出价,这很简单。将出价插入到单独的子表中,这是一种低争用操作。每次显示该项目时,都会检索所有出价并应用用于确定高出价者的业务规则。
你问题背后的真正问题是我们如何实现一致性?要在大规模系统中实现一致性,您必须放弃ACID而是使用BASE:
基本可用
软状态
最终一致
在每个客户端请求结束时,您需要放松数据的一致性,现在您已打开窗口以消除分布式事务并使用其他机制来达到一致状态。例如,在上述投标案例中,我们还更新由投标人组织的查看表,以便在“我的易趣”页面中快速显示。这是使用一对异步事件完成的。一个人依赖于内存队列,因为我们希望在出价和出现在“我的易趣”之间的延迟非常低。但是,在内存中队列不可靠,因此我们还使用具有出价操作的服务器端事务来捕获出价事件。如果内存队列操作失败,则作为恢复机制处理bid事件。因此,投标人视图表是分离的,并不总是与投标表的状态一致。但这是我们能够承受的宽容,并允许我们避免出价和出价视图表之间的ACID合规性。
您对大型系统的其他架构师有什么建议?
他最简单的建议是,大规模扩展不会为设计为小规模扩展的架构增加资源。 您必须摆脱传统模式,例如ACID和分布式事务。 愿意寻找机会放松传统智慧状态无法放松的约束。
对于一些简单的公理,设计所有要拆分的东西,并考虑BASE,而不是ACID。
亚马逊首席技术官Werner Vogels也在QCon上发表讲话,并以Eric Brewer的CAP定理为例,提供了一些权衡的背景。该定理在2000年PODC会议(.pdf文档)的介绍中描述,其中也涵盖了ACID与BASE,它表明,对于共享数据系统的三个属性 - 数据一致性,系统可用性和网络分区容忍度 - 只有两个可以同时发生。换句话说,不能容忍网络分区的系统可以使用诸如事务之类的常用技术来实现一致性和可用性。但是,对于亚马逊和eBay等大型分布式系统,网络分区是给定的。这样做的结果是,处理非常大的分布式系统的架构师必须决定是否放宽对一致性或可用性的要求。这两个选项都给开发人员带来了一些责任,他们需要了解他们正在使用的架构的特征。例如,如果您选择放松一致性,那么开发人员需要决定如何处理对系统的写入不会立即反映在相应读取中的情况。正如Windows Live程序经理Dare Obasanjo所说的那样.
我们在Windows Live平台的某些方面遵循类似的做法,我听说开发人员抱怨这样一个事实,即您通过事务免费获得的错误恢复由应用程序开发人员掌握。 最大的抱怨总是围绕复杂的批量操作。
有趣的是,许多大型网站似乎都独立地得出了相同的结论。 虽然只有少数节点的小型系统不必担心这些类型的权衡,但eBay和亚马逊正在解决的各种问题可能会开始出现在企业系统中,因为它们也会扩展到更大的范围。 更多的观众。
最新内容
- 3 days 4 hours ago
- 3 days 4 hours ago
- 3 days 4 hours ago
- 3 days 4 hours ago
- 4 days 9 hours ago
- 1 week 5 days ago
- 1 week 5 days ago
- 1 week 5 days ago
- 2 weeks 1 day ago
- 2 weeks 1 day ago