比特币丢失！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&移动支付系统。

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