這是一個事故灶体！多家比特幣運營商失竊阅签，這引發(fā)了一場爭論，最終一致性數(shù)據(jù)庫對銀行業(yè)務是否有用蝎抽。
2014年3月2日政钟，由于代碼缺陷，F(xiàn)lexcoin丟失了它所有的比特幣樟结。攻擊者發(fā)出了成千上萬的并發(fā)請求养交，定序將比特幣從他其中一個賬戶轉移到另一個賬戶。之后瓢宦，他用其它賬戶重復同樣的操作碎连，直到取走了所有比特幣。之所以能夠這樣做驮履，是因為編寫的代碼沒有處理多并發(fā)請求鱼辙，而且所有轉移都是發(fā)生在余額更新之前。如果余額沒有及時更新疲吸，即使賬戶是空的座每，請求也可能被批準。因此摘悴，在丟失了896個比特幣（價值約50萬美元）之后，F(xiàn)lexcoin關停了他們的業(yè)務舰绘。
兩天之后蹂喻，Poloniex發(fā)生了同樣的事葱椭，但他們只丟失了12.3%的比特幣，而且該公司彌補了損失口四，并設法維持了下去孵运。
康奈爾大學副教授Emin Gün Sirer寫了一篇博文，將比特幣丟失歸因于最終一致性數(shù)據(jù)存儲蔓彩。在容易產(chǎn)生銀行盜竊的NoSQL解決方案中治笨，他提到MongoDB、Cassandra和Riak赤嚼，因為：
這里的問題旷赖，其根源在于MongoDB提供的接口和語義設計有問題。如果我們用的是Cassandra或者Riak更卒，那么情況不會有任何不同……
比特幣恰逢分布式系統(tǒng)的一個尤其黑暗的時期等孵，人們秉持對CAP理論的錯誤理解，認為他們只不過是不得不放棄數(shù)據(jù)庫的一致性……
目前尚不清楚Flexcoin或者Poloniex那時是否正在使用MongoDB蹂空，而值得一提的是俯萌，Sirer正參與開發(fā)HyperDex，它支持ACID事務上枕，是一個有競爭性的鍵-值數(shù)據(jù)存儲咐熙。另外，這不是Sirer第一次詬病MongoDB的設計了辨萍。一年前糖声，他就聲稱MongoDB的容錯性有問題。
拋開爭論不談分瘦，最終一致性數(shù)據(jù)存儲是否適合銀行業(yè)務是個值得深思的問題蘸泻。不出所料，Sirer的博文引發(fā)了大量的評論嘲玫，本文節(jié)選了部分最值得注意的悦施。
jrp指出，更新操作可以使用MongoDB在數(shù)據(jù)庫級以原子方式實現(xiàn)去团，但他也認為“這將照顧不到其它ACID屬性抡诞。”
jakcharlton認為土陪，鑒于最終一致性在這種情況下有問題昼汗，一個“ACID系統(tǒng)并不能解決該問題，它只是將問題推到應用程序的邊界鬼雀，問題在那里再次發(fā)生顷窒。銀行業(yè)務使用最終一致性數(shù)據(jù)存儲是個壞例子，也顯示出開發(fā)人員思維方面的問題，他們認為由于他們的數(shù)據(jù)庫滿足ACID鞋吉，所以他們能夠免于并發(fā)問題鸦做。”
Alex“做任何事都使用MongoDB谓着，除了需要事務的時候泼诱，那時我會用合適的工具（不是MongoDB）完成工作∩廾”他認為治筒，將MongoDB用于不該使用它的工作是開發(fā)人員犯的一項錯誤。
Robert Escriva是一名HyperDex開發(fā)人員舷蒲，他認為罪魁禍首不是程序員耸袜，而是最終一致性系統(tǒng)可以用于銀行業(yè)務這樣一種普遍存在的觀念：
問題不在程序員的理解。有一種普遍存在的錯誤觀念鼓勵人們使用最終一致性系統(tǒng)阿纤【涔啵“如果它好到足以用于銀行，那么它也能滿足你”欠拾，他們會用這樣的話來證明它的合理性胰锌。這種想法是危險的。
最終藐窄，應用程序應該是其不變量的總和资昧。如果系統(tǒng)底層的數(shù)據(jù)存儲不能提供保證——或者更糟糕，需要大量的維護以及10萬美元的支持合同來提供保證——應用程序有了問題荆忍，卻歸咎于開發(fā)人員格带，這是一種托詞。我們應該以更高的標準要求數(shù)據(jù)庫供應商（尤其是那些動輒就獲得數(shù)億VC現(xiàn)金的供應商）刹枉。
Eric Brewer是CAP理論的創(chuàng)建者叽唱，他先前在一篇文章中寫道，為了在分區(qū)期間提供可用性微宝，銀行在他們的ATM業(yè)務中放棄了一致性棺亭。但他們這樣做的時候采取了一定的防范措施，其中包括將取款數(shù)額限制在某個較小的閥值內蟋软。這里還要提一下Stripe镶摘，根據(jù)他們的一篇博文，這是一款使用了MongoDB的Web&移動支付系統(tǒng)岳守。
最終一致性數(shù)據(jù)存儲適合一般銀行業(yè)務嗎凄敢？或者開發(fā)人員應該知道它們的局限性而另尋方案呢？
