最终一致性 [英] Eventual Consistency

问题描述

我正处于应用程序设计的早期阶段，该应用程序必须具有高可用性和可伸缩性.由于多种原因，我想为此使用最终一致性数据模型.我知道并理解为什么对于许多解决方案来说，这是一个不受欢迎的体系结构选择，但这对我而言很重要.

I am in the early stages of design of an application that has to be highly available and scalable. I want to use an eventual consistency data model for this for a number of reasons. I know and understand why this is an unpopular architectural choice for many solutions, but it's important in my case.

我正在寻找在处理分布式/文档样式数据库时需要注意的现实建议，最佳实践和陷阱.尤其是电子商务(购物车样式)应用程序周围的区域，这些区域通常较容易与关系数据库放在一起.

I am looking for real-world advice, best-practices and gotchas to look out for when dealing with distributed / document-style databases. And particularly areas around e-commerce (shopping cart style) apps that traditionally are easier to put together with a relational db.

我知道使用这些类型的数据库是有挑战性的，但是Google和E-bay都在使用它们，因此它们不会那么难;-)任何建议都将不胜感激.

I understand using these types of DB is challenging, but hey, Google and E-bay use them so they can't be that hard ;-) Any advice would be appreciated.

推荐答案

如果您想要一个分布式系统(即最终一致性"的东西)，则需要人员，构建，维护和操作它.

If you want to have a Distributed System (that "Eventual Consistency" thing) you need people, build, maintain and to operate it.

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

I found that there are three classes of people which have very little problems with "Eventual Consistency":

• 在分布式系统中具有扎实背景的人们.他们了解了最终一致性拜占庭式失败以及类似的东西.如果您了解 Paxos 与假期无关，那么您可能就是其中之一.
• 具有网络编程经验的人们.他们可能会错过理论背景，但是对异步性和没有全局时钟和计数器"范式有直观的了解.如果您至少拥有 Richard Stevens 的8本书，您可能就是其中一员.
• 非常有经验的编码人员，很少接触RDBMS.内核专家，科学计算和游戏行业的人都浮现在脑海.

• People with a solid background in distributed systems. They have learned about Eventual Consistency Byzantine Failures and stuff like that. If you understand that Paxos is not about holidays, you are probably one of them.
• People experienced in network programming. They might miss the theoretical background but have an intuitive understanding of asynchronity and the "no global clocks & counters" paradigm. If you own at least 8 books by Richard Stevens you are probably one of them.
• Very experienced coders which had little exposure to RDBMS. Kernel guys, people from scientific computing and the gaming industry come to mind.

所有这些人在就业市场上都很受追捧.例如，大约有75％的分布式系统学者离开了运行大型，自行设计的分布式系统的机构，例如股票交易所.

All in all this people are very sought after in the job market. For example 75% or so of the academics in distributed systems leave for institutions who run big, self-designed distributed systems, e.g. the stock exchanges.

Hardoop，SimpleDB和CouchDB等产品使事情变得有些简单，但是在分布式系统技术上构建产品仍然是一个巨大的挑战.

The whole thing got somewhat simpler with offerings like Hardoop, SimpleDB and CouchDB but it is still a big challenge to build something on distributed systems technology.

另一方面，RDBMS是非常好的工程设计.他们被很好地理解，并且在市场上可以找到有关他们的专业知识.每小时都有很多不错的工具，教育机会和许多高技能的专家可以租用.因此，请三思而后行，您可能无法接受RDBMS方法-也许加上一些聪明的作弊手段.我通常会向学生指出生活新闻架构.

On the other Hand RDBMS are a very fine pice of engineering. They are well understood and expertise on them is available the job market. There are a lot of decent tools, education opportunities and lots of highly skilled experts are available to be rented by the hour. So think twice of you can't get on with a RDBMS approach - perhaps coupled with some clever cheating. I usually point students to the Lifejournal architecture.

对于分布式数据库，经验要少得多.这就是到目前为止您很少找到建议的原因.

For Distributed Databases there is much less experience. That's exactly the reason you have found so little advice so far.

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

If you are determined to use "Eventual Consistency" I think besides immature tools the main challenge is the mindset of everyone involved. Are your API users (coders) and application users (your employees and your customers) are willing and able to accept the inconsistency? Can you hide it from certain classes of users? We are not used to that mindset that computers are inconsistent. Something is in stock or it isn't. "Maybe" isn't an answer users expect.

还要记住，最终"可能对算法设计者意味着很长的时间.您可以接受不一致的情况多长时间?

Also keep in mind that "eventual" can mean a very long time to algorithm designers. For how long can you accept inconsistency?

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

For a shopping cart application you might want to go truly distributed: Use the Clients Browser as data store. On checkout you can submit the cart to the server side batch processing system. This means for the catalog you need read only high availability (easier) and the cart submission is a very narrow interface with no need for transactions. Later on the processing of the order has no (Soft) real time requirements and thus is easier.

顺便说一句:上次我检查E-Bay架构时，它们在RDBMS中的位置很大，但此后可能已经发生了变化. (确实发生了变化-请参见评论)

BTW: Last time I checked on E-Bay architecture they where big in RDBMS but it may have changed since then. ( it did change - see comments)

这篇关于最终一致性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！