分布式–1概述cap和base
分布式–2分布式事務
分布式–3分布式一致性演算法
分布式-4集群
分布式–5服務限流演算法
分布式–6分布式id
分布式–7效能壓測
分布式–8日誌鏈路跟蹤
分布式-9分布式鎖|redis鎖的幾種實現
參考 分布式系統間各種問題：宕機、網路不穩定
本地事務無法滿足需求：
1）遠端服務假失敗： 遠端服務其實成功了，由於網路故障等沒有返回 導致：訂單回滾，庫存卻扣減
2）遠端服務執行完成，下面的其他方法出現問題 導致：已執行的遠端請求，肯定不能回滾
兩階段提交系統中，存在乙個節點作為協調者，其他節點為參與者。
所有的節點都採用預寫式日誌。日誌記錄不會丟失。
所有的節點不會永久性的宕機，即使宕機後仍可以恢復。
第一階段：事務管理器要求每個涉及到事務的資料庫預提交此操作，並反映是否可以提交.
第二階段：根據第一階段的反饋，事務協調器要求每個資料庫提交資料，或者回滾資料。
事務管理器為單點，故障以後整個資料庫集群無法使用
在執行過程中，所有參與事務的節點都是事務獨佔狀態，當有參與者占用公共資源時，那麼其他第三方節點對公共資源的訪問會被阻塞。
第二階段中，假設協調者發出了事務commit的通知僅被一部分參與者所收到並執行，其餘的參與者則因為沒有收到通知一直處於阻塞狀態，這時候就產生了資料的不一致性。
為解決兩階段提交協議中，公共資源占用堵塞的問題，三階段提交協議中協調者和參與者都引入了超時機制，然後把兩階段提交協議裡的第乙個階段拆分為兩步：先詢問（cancommit），再鎖資源（precommit），再最後提交（docommit）。
cancommit：
協調者向參與者傳送commit請求，參與節點反映是否可以調節。
precommit：
根據cancommit響應情況有以下兩種執**況。
如果所有的參與節點返回yes，則進行事務的預執行：協調者向參與者傳送precommit請求，使參與者進入prepare階段。並向協調者反饋ack。
如果任意乙個節點返回了no，或者等待超時進進行中斷操作。則協調者向所有的參與者傳送abort請求，參與者執行abort請求放棄事務的執行。
docommit：
階段根據precommit的響應也有兩種執**況。
如果協調者收到所有參與者的ack響應，則傳送docommit請求，所有的參與者提交事務釋放資源，並向協調者反饋ack響應。
如果協調者沒有到所有參與者的ack響應，則會執行中斷事務
在docommit階段中，假設協調者發出了事務commit的通知僅被一部分參與者所收到並執行，其餘的參與者則因為沒有收到通知一直處於阻塞狀態，這時候就產生了資料的不一致性。
很多框架都實現了tcc，我們只需要把自己的**業務拆成三部分，放在對應的是三個方法裡，框架就可以幫我們按時機執行。
相當於三階段的手動版
1）定義
tcc是支付寶提出的分布式事務解決方案,每個分布式事務的參與者都需要實現3個介面：try、confirm、cancel。
try階段：
呼叫方呼叫各個服務的 try 介面，各個服務執行資源檢查和鎖定，看自己是否有能力完成，如果允許，則鎖定資源.
confirm階段：
各個服務的 try 介面都返回了 yes，則進入提交階段，呼叫方呼叫各個服務的 confirm 介面，各個服務對 try 階段鎖定的資源進行處理。如果 try 階段有一方返回了 no，或者超時，呼叫方呼叫各個服務的 cancel 介面，釋放鎖定的資源
cancel階段：
取消執行，釋放try階段預留的業務資源
confirm階段和cancel階段是互斥的，只能進行乙個，而且都是冪等性的，允許失敗重試。
2）優點
1. tcc解決了跨服務的業務操作原子性問題，可以讓應用自己定義資料庫操作的粒度，降低鎖衝突，提高系統的業務吞吐量。
2. tcc的每一階段都由業務自己控制，避免了長事務，提高了效能。
1. 業務侵入性強：業務邏輯必須都要實現try，confirm，cancel三個操作
異常情況
現象是 try 沒被執行，就呼叫了 cancel:呼叫 try 時出現異常，try 介面實際沒有被呼叫，自然沒有返回 yes，那麼會按照正常流程進入第2階段，呼叫 cancel 介面，這就形成了空回滾。
解決方法：讓 cancel 能夠識別出這是乙個空回滾，可以記錄事務執行狀態，cancel 中判斷 try 是否執行了。
提交階段異常時可能會重複呼叫 confirm 和 cancel，所以要實現冪等，保證多次執行效果一致。
解決方法：記錄事務執行狀態，如果執行過了，就不再執行。
現象是先執行了 cancel，後執行的 try，造成資源沒人釋放:呼叫 try 時網路擁堵超時，被認為失敗，然後呼叫 cancel，這時事務相當於結束了，但後來網路好點之後 try 開始執行了，鎖定了相關資源，因為事務已經結束，confirm、cancel 都不會再呼叫了，就造成資源懸掛，無法釋放。
解決方法：還是記錄事務執行狀態，try 執行時判斷 cancel 是否執行了。
詳見 分布式–3分布式一致性演算法
利用mq延時佇列，實現高併發下的定時任務，最終一致解除訂單或者解除庫存鎖定。
1）下單之後，鎖定庫存。
2）傳送乙個訊息給交換機，key為lock，經交換機發給延時佇列
3）延時佇列50分鐘後經過交換機，路由到relase
4）relase被監聽消費後，檢查訂單狀態是否要解鎖，業務處理
上圖還有個庫存解鎖模組，是可以手動或其他情況觸發解鎖（也可以其他業務直接放入relase佇列進行解鎖）
**：myrabbitconifg
分布式事務（二）分布式事務方案
首先這是普通事務 下面是分布式事務 在微服務系統中，每個微服務應用都可能會有自己的資料庫，它們首先需要控制自己的本地事務。一項業務操作可能會呼叫執行多個微服務。如何保證多個服務執行的多個資料庫的操作整體成功或整體失敗？這就是分布式事務要解決的問題。cap 和 base 是對大規模網際網路系統分布式實...
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...
分布式之分布式事務
被人問到分布式事務，之前學rabbitmq 的時候學到過rabbitmq 高階的事務，因為沒有用過，所有沒有回答好。這裡總結一下。1.單機版事務。事務的四大特性 acid a.原子性 b.一致性 c.隔離性 d.永續性 單機事務可以通過設定事務的隔離級別 參見spring 的事務隔離級別 2.分布式...