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

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

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&移动支付系统。

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

你可能感兴趣的:(比特币丢失!MongoDB和最终一致性)