本文主要介紹SpringCloud里頭一些常見的原理、定理等相關SpringCloud的技術知識
一、CAP原則
CAP原則又稱CAP定理，指的是在一個分布式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。
CAP原則是NOSQL數據庫的基石。Consistency（一致性）。 Availability（可用性）。Partition tolerance（分區容錯性）
分布式系統的CAP理論：理論首先把分布式系統中的三個特性進行了如下歸納：
● 一致性（C）：在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
● 可用性（A）：在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
● 分區容錯性（P）：以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。
二、與可用的抉擇
CAP理論就是說在分布式存儲系統中，最多只能實現上面的兩點。而由於當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。
對於web2.0網站來說，關系數據庫的很多主要特性卻往往無用武之地
1.數據庫事務一致性需求
很多web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求並不高。允許實現最終一致性。
2.數據庫的寫實時性和讀實時性需求
對關系數據庫來說，插入一條數據之后立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web應用來說，並不要求這么高的實時性，比方說發一條消息之 后，過幾秒乃至十幾秒之后，我的訂閱者才看到這條動態是完全可以接受的。
3.對復雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角 度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
三、與NoSQL的關系
傳統的關系型數據庫在功能支持上通常很寬泛，從簡單的鍵值查詢，到復雜的多表聯合查詢再到事務機制的支持。而與之不同的是，NoSQL系統通常注重性能和擴展性，而非事務機制（事務就是強一致性的體現） 。
傳統的SQL數據庫的事務通常都是支持ACID的強事務機制。A代表原子性，即在事務中執行多個操作是原子性的，要么事務中的操作全部執行，要么一個都不執行;C代表一致性，即保證進行事務的過程中整個數據庫的狀態是一致的，不會出現數據花掉的情況;I代表隔離性，即兩個事務不會相互影響，覆蓋彼此數據等;D表示持久化，即事務一旦完成，那么數據應該是被寫到安全的，持久化存儲的設備上（比如磁盤）。
NoSQL系統僅提供對行級別的原子性保證，也就是說同時對同一個Key下的數據進行的兩個操作，在實際執行的時候是會串行的執行，保證了每一個Key-Value對不會被破壞。
四、與BASE的關系
BASE就是為了解決關系數據庫強一致性引起的問題而引起的可用性降低而提出的解決方案。
BASE是下面三個術語的縮寫：
基本可用（Basically Available）
軟狀態（Soft state）
最終一致（Eventually consistent）
目前最快的KV數據庫,10W次/S, 滿足了高可用性。
Redis的k-v上的v可以是普通的值（基本操作：get/set/del） v可以是數值（除了基本操作之外還可以支持數值的計算） v可以是數據結構比如基於鏈表存儲的雙向循環list（除了基本操作之外還可以支持數值的計算，可以實現list的二頭pop,push）。如果v是list，可以使用redis實現一個消息隊列。如果v是set,可以基於redis實現一個tag系統。與mongodb不同的地方是后者的v可以支持文檔，比如按照json的結構存儲。redis也可以對存入的Key-Value設置expire時間。
Redis的v的最大遠遠超過memcache。這也是實現消息隊列的一個前提。