mysql中，我們可以使用begin開始事務，rollback回滾事務，commit提交事務
redolog 記錄變更、undolog回滾
spring中，使用@transaction標記事務
原子性（atomic）
要麼全部成功，要麼全部失敗，沒有中間狀態
一致性（consistency）
指的是在執行事務前後，事務外訪問資料的時候，資料是一致的，要麼看到的是成功的，要麼看到的是失敗的結果，不會多工查詢到的資料不一樣。
隔離性（isolation）
乙個事務在未完成時，另乙個事務不會影響到他
永續性（durability）
會有持久化效果，改變是永久的
隨著系統越來越龐大，我們為了提高可用性、維護性、吞吐量等等技術指標，可以採用soa來改善原有架構，業務計算的問題解決後，資料庫便成了整個系統中的瓶頸
資料庫集群/分布式儲存方案在當前最主流的便是採用分庫分表方案做多機儲存和負載
分庫分表能減少單錶
在多機儲存的環境下，傳統的事務機制便無法正常執行了。
表垂直拆分
把表中的列拆分成多個部分，就是把一張很多欄位的表，拆分成多個表
表水平拆分
按行拆分，一張表裡的行數越多，查詢效率越低
水平拆分指定就是把原來的一張表中存放的資料按照固定行數拆分成多個表來儲存
分表後依然可以使用本地事務，但是單機負載依然是瓶頸。
分庫分庫指的是
微服務下的多庫儲存
回想cap定理和base理論
base通過允許損失部分可用性來提高資料最終一致性
強一致性會帶來系統大量的損耗，存在單點故障問題，在提交事務階段會產生阻塞，直到結束才會釋放資源。高併發場景下表現並不好。
二階段提交協議
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-xm2kgjzk-1596527139136)(images/8af234a0-6ed1-11e9-9f49-6f4505f5df5e)]
二階段提交協議可以保證資料強一致性
二階段
角色:
參與者
二階段提交把事務分為兩個階段，即準備階段和提交階段，準備階段負責收集每個參與者提交資料的預提交資訊，其實是收集每個資料節點是否能夠成功執行命令，
如果其中某些節點無法執行，那麼會反饋給協調者失敗資訊，然後協調者會傳送回滾資訊到每個資料節點以保證一致性
如果全部返回準備好的訊息，那麼協調者會正式向資料節點提交資料變更。
問題同步執行
每一次收集準備資訊都需要等所有資料節點返回資訊，造成同步等待。
單點故障
需要考慮資料節點和協調者的單點故障問題
執行提交
資料節點提交變更，無法保證是否真正提交了
二階段提交存在很多潛在和小概率問題，那麼在資料一致性要求高的場景下會造成資料不一致的現象發生，一旦發生資料不一致的情況後，後續人工干預的操作會浪費大量的時間，對銀行、餘額這類業務，還有可能造成資產流失。
三階段提交協議
三階段提交是對二階段提交的改良版本，增加了預備階段，解決了同步阻塞問題。
tcc模式
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-s1cyf4bm-1596527139143)(images/0e53e470-6ed1-11e9-8477-e9d92585d062)]
tcc
tryconfirm
cancel
主業務事務管理器
執行流程
第一階段
第二階段
t -> cc關係繫結
t是由主業務發起的，cc操作和t操作不在一台機器上
try階段進行了鎖定資源操作，鎖定不成功就認為是不可進行的，鎖定成功就最終一定會成功。
框架tcc-transaction
hmily
bytetcc
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-xhcurefj-1596527139155)(images/hmily-framework-1572255210660.png)]
aop
tcc 通過aop，面向切面程式設計來對confirm/cancel操作透明化
冪等
資料庫中的唯一索引
分布式鎖
狀態機補償模式
重試固定次數，固定時間，訊息佇列，定時任務
下一次訪問修復
定時校對/核對 quartz、xxl-job、elastic-job
事務 一定是由多個操作組成的嗎？
96527139155)]
aop
tcc 通過aop，面向切面程式設計來對confirm/cancel操作透明化
冪等
資料庫中的唯一索引
分布式鎖
狀態機補償模式
重試固定次數，固定時間，訊息佇列，定時任務
下一次訪問修復
定時校對/核對 quartz、xxl-job、elastic-job
事務 一定是由多個操作組成的嗎？
億級流量系統多級快取架構8 服務降級
在高併發場景下，當系統中的一些功能元件出現異常，無法繼續提供伺服器的時候，為了保證整體系統可用性，可以犧牲一部分功能依舊提供有損服務 服務等級定義 sla service level agreement 是判定壓測是否異常的重要依據。壓測過程中，通過監控核心服務狀態的 sla 指標資料，您可以更直觀...
架構知識總結 3 分布式快取架構（下）
目錄 1 怎麼才能夠突破單機主從架構瓶頸，讓redis支撐海量資料？redis中分布式資料儲存的演算法 什麼是redis的雪崩和穿透？如何保證快取與資料庫的雙寫一致性？使用cache aside pattern redis的併發競爭問題是什麼？如何解決這個問題？了解redis事務的cas方案嗎？re...
03分布式電商專案 系統架構
soa 是 service oriented architecture 的首字母簡稱，它是一種支援面向服務的架構樣式。從服務 基於服務開發和服務的結果來看，面向服務是一種思考方式。其實 soa 架構更多應用於網際網路專案開發。為什麼網際網路專案會採用 soa 架構呢？隨著網際網路的發展，應用的規模不...