分布式事物 TCC模式見解

       随着網際網路浪潮不斷向前推進，企業不得不面對大規模的網際網路請求，在當今的網際網路發展中，新興起的微服務架構的模式不斷被創新和應用，而在微服務基礎當中，事物問題尤為突出，不能解決事物的問題，那麼整個微服務都是虛談，根本無從說起，本篇文章主要講解個人對于微服務中分布式事物TCC的見解。

       首先，所謂的TCC， Try Confirm Cancel，分别對應着确認一個事物完成的簡單三個過程，嘗試做某件事、确認做某件事、補充的取消做某件事，因為在分布式的事物當中，可能完成一件事情的過程由多個應用一起來完成，那麼傳統的單機性質的資料庫事物已經不能支援多個應用，或者說完成這件事情所涉及的表由多個資料庫組成，那麼為了保證一緻性、原子性，需要将這件事情進行分解，然後再組合起來的方式來共同完成。那麼跟TCC相對于的一些其他的解決性方案還有：可靠事件模式(事件的發送和接收保障高可靠性來實作事物一緻性)、補償模式(如果确認失敗，全部逆向取消)。

   TCC，仔細觀察，其由三部曲組成，回想一下資料庫的三部曲：DML、Commit、rollback.這之間是有異曲同工之妙的，try的操作能夠必須要能夠保證後面的commit以及rollback沒有問題，也就是try必須執行成功才能執行後續操作，字面意思即是要使得相對應的資源必須可用，并且鎖住，然後才有後續的comfirm，comfirm的操作需要有其他的事件來通知，執行confirm操作，相對應的，假如confirm失敗，就需要rollback操作，操作的内容與try相反，但是實際的業務的時候，可能會有稍微差別，隻要是釋放資源以及做其他的相關通知等。

   TCC操作事情：

   1、Try：嘗試執行業務。

• 完成所有業務檢查(一緻性)
• 預留必須業務資源(準隔離性)

    2、Confirm：确認執行業務。

• 真正執行業務
• 不做任何業務檢查
• 隻使用Try階段預留的業務資源

   3、Cancel：取消執行業務

• 釋放Try階段預留的業務資源
• 其他事件消息等通知

   TCC操作舉例：    一般系統中執行的積分扣除功能，因為積分扣除這項操作的發起可能是第三方的應用，與積分管理這個服務不在在應用内，為了使得事物一緻性，可以使用TCC模式處理。      1、Try：嘗試扣除使用者積分，扣除前必須對各項相關資料等做校驗，發現不合法的則直接退出，不執行後續操作。這步驟必須保證使用者有足夠的積分并且可以先扣除，假如後面取消執行業務，可以補回來，但是更多情況是往正常扣除的方向走的。這一點确定了積分扣除記錄可以寫了。      2.确認執行業務。在收到另外應用通知，發起扣除的應用業務已經執行完畢，比如積分抽獎或者兌換，收到消息确認沒有問題，可以正常扣除積分，因為在try操作上已經真實扣除了積分，這個時候就不用再處理了，隻是處理一些事務遺留的一些其他的處理，比如這個事物中一些狀态的确認等。     3.取消執行業務。假如收到第三方應用通知，取消執行業務，那麼則需要執行針對try步驟中的事情做復原，這裡不建議删除try的操作，而是執行新增補充的記錄來彌補，這個操作需要根據實際的業務來分析，這裡隻是簡單說一下，因為不同業務的復原操作和性質不一樣。在處理完成try步驟的復原後，後續其他消息的通知也是在這個步驟，比如告知使用者操作失敗等。    4.在執行完成上面三個步驟後，其他還是有一定漏洞的，漏洞的引起是因為一些不确定或者系統的性能等引起的，為了保障TCC能夠完整無缺，需要做一些其他彌補操作；首先是消息的通知，第三方應用與積分扣除進行了業務隔離，通過消息機制的話，消息有可能丢失，或者網絡等原因通知不到位，會導緻各種情況，這就要求TCC操作的完整性要好，而一些其他因素會破壞完整性，是以必須做一些彌補确認性的事情，使得完成性出現問題的時候，能夠系統自動處理或者人為及時處理。這一步的操作根據不同企業的系統架構使用不一樣的處理模式，而且與業務有關系，這裡就不再描述。