<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ??碼云GVP開源項目 12k star Uniapp+ElementUI 功能強大 支持多語言、二開方便! 廣告
                # 神話:埃里克·布魯爾(Eric Brewer)談銀行為什么不是堿-可用性就是收入 > 原文: [http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html](http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html) ![](https://img.kancloud.cn/45/83/4583228bc480ff608042c03f46149663_240x216.png) 在 [NoSQL:過去,現在,未來](http://www.infoq.com/presentations/NoSQL-History) [Eric Brewer](https://twitter.com/eric_brewer) 中,關于解釋 [BASE 的觀念通常很難理解的部分特別細膩](http://queue.acm.org/detail.cfm?id=1394128) (基本可用,軟狀態,最終一致), [酸](http://en.wikipedia.org/wiki/ACID) (原子性,一致性,隔離性,耐久性), [CAP [](http://en.wikipedia.org/wiki/CAP_theorem) (一致性可用性,分區容限),這是關于銀行業一致性的神圣性的長期存在的神話。 **神話** :金錢很重要,因此銀行 必須 使用交易來保持金錢安全和一致,對嗎? **現實** :銀行交易不一致,尤其是對于 ATM 而言。 ATM 被設計為具有正常情況下的行為和分區模式的行為。 在分區模式下,可用性是通過一致性來選擇的。 **為什么?** **1)**可用性與收入相關,而一致性通常不相關。 **2)**歷史上從來沒有完美交流的想法,所以一切都被分割了。 您的 ATM 交易必須經過,因此可用性比一致性更重要。 如果自動柜員機(ATM)處于關閉狀態,那么您就無法賺錢。 如果您可以保持一致性,堅持不懈,并彌補其他錯誤(這種情況很少發生),那么您將獲得更多的收入。 這是大多數企業發現的空間,因此 BASE 比以前更受歡迎。 對于金融業來說,這不是一個新問題。 他們從來沒有保持過一致,因為歷史上他們從來沒有過完美的溝通。 相反,金融業依賴審計。 導致銀行數據一致性的原因不是其數據庫的一致性,而是所有事實都被 [寫下兩次,然后稍后使用](https://en.wikipedia.org/wiki/Double-entry_bookkeeping_system) 進行整理。 不可更改的記錄,以后再進行核對。 對錯誤進行財務補償的想法是深深植根于金融系統的想法。 在文藝復興時期,當[現代銀行系統](http://en.wikipedia.org/wiki/Luca_Pacioli)初具規模時,一切都被分割了。 如果信件(您的數據)是通過馬或輪船運輸的,那么您的數據可能會保持非常低的一致性,但是它們仍然擁有令人驚訝的豐富而成功的銀行系統。 交易是不必要的。 例如, ATM 選擇了 [交換操作](http://en.wikipedia.org/wiki/Serializability) 之類的遞增和遞減操作,因此操作順序無關緊要。 它們是可重新排序的,以后可以使其保持一致。 如果 ATM 與網絡斷開連接,并且當分區最終恢復正常時,ATM 發送將操作列表發送到銀行,并且期末余額仍然正確。 問題很明顯,您可能會提取比您更多的錢,因此最終結果可能是一致的,但為負數,無法通過要求退款來彌補,因此,銀行將向您獎勵透支罰款。 隱藏的哲學是您試圖 **約束并管理風險,** 仍然可以進行所有操作。 在 ATM 機中,這將限制您一次可以提取的最大金額。 風險不大。 自動取款機是有利可圖的,因此偶爾的損失僅僅是開展業務的風險。 事實證明,這不是圣杯。 勝過一致性的是: * 審核 * 風險管理 * 可用性 在以寫可用性為關鍵的后互聯網世界中,現實世界看起來更像*弱一致性+延遲異常+補償*,而不是完美的溝通和交易的無錯誤世界。 就像過去一樣,但現在您在 ACID <-> CAP 頻譜上有更多選擇。 ## 相關文章 * [關于 HackerNews 2](https://t.co/VMC2IA1K0I) * [討論黑客新聞](https://news.ycombinator.com/item?id=5642010) * [](http://highscalability.com/blog/2012/9/24/google-spanners-most-surprising-revelation-nosql-is-out-and.html)[Google Spanner 最令人驚訝的啟示:NoSQL 出爐了,而 NewSQL 出現了](http://highscalability.com/blog/2012/9/24/google-spanners-most-surprising-revelation-nosql-is-out-and.html) 真的很有趣。 當然,課程必須實施廣泛的審核功能,以彌補潛在的不一致問題,并在發現問題時嘗試和糾正流程 這帶來了銀行認為可以接受的復雜程度,因為收益非常可觀。 但是并不是每個組織或其應用程序都可以忍受這一點-因此仍然有很多地方需要保持一致性 嗨,托德, 我不確定您的所在地,但該示例在英國似乎并不成立。 我不知道實際的實現方式,但是在免費的 ATM 交易環境中,可用性似乎并不是主要問題。 自動柜員機停運并不罕見,而且,超出您的限額將導致機器拒絕為您提供所要求的現金。 盡管如此,有關換向運算的有趣觀點。 干杯, 蒂姆 我不知道這是否可行,因為錢是可替代的-銀行從我那里獲得的 1 美元報酬與自動柜員機應支付的 1 美元沒有明顯的不同。 如果我使用了錯誤的約會資料并承諾“以后再補”,則效果不一樣。 :) 蒂姆 我也在英國,并且同意 ATM 系統乍看之下在英國似乎并不那么清楚,但我相信它仍然是正確的。 我相信,使 ATM 脫機的原因是 ATM 與它用于驗證卡號并快速檢查卡是否被舉報為欺詐性的服務之間的斷開連接。 每個 ATM 提供商(實際上是銀行組)似乎確實要分別運行其系統,然后再將它們一起應用。 我當然已經看過自動取款機說不能顯示我的余額,但是可以提款。 如果這樣的分區是為什么在周末/銀行假日不進行任何交易,而您仍然可以使用您的卡,我不會感到驚訝。 另一個蒂姆 A 罐(應該)仍代表原子。 誰想要一半的交易偽裝成整個交易? 我在 atm 網絡上工作了多年,是的,它們都像這樣工作。 今天,大多數網絡都以在線模式工作。 但是協議支持脫機交易。 請記住,這些網絡也支持信用卡交易(可以在授權交易后應用提示)。 脫機模式可用于支持斷開連接的情況或啟用可伸縮性,驗證是聯機的,但金融交易是分批的。 完全斷開連接的可能性較小,因為必須在線檢查引腳(至少直到芯片和引腳為止)。 從 atm 到后臺,事務不是原子的,如果發生通信錯誤,則可以撤消事務。 一些自動取款機交易被標記為強制過帳,以表明已經發放了款項,即使它們違反了辦公室規定(如不透支)也已得到處理。 這些細節中的一些是西方過去的遺跡,但是在非洲,南美和印度,長距離通信可能非常繁瑣,因此中斷的操作仍然非常重要。 盡管 Atm 交易是免費的,但信用卡交易涉及銀行收費和商人收入。 當服務不可用時,也會損害聲譽。 在金融危機爆發的第一年左右,有很多關于不同機構的傳言。 這些機構非常擔心服務中斷會觸發其銀行擠兌。 干得好,保持下去 好的文章,內容翔實,有趣,重點突出。 Tim, >可用性似乎并不是主要問題。 自動柜員機停運并不罕見 高不可用性率并不能證明可用性不是 OP 中規定的最高優先級。 它只是表明所討論的網絡在實現該優先級方面很差。 >超出您的限制將導致機器拒絕為您提供所要求的現金。 同樣,這并不是可用性優先于一致性的禁忌。 本文的風險管理部分對此進行了介紹。 本文缺少的是認識到,在銀行發布的實際財務更新包含的內容遠不止簡單的余額更新。 可能會有幾十個表被更新,甚至更多。 所有這些工作必須是原子的。 ATM 網絡具有備用功能,可以在多個級別上進行不可靠的通信或主機丟失,但是當消息到達銀行時,它最終是一個很好的老式 ACID 更新。 ATM 和在線信用卡交易系統及其支持的登錄,強制發布,預授權,部分和增量授權等功能,使網絡變得非常可用,這僅僅是因為各機構已選擇達成一項協議 彼此都很好。 銀行系統不太愿意讓提款部分過帳。 謝謝,不錯的帖子 有趣的文章,感謝您提供信息。 真正不幸的是,信息開發人員必須受到來自 Web 開發社區的此類論點的轟炸。 經典的 ATM 示例不應該從字面上理解,而是重要交易的象征。 最容易理解的一種。 現代銀行機構已經實施了風險管理以促進可用性的事實,并沒有改變任何與 ACID 兼容的交易的重要性! 在我的銀行存款,我每 24 小時只能提取 500 美元(風險)(保持一致的時間)。 讓我們想象一下一項新法律,銀行將不再采取此類措施? 哪里有人可以拿出大筆現金? 銀行將很快從 BASE 變為 ACID! 今天的最終一致性如何? 這是關于分發帳單,以及在有人關心的情況下移動零碎的東西。 考慮到關于 ACID 的評論中的論點,我真的很想讀這本書的續集。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看