近日，多家比特币运营商失窃，这引发了一场争论，最终一致性数据库对银行业务是否有用。
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
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论