當前工作只分表並未分庫
分布式事務解決方案:
兩階段提交:xa介面規範
1.表決階段,將所有參與者的是否可提交狀態都反饋給協調者
2.執行階段,決定是否提交或者回滾;
鎖定資源時間長,同步阻塞的,不能確定是準確的事務,有些會宕機
tcc方案:try,confirm,cancel
1.業務應用會向事務協調器註冊事務
2.業務應用呼叫所有服務的try介面
3.業務應用返回給協調器狀態,呼叫confirm或者cancel介面
業務入侵強,都需要實現介面,需要實現多種回滾策略;
基於訊息佇列的:
1.a系統的業務**和訊息傳送**放到同乙個事務中,
2.b系統訂閱訊息進行資料庫操作
入侵強,需要大量改造
gts:分布式事務中介軟體
優點:1.效能強:acid,高可用,高效能;
2.應用入侵少,只加註解就可以
3.支援多種框架dubbo,springcloud等,如果需要呼叫第三方,而第三方沒有接入gts,則需要開啟mt模式,等價於tcc,自定義多種行為
4.解決協調者單點的問題,保證資料一致性
整合:1.客戶端(client):完成事務的發起與結束。
2.資源管理器(rm):完成事務分支的建立,提交,回滾等操作.
3.事務協調器(server):主要負責分布式事務的整體推進,事務生命週期的管理
基於gts的開源版本fescar:
生命週期:
1.業務應用要求協調者開始全域性的事務,並生成乙個呼叫鏈的id
2.通過微服務的呼叫鏈傳播,在進行資料庫操作的時候會先獲取xid,進而傳播到下乙個服務;
3.分支事務將在協調者中註冊為xid的響應的全域性事務;
4.業務要求協調者提交或者回滾響應的事務;
5.協調者驅動事務分支進行提交或回滾
新增@globaltransactional註解就可以
事務 分布式事務解決方案
事務acid特性 事務隔離級別 指的是讀和寫同時出現時出現的資料不一致問題。事務的一致性問題 存在問題問題描述 髒讀 dirty read 針對的是單條資料。即乙個更新操作a修改了某一條資料，但尚未提交該事務，此時另乙個讀操作b來查詢該條資料，讀到的是修改後的但尚未提交的資料。不可重複讀 unrep...
分布式事務解決方案
一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性，分為三個階段tryi...
分布式事務解決方案
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...