CAP原理
Consistency（一致性） ：客戶端知道一系列的操作都會同時發生(生效)
Availability（可用性） ：每個操作都必須以可預期的響應結束
Partition tolerance（分區容錯性） ：即使出現單個組件無法可用，操作依然可以完成
在分布式系統中，最多只能實現上面兩點。任何橫向擴展都要依賴於數據分區。因此，我們只能在一致性和可用性之間進行權衡。
BASE理論
Basically Available（基本可用）
Soft state（軟狀態）
Eventual consistency（最終一致性）
對CAP一致性和可用性進行一個權衡的結果，核心思想是：我們無法做到強一致性，但可以采用適當的方式讓系統達到最終一致性。
一、分布式事務
事務的四個特性
原子性、一致性、隔離性、持久性，這四個屬性通常稱為ACID特性。
1.原子性（Atomicity）
一個事務是一個不可分割的工作單位，事務內的所有操作要么都執行，要么都不執行。
2.一致性（Consistency）
事務要有完整性約束，不能存在中間狀態。比如A轉賬給B，A要減，B要加。
3.隔離性（Isolation）
多個事務並發執行的時候不會互相干擾，即一個事務內部的數據對於其它事務來說是隔離的。
4.持久性（Durability）
一個事務完成之后數據就被永遠保存下來，之后的其它操作或故障都不會對事務的結果產生影響。
什么是分布式事務？
分布式事務用於保證不同節點間的數據一致性。
分布式事務解決方案
兩階段提交（2PC）
兩階段提交是一種強一致性設計，包含兩個角色：事務協調者和事務參與者
正常流程：
1.事務協調者向所有的參與者發送Prepare請求。參與者接到請求后，各自執行業務操作。如果參與者執行成功，暫時不提交事務，而是向事務協調者返回“完成”消息。
2.事務協調者向所有的參與者發送Commit請求。參與者接到請求后，各自進行本地的事務提交，並釋放鎖資源，向事務協調者返回”完成“消息。
失敗流程：
若第1步某個參與者返回”失敗“消息，則第2步事務協調者發送Abort請求，各個事務參與者進行回滾操作。
XA兩階段提交的不足
1.性能問題
XA協議遵循強一致性。在事務執行過程中，各個節點占用着數據庫資源，只有當所有節點准備完畢，事務協調者才會通知提交，參與者提交后釋放資源。這樣的過程有着非常明顯的性能問題，不適合高並發高性能場景。
2.協調者單點故障問題
事務協調者是整個XA模型的核心，一旦事務協調者節點掛掉，參與者收不到提交或是回滾通知，參與者會一直處於中間狀態無法完成事務。
3.丟失消息導致的不一致問題
在XA協議的第二個階段，如果發生局部網絡問題，一部分事務參與者收到了提交消息，另一部分事務參與者沒收到提交消息，那么就導致了節點之間數據的不一致。
XA三階段提交（3PC）
XA三階段提交在兩階段提交的基礎上增加了CanCommit階段，並且引入了超時機制。一旦事務參與者遲遲沒有接到協調者的commit請求，會自動進行本地commit。這樣有效解決了協調者單點故障的問題。但是性能問題和不一致的問題仍然沒有根本解決。
MQ事務（消息事務+最終一致性）
利用消息中間件來異步完成事務的后一半更新，實現系統的最終一致性。這個方式避免了像XA協議那樣的性能問題。
補償事務（TCC）
TCC事務是Try、Commit、Cancel三種指令的縮寫，其邏輯模式類似於XA兩階段提交，但是實現方式是在代碼層面來人為實現。
本地消息表
添加本地消息表實現最終一致性。比如商城系統，一個訂單服務，一個庫存服務。訂單服務產生訂單后，往消息表中添加一條數據，標記狀態為發送中。然后寫數據到MQ，庫存服務MQ接收到數據進行扣庫存操作，再寫數據到MQ，訂單服務MQ接收消息標記消息表中的狀態為已完成。為了確保消息投遞不丟失，添加一個定時任務掃描訂單服務中的消息表，將發送中的訂單重新投遞。
優點
實現邏輯簡單，開發成本較低。
缺點
與業務場景綁定，高耦合，不能公用。
事務並發帶來的問題
1.臟讀
一個事務讀到另一個事務還沒有提交的數據。
2.不可重復讀
一個事務兩次讀取同一條數據，兩次讀取到的數據不一致。
3.幻讀
一個事務兩次讀取同一份數據，兩次讀取到的數據量不一致。
4.更新丟失
一個事務的更新覆蓋了另一個事務的更新。
事務並發解決方案
隔離級別（MySQL默認是可重復讀）
1.讀未提交
可能存在：臟讀、可重復讀、幻讀
2.讀已提交
可能存在：可重復讀、幻讀
3.可重復讀
可能存在：幻讀
4.可串行化
避免了臟讀、可重復讀、幻讀
悲觀鎖和樂觀鎖是數據庫用來保證數據並發安全防止更新丟失的兩種方法。
1.悲觀鎖
悲觀鎖總是假設最壞的情況，每次拿數據的時候都以為別人會修改，所以每次拿數據的時候都會上鎖，直到整個事務結束。表鎖、行鎖、讀鎖、寫鎖都屬於悲觀鎖。Java中的synchronized也是悲觀鎖的實現。
2.樂觀鎖
樂觀鎖總是假設最好的情況，認為別人都是友好的，所以每次獲取數據的時候不會上鎖，但更新數據那一刻會判斷數據是否被更新過。如果被更新過，則報異常。樂觀鎖可用版本號機制和CAS算法實現。
Spring事務傳播屬性和隔離級別
二、分布式鎖
鎖是一種控制共享資源爭搶的機制，采用互斥方式防止並發造成的沖突。
分布式鎖的三要素
1.外部存儲
2.全局唯一標識
3.至少有兩種狀態，獲取和釋放
分布式鎖的實現方式
1.數據庫
2.Redis
3.Zookeeper
三、秒殺
秒殺的特點
1.瞬時大並發。
2.庫存少，只有少部分用戶能秒殺成功。
秒殺解決方案
1.限流
令牌桶算法（網關限流）
以一個恆定的速度往桶中放入令牌，當來一個請求的時候，需要先從桶中獲取一個令牌，桶中沒有令牌可取時，就拒絕服務。需配置令牌桶的容量、允許每秒處理請求數。
漏桶算法
把請求放入漏桶中，漏桶以一定的頻率處理請求，當漏桶中的請求滿的時候，就拒絕請求。
2.削峰
3.緩存
4.異步
性能指標
1.TPS（吞吐量）
TPS是指每秒事務數，一個事務數可以是一個接口，也可以是一個業務流程。從第一個請求發送到接收到最后一個請求的響應的過程。
2.QPS
每秒查詢率。是服務器每秒能夠響應的查詢次數。
3.並發數
指系統可以同時承載的用戶數量。並發量=QPS*平均響應時間
負載均衡策略
1.輪詢
每個請求按時間順序逐一分配到不同的服務器，如果某個服務器down掉，則自動剔除。
2.指定權重
指定輪詢幾率，weight和訪問比率成正比，用於服務器性能不均的情況。
3.ip hash
同一個IP分配到同一個服務器，可解決分布式session問題。
4.隨機
5.最小連接數