<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>

                企業??AI智能體構建引擎,智能編排和調試,一鍵部署,支持知識庫和私有化部署方案 廣告
                # Brewer 的 CAP 定理簡述 > 原文: [https://howtodoinjava.com/hadoop/brewers-cap-theorem-in-simple-words/](https://howtodoinjava.com/hadoop/brewers-cap-theorem-in-simple-words/) 當您開始討論分布式架構時,很可能會遇到 **CAP 理論**(或 Brewer 定理)。 CAP 代表一致性,可用性和分區容錯性。 它希望系統設計師在最終設計中在以上三個競爭保證之間做出選擇。 據說不可能在系統中實現全部三項,并且您必須在系統的三項保證中最多選擇兩項。 好。 定義似乎簡單快捷。 可是等等 !! 您所說的一致性,可用性和分區容錯性是什么意思? 讓我們在分布式計算環境中定義這些術語。 1. #### 一致性 一致的服務將完全運行或根本不運行。 一致性在非分布式系統中的 ACID 屬性中為“C”,適用于數據庫事務的理想屬性,這意味著數據將永遠不會持久保存(回滾),從而打破了某些預設約束。 在分布式環境中,一致性意味著,正在從集群讀取數據的所有客戶端程序在任何給定時間點都會看到相同的數據。 從兩個節點獲取數據的兩個客戶端應該根本看不到不同的數據。 2. #### 可用性 可用性意味著,**無論群集**內部發生什么,您都應該能夠檢索存儲在分布式系統中的數據。 如果發出請求,則必須從系統得到響應; 即使集群中的一個節點(或多個節點)發生故障。 3. #### 分區容錯性 分區容錯性意味著即使兩個節點(兩個節點都在上,但無法通信)之間存在“分區”(通信中斷),群集(作為一個整體)仍可以繼續運行。 **不允許出現少于總網絡故障的一組故障,從而導致系統無法正確響應。** 因此,CAP 定理使您可以選擇想要添加到系統中的 3 個保證中的任意兩個。 您不能保證單個分布式系統中的全部 3 個,例如,為了獲得可用性和分區容錯性,您必須放棄一致性。 ## CAP 定理例子 不管您讀過什么,大部分都是定義部分,對于初學者來說有點復雜。 讓我們用更簡單的英語來了解 您需要設計一個由 4 個數據節點組成的分布式集群。 復制因子為 2,即任何寫入群集的數據都必須寫入 2 個節點; 因此,當發生故障時,一秒鐘即可提供數據。 現在,嘗試對此要求應用 CAP 定理。 在分布式系統中,任何時候都可能發生兩件事,即節點故障(硬盤崩潰)或網絡故障(兩個節點之間的連接斷開)([分布式計算的謬誤](https://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing))。 我們將嘗試根據這些事實/假設來設計我們的系統。 #### CP(一致性/分區容錯性)系統 在分布式系統中,在讀取數據時,一致性是由一種投票機制決定的,在該機制中,所有擁有數據副本的節點都同意他們擁有所請求數據的“相同副本”。 現在,假設我們請求的數據存在于兩個節點 N1 和 N2 中。 客戶端嘗試讀取數據; 而且我們的 CP 系統也可以容忍分區,因此發生了預期的網絡故障,并且將 N2 檢測為宕機。 現在,系統無法確定 N1 的數據副本是否為最新; 它也可能是陳舊的。 因此,系統決定將錯誤事件發送給客戶端。 在這里,系統選擇了數據一致性而不是數據可用性。 同樣,如果復制因子為 2,則在寫入數據時,系統可能會拒絕寫入請求,直到找到兩個運行狀況良好的節點以一致的方式完全寫入數據為止。 #### AP(可用性/分區容錯性)系統 如果在上述情況下系統而不是發送錯誤(如果 N2 處于關閉狀態)怎么辦? 它發送從 N1 接收的數據。 客戶端得到了數據,但是過去存儲在系統中的是最新數據副本嗎? 你不能決定。 您選擇可用性而不是一致性。 這些是 AP 系統。 #### CA(一致性/可用性)系統 在分布式環境中,我們無法避免 CAP 的“P”。 因此,我們必須在 CP 或 AP 系統之間進行選擇。 如果我們希望擁有一個一致且可用的系統,那么我們就必須忽略分區容錯性,只有在非分布式系統(例如 oracle 和 SQL Server)中才有可能。 ![CAP Theorem Example](https://img.kancloud.cn/3b/99/3b991b8d7865261c80585319d8b3e917_600x300.png) CAP 理論示例 在當今世界中,我們可以在分布式系統中實現這三個目標(如果不是全部,則至少是部分)。 例如 [Cassandra 中的可調一致性](http://docs.datastax.com/en/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html)。 *CAP 定理就像關于軟件項目的古老玩笑一樣:您可以在時間,預算或正確性中選擇任意兩個??* **祝您學習愉快!** **參考**:[http://www.julianbrowne.com/article/viewer/brewers-cap-theorem](http://www.julianbrowne.com/article/viewer/brewers-cap-theorem)
                  <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>

                              哎呀哎呀视频在线观看