分散式事物 TCC模式見解
阿新 • • 發佈:2019-01-06
隨著網際網路浪潮不斷向前推進,企業不得不面對大規模的網際網路請求,在當今的網際網路發展中,新興起的微服務架構的模式不斷被創新和應用,而在微服務基礎當中,事物問題尤為突出,不能解決事物的問題,那麼整個微服務都是虛談,根本無從說起,本篇文章主要講解個人對於微服務中分散式事物TCC的見解。
首先,所謂的TCC, Try Confirm Cancel,分別對應著確認一個事物完成的簡單三個過程,嘗試做某件事、確認做某件事、補充的取消做某件事,因為在分散式的事物當中,可能完成一件事情的過程由多個應用一起來完成,那麼傳統的單機性質的資料庫事物已經不能支援多個應用,或者說完成這件事情所涉及的表由多個數據庫組成,那麼為了保證一致性、原子性,需要將這件事情進行分解,然後再組合起來的方式來共同完成。那麼跟TCC相對於的一些其他的解決性方案還有:可靠事件模式(事件的傳送和接收保障高可靠性來實現事物一致性)、補償模式(如果確認失敗,全部逆向取消)。
TCC,仔細觀察,其由三部曲組成,回想一下資料庫的三部曲:DML、Commit、rollback.這之間是有異曲同工之妙的,try的操作能夠必須要能夠保證後面的commit以及rollback沒有問題,也就是try必須執行成功才能執行後續操作,字面意思即是要使得相對應的資源必須可用,並且鎖住,然後才有後續的comfirm,comfirm的操作需要有其他的事件來通知,執行confirm操作,相對應的,假如confirm失敗,就需要rollback操作,操作的內容與try相反,但是實際的業務的時候,可能會有稍微區別,只要是釋放資源以及做其他的相關通知等。
TCC操作事情:
1、Try:嘗試執行業務。
- 完成所有業務檢查(一致性)
- 預留必須業務資源(準隔離性)
- 真正執行業務
- 不做任何業務檢查
- 只使用Try階段預留的業務資源
- 釋放Try階段預留的業務資源
- 其他事件訊息等通知