> CAP理論指的是分布式系統最多同時滿足C-consistency、A-available和P-partition tolerance中的兩項


## 1. consistency一致性
1. all nodes see the same data at the same time即為更新數據完成并響應客戶端后,其他節點獲取的都是最新的值(同步完成,強一致性)
2. 對于一致性,可以分為從客戶端和服務端兩個不同的視角。從客戶端來看,一致性主要指的是多并發訪問時更新過的數據如何獲取的問題。
從服務端來看,則是更新如何復制分布到整個系統,以保證數據最終一致。一致性是因為有并發讀寫才有的問題,因此在理解一致性的問題時,一定要注意結合考慮并發讀寫的場景。
3. 對于關系型數據庫,要求更新過的數據能被后續的訪問都能看到,這是強一致性。
4. 如果能容忍后續的部分或者全部訪問不到,則是弱一致性。
5. 如果經過一段時間后要求能訪問到更新后的數據,則是最終一致性。
## 2. available可用性
reads and writes always available,服務一直可以提供響應,即使數據不是最新的。
## 3. 分區容忍性(Partition tolerance)
> 1. 分布式系統在遇到任何網絡分區故障的時候,仍然能夠對外提供滿足一致性和可用性的服務,也就是說,服務器A和B發送給對方的任何消息都是可以放棄的,也就是說A和B可能因為各種意外情況,導致無法成功進行同步,分布式系統要能容忍這種情況。除非整個網絡環境都發生了故障。
> 2. P是分布式的基礎,不滿足分區容忍,就是單體應用了

AP: 即時G1和G2數據同步失敗,也要保證可用性
CP:G1和G2數據同步失敗,就一直等著,不提供服務,因為要保證數據的一致性
### 同步策略
保證可用性和分區容錯,舍棄強一致性,但保證最終一致性,比如一些高并發的站點(秒殺、淘寶、12306)。最終近似于兼顧了三個特性。
## 4. 數據一致性
> **一致性可以分為強一致性、弱一致性和最終一致性。所謂強一致性,即復制是同步的,弱一致性,即復制是異步的。**
CAP理論告訴我們一個悲慘但不得不接受的事實——我們只能在C、A、P中選擇兩個條件。而對于業務系統而言,我們往往選擇犧牲一致性來換取系統的可用性和分區容錯性。不過這里要指出的是,所謂的“犧牲一致性”并不是完全放棄數據一致性,而是犧牲**強一致性**換取**弱一致性**。
### 4.1 強一致性
> 系統中的某個數據被成功更新后,后續任何對該數據的讀取操作都將得到更新后的值;
也稱為:原子一致性(Atomic Consistency)線性一致性(Linearizable Consistency)
**1. 兩個要求:**
* 任何一次讀都能讀到某個數據的最近一次寫的數據。
* 系統中的所有進程,看到的操作順序,都和全局時鐘下的順序一致。
簡言之,在任意時刻,所有節點中的數據是一樣的。例如,對于關系型數據庫,要求更新過的數據能被后續的訪問都能看到,這是強一致性。
**2. 總結:**
* 一個集群需要對外部提供強一致性,所以只要集群內部某一臺服務器的數據發生了改變,那么就需要等待集群內其他服務器的數據同步完成后,才能正常的對外提供服務。
* 保證了強一致性,務必會損耗可用性。
### 4.2 弱一致性
> 系統中的某個數據被更新后,后續對該數據的讀取操作**可能**得到更新后的值,也可能是更改前的值。
但即使過了**不一致時間窗口**這段時間后,后續對該數據的讀取也不一定是最新值
所以說,可以理解為數據更新后,如果能容忍后續的訪問只能訪問到部分或者全部訪問不到,則是弱一致性。
### 4.3 最終一致性
> 是弱一致性的特殊形式,存儲系統保證在沒有新的更新的條件下,最終所有的訪問都是最后更新的值。
> 不保證在任意時刻任意節點上的同一份數據都是相同的,但是隨著時間的遷移,不同節點上的同一份數據總是在向趨同的方向變化。
簡單說,就是在一段時間后,節點間的數據會最終達到一致狀態。
**一致性總結**
弱一致性即使過了不一致時間窗口,后續的讀取也不一定能保證一致,而最終一致過了不一致窗口后,后續的讀取一定一致
## 5. Base理論
* BA:Basic Available基本可用
* 整個系統在某些不可抗力的情況下,仍然能夠保證“可用性”,即一定時間內仍然能夠返回一個明確的結果。只不過“基本可用”和“高可用”的區別是:
* “一定時間”可以適當延長 當舉行大促時,響應時間可以適當延長
* 給部分用戶返回一個降級頁面 給部分用戶直接返回一個降級頁面,從而緩解服務器壓力。但要注意,返回降級頁面仍然是返回明確結果。
* S:Soft State柔性狀態: 是指允許系統中的數據存在中間狀態,并認為該中間狀態的存在不會影響系統的整體可用性,即允許系統不同節點的數據副本之間進行數據同步的過程存在延時。
* E:Eventual Consisstency最終一致性: 同一數據的不同副本的狀態,可以不需要實時一致,但一定要保證經過一定時間后仍然是一致的。
BASE理論是對CAP中的一致性和可用性進行一個權衡的結果,理論的核心思想就是:我們無法做到強一致,但每個應用都可以根據自身的業務特點,采用適當的方式來使系統達到最終一致性(`Eventual consistency`)。
- springcloud
- springcloud的作用
- springboot服務提供者和消費者
- Eureka
- ribbon
- Feign
- feign在微服務中的使用
- feign充當http請求工具
- Hystrix 熔斷器
- Zuul 路由網關
- Spring Cloud Config 分布式配置中心
- config介紹與配置
- Spring Cloud Config 配置實戰
- Spring Cloud Bus
- gateway
- 概念講解
- 實例
- GateWay
- 統一日志追蹤
- 分布式鎖
- 1.redis
- springcloud Alibaba
- 1. Nacos
- 1.1 安裝
- 1.2 特性
- 1.3 實例
- 1. 整合nacos服務發現
- 2. 整合nacos配置功能
- 1.4 生產部署方案
- 環境隔離
- 原理講解
- 1. 服務發現
- 2. sentinel
- 3. Seata事務
- CAP理論
- 3.1 安裝
- 分布式協議
- 4.熔斷和降級
- springcloud與alibba
- oauth
- 1. abstract
- 2. oauth2 in micro-service
- 微服務框架付費
- SkyWalking
- 介紹與相關資料
- APM系統簡單對比(zipkin,pinpoint和skywalking)
- server安裝部署
- agent安裝
- 日志清理
- 統一日志中心
- docker安裝部署
- 安裝部署
- elasticsearch 7.x
- logstash 7.x
- kibana 7.x
- ES索引管理
- 定時清理數據
- index Lifecycle Management
- 沒數據排查思路
- ELK自身組件監控
- 多租戶方案
- 慢查詢sql
- 日志審計
- 開發
- 登錄認證
- 鏈路追蹤
- elk
- Filebeat
- Filebeat基礎
- Filebeat安裝部署
- 多行消息Multiline
- how Filebeat works
- Logstash
- 安裝
- rpm安裝
- docker安裝Logstash
- grok調試
- Grok語法調試
- Grok常用表達式
- 配置中常見判斷
- filter提取器
- elasticsearch
- 安裝
- rpm安裝
- docker安裝es
- 使用
- 概念
- 基礎
- 中文分詞
- 統計
- 排序
- 倒排與正排索引
- 自定義dynamic
- 練習
- nested object
- 父子關系模型
- 高亮
- 搜索提示
- kibana
- 安裝
- docker安裝
- rpm安裝
- 整合
- 收集日志
- 慢sql
- 日志審計s
- 云
- 分布式架構
- 分布式鎖
- Redis實現
- redisson
- 熔斷和降級