比特币丢失、MongoDB 和最终一致性

  • Abel Avram
  • 马德奎

2014 年 4 月 28 日

话题:语言 & 开发架构

近日,多家比特币运营商失窃,这引发了一场争论,最终一致性数据库对银行业务是否有用。

2014 年 3 月 2 日,由于代码缺陷,Flexcoin 丢失了它所有的比特币。攻击者发出了成千上万的并发请求,定序将比特币从他其中一个账户转移到另一个账户。之后,他用其它账户重复同样的操作,直到取走了所有比特币。之所以能够这样做,是因为编写的代码没有处理多并发请求,而且所有转移都是发生在余额更新之前。如果余额没有及时更新,即使账户是空的,请求也可能被批准。因此,在丢失了 896 个比特币(价值约 50 万美元)之后,Flexcoin 关停了他们的业务。

两天之后,Poloniex 发生了同样的事,但他们只丢失了 12.3% 的比特币,而且该公司弥补了损失,并设法维持了下去。

康奈尔大学副教授Emin Gün Sirer写了一篇博文,将比特币丢失归因于最终一致性数据存储。在容易产生银行盗窃的 NoSQL 解决方案中,他提到 MongoDB、Cassandra 和 Riak,因为:

这里的问题,其根源在于 MongoDB 提供的接口和语义设计有问题。如果我们用的是 Cassandra 或者 Riak,那么情况不会有任何不同……

比特币恰逢分布式系统的一个尤其黑暗的时期,人们秉持对 CAP 理论的错误理解,认为他们只不过是不得不放弃数据库的一致性……

目前尚不清楚 Flexcoin 或者 Poloniex 那时是否正在使用 MongoDB,而值得一提的是,Sirer 正参与开发HyperDex,它支持 ACID 事务,是一个有竞争性的键 - 值数据存储。另外,这不是 Sirer 第一次诟病 MongoDB 的设计了。一年前,他就声称MongoDB 的容错性有问题

抛开争论不谈,最终一致性数据存储是否适合银行业务是个值得深思的问题。不出所料,Sirer 的博文引发了大量的评论,本文节选了部分最值得注意的。

jrp指出,更新操作可以使用 MongoDB 在数据库级以原子方式实现,但他也认为“这将照顾不到其它 ACID 属性。”

jakcharlton认为,鉴于最终一致性在这种情况下有问题,一个“ACID 系统并不能解决该问题,它只是将问题推到应用程序的边界,问题在那里再次发生。银行业务使用最终一致性数据存储是个坏例子,也显示出开发人员思维方面的问题,他们认为由于他们的数据库满足 ACID,所以他们能够免于并发问题。”

Alex“做任何事都使用 MongoDB,除了需要事务的时候,那时我会用合适的工具(不是 MongoDB)完成工作。”他认为,将 MongoDB 用于不该使用它的工作是开发人员犯的一项错误。

Robert Escriva是一名 HyperDex 开发人员,他认为罪魁祸首不是程序员,而是最终一致性系统可以用于银行业务这样一种普遍存在的观念:

问题不在程序员的理解。有一种普遍存在的错误观念鼓励人们使用最终一致性系统。“如果它好到足以用于银行,那么它也能满足你”,他们会用这样的话来证明它的合理性。这种想法是危险的。

最终,应用程序应该是其不变量的总和。如果系统底层的数据存储不能提供保证——或者更糟糕,需要大量的维护以及 10 万美元的支持合同来提供保证——应用程序有了问题,却归咎于开发人员,这是一种托词。我们应该以更高的标准要求数据库供应商(尤其是那些动辄就获得数亿 VC 现金的供应商)。

Eric Brewer 是CAP 理论的创建者,他先前在一篇文章中写道,为了在分区期间提供可用性,银行在他们的 ATM 业务中放弃了一致性。但他们这样做的时候采取了一定的防范措施,其中包括将取款数额限制在某个较小的阀值内。这里还要提一下Stripe,根据他们的一篇博文,这是一款使用了 MongoDB 的 Web& 移动支付系统。

最终一致性数据存储适合一般银行业务吗?或者开发人员应该知道它们的局限性而另寻方案呢?

查看英文原文:BitCoins Lost, MongoDB and Eventual Consistency

语言 & 开发架构