您現在的位置是:網站首頁> 世界杯半全场是什么意思

“若干分布式事務框架”與“我的偏見”

  • 大紅鷹dhy0002
  • 2019-04-25
  • 392人已閱讀
簡介本文來談談我對若干分布式事務框架的看法,只談設計時導致無法輕易改變的硬傷(或者說我的偏見),其優點應該已表現在其文檔中,不再贅述。至于我的偏見能不能成為你的偏見,請自行思考核實,僅供大

世界杯半全场是什么意思 www.ezveqs.com.cn 本文來談談我對若干分布式事務框架的看法,只談設計時導致無法輕易改變的硬傷(或者說我的偏見),其優點應該已表現在其文檔中,不再贅述。至于我的偏見能不能成為你的偏見,請自行思考核實,僅供大家選型時開拓思路使用。

靶子

以下我略有了解的框架將成為靶子:

TransactionsEssentials(atomikos免費版)tcc-transactionByteTCChmilytx-lcnGTSEasyTransaction

TransactionsEssentials

其是atomikos公司的兩階段提交事務的免費版本,說到兩階段提交大家第一印象應該都是慢,第二印象應該就是很方便,編碼少。

但實際上有多慢呢?可能大家都不太確定,我這里有一組數字供大家參考,相同業務場景,兩個服務有數據協同需求:

若兩個服務在同一庫中,單庫事務可達600TPS+但Atomikos速度為40-70TPS

當然,這里沒有給出具體的場景與配置,確實差值也有點大,我當時也是不太相信的。但我從多個不同測試數據源獲得的數據都較為類似,大家有空可以協助驗證下,然后評論給下數據。

所以對于TransactionsEssentials這個框架,我的偏見就是,太慢。

tcc-transaction

這是一個在GITHUB上開源了很久的框架了,其STAR數量接近3K,其代碼簡潔易懂。但其有三個缺點:

慢應用Crash時有幾率導致持久化的事務狀態不正確不支持框架冪

慢的原因

事務日志使用一個數據庫的變長字段存儲會多次更新該字段該字段存儲的內容不斷變長,使其不能在磁盤中原地更新,導致頁的分裂,或者導致該字段從頁中移除,涉及大量IO

CRASH不一致的原因

其CRASH后純粹依賴事務日志判斷全局事務狀態(Trying,Confirming,Canceling)然而該事務日志記錄的事務狀態是無法與業務數據庫的事務狀態保持強一致的(若能,則需要引入2PC等手段,是不是很矛盾)因此在Crash時導致事務日志狀態不正確時,按照目前的設計是需要人工介入排查問題的

不支持框架冪等

這會導致業務開發工作量大大增加。

ByteTCC

ByteTCC是一個兼容JTA規范的基于TCC機制的分布式事務管理器。

其實個人覺得基JTA規范擴展的TCC實現并非一個特別好的想法,其

強制Spring的PlatformTransactionManager要支持JTA,需要用戶修改原有的PlatformTransactionManager使用了ByteTCC自行實現的UserTransaction(JTA相關接口),并在里層整合"TCC"及“真JTA”的控制邏輯,這違反了編程里的開閉原則用自定義實現類替換掉了客戶原有實現中可能更為可靠的JTA/JDBC事務,即單機事務的代碼邏輯也被改了在JTA接口中整合“真JTA”及“TCC”的邏輯交錯在整個實現中,沒有很好地分離邏輯,不利于閱讀,也不利于修改限制了使用其他的JTA實現

不知道大家有沒有聽懂我上面說了什么,其實就是說,如果讓我來設計,我是盡量不會對原有邏輯進行修改,而是對邏輯進行擴展,這樣才能最大程度的程序的安全性,也能更好地與原有邏輯整合。

舉個例子,EasyTransaction里就是基于擴展實現了各種功能,其能保證原有事務處理邏輯完全不變,僅僅只是外掛了TCC、可靠消息等等的實現,同等情況下,其實現的理論風險會更小,并且EasyTransaction能無縫兼容JTA事務以及EasyTransaction內的各種事務,并協調一起工作,而ByteTCC則由于其實現形式,難以簡單做到。

另外一個方面是其代碼變得過于復雜,至少對我來說有理解難度,需要一些額外的知識支撐,不知道其他人的看法是怎樣的。

同時關于冪等,ByteTCC只支持Confirm及Cancel操作的冪等,不過這比很多框架都要強了。

hmily

這個框架的主要描述是“高性能分布式事務tcc方案開源框架”,個人感覺其之所以這么聲稱是因為“采用disruptor框架進行事務日志的異步讀寫,與RPC框架的性能毫無差別”。

這里有兩個個人認為的硬傷(也許是偏見吧):

異步寫入事務日志就等于TCC是不可靠的持久化IO瓶頸才是一個分布式事務框架的主要瓶頸,其并非Disruptor框架主要針對的CPU瓶頸

為什么不可靠

就一個簡單的問題吧,事務日志存儲連接不上(網絡斷掉/掉電了),這時異步寫入的日志放到內存了,然后遠程的訪問請求TRY發出去了,這個時候應用CRASH了。這就會導致TCC日志不完整,從而導致事務無法恢復。

有一些觀點認為這些情況極其少見,不需處理,那我們并發編程時volatile之類的同步手段還需要用么?

并且異常都是連鎖的,它并不是孤立出現的,我們無法預判會出現什么異常情況,也有墨菲定律說,越擔心的事情越有可能發生,因此我們對于這類情況必然是雖然我們不能保證實現完美,但是我們的理論至少要使完美的。

異步的Disruptor并不能解決矛盾的主要方面

我們知道,CPU的速度會比持久化IO的速度高很多個數量級,因此,基本上涉及持久化時,IO必然才是主要優化的目標。

因此我們做優化時,仿照KAFKA等,批量匯集數據,批量IO才是正確的解決之道。不做這個而去優化CPU性能這有點本末倒置,同時據我了解的多個測試結果中,hmily的性能都大幅不及EasyTransaction。

也不支持框架冪等

同上Tcc-transaction

tx-lcn

這個框架本質上是一個BestEffors 1PC的框架,是什么意思呢,也就是大多數情況下,只要應用不Crash就不會導致不一致。

這里帶來什么矛盾呢?除非你不關心不一致,允許數據出錯不修復,但一旦出現數據不一致一定要修復的情況的話,就要走人工補償處理,或者調用相關的修復程序。

而人工補償處理,實際上,也就相當于人肉寫了一遍修復程序,而且人肉執行還沒留下代碼,下次出問題還要人工再分析處理一遍。

因此,結論很明顯:

對于允許數據不一致的數據來說用BestEffors 1PC挺好的,性能高于2PC,代碼量與2PC一樣。但是對于數據出現不一致時,必須修復的情況我們必須要寫對應的修復程序這實際上跟TCC/補償等工作量一樣了為啥不切換到TCC/補償等性能更加高的形式并且使用BestEffors1PC寫的業務代碼在出現數據異常時,并不能保證其后續的補償是可執行的。舉個例子,轉賬,出現了給別人加錢了,但是自己沒有扣錢的數據異常,此時兩位客戶就有可能立馬把錢取出來用掉

tx-lcn這個框架是有適用場景的,但是我個人覺得最好把相關的厲害關系放到險要位置,不然有巨多小白無腦就用了,而不知道其中的坑,我覺得不太好。

GTS

這個框架的偏見嘛,主要就是臟讀了。貼一段之前寫過的文字。

GTS確實很贊,其核心原理是補償。

但這個補償做得很屌,補償操作由框架自動生成,無需業務干預,框架會記錄修改前的記錄值到上面的txc_undo_log里,若需要回滾,則拿出undo_log的記錄覆蓋回原有記錄

同時這里存在一個事務隔離級別的問題,GTS的做法是默認臟讀,那么就可以直接拿數據庫記錄展示(但個人覺得應該可以不做臟讀,直接拿undo_log里的記錄做mvcc,只要undo_log記錄不大,都可以加載到內存里)。

還有另外一個問題是如何禁止其他事務對進行中的全局事務記錄的更新,GTS的做法是需要接管APP中的數據源,這樣就可以解析控制業務要執行的SQL,對于update操作(或者select for update),予以禁止或等待。

不過整體的做法相當于魔改數據庫,將數據庫的部分功能拉到了業務APP里進行,并修改了默認隔離級別(臟讀,如果業務有用數據庫記錄樂觀鎖來控制并發的話,將會失效),還有就是,不通過GTS的定制數據源訪問會訪問修改到未提交數據

EasyTransaction

這個嘛,是我自己寫的框架,上面出現的偏見,在我這里都不會有,這篇文章本質是個軟文,哈哈,所以ET在我這沒有偏見,但我匯總下ET的優點把:

真正的高性能,對IO做了大量優化,多個獨立三方公司橫向評測分布式事務框架時,同等場景及同等可靠性保證下性能最佳(可自行驗證測試)理論上只要外部組件不丟數據,在ET內部是不會出現事務不完整的情況(相對于上面一些框架,其原理就不可靠,運行出現異??梢運凳潛厝壞模┲С摯蚣苊蕕?,業務程序程序不再需要接管 冪等、調用時序錯亂處理等繁瑣重復邏輯(這個是一個繁瑣重復的工作,貌似只有ET對本項進行了完整支持)基于擴展的實現,而非基于修改的實現,更易理解,風險更小,功能更強大支持多種事務形態(TCC,補償,可靠消息,SAGAs等)混合使用,可按照最適合業務的選擇最貼切的事務形態(這時ET創建之初的理念及特點,也是其他框架所不具有的特性)

總結

以上的偏見是不成熟的小想法,若有不正確,各位大佬盡管在評論區拍磚。同時本文僅供各位大佬選型時開拓思路,我認為的偏見不一定就是你的偏見,可能僅僅只是考慮角度、設計理念不一樣而已。

個人認為EasyTransaction的理念、設計、可靠性、性能等都不會比上面的框架差,但ET的STAR數量卻不及上面的各個開源框架,我覺得一定是ET有什么我自己沒有察覺到的缺陷,請大家拍磚以促進本框架進步,可以直接評論,或者到GITHUB上提ISSUE,感謝你的改進建議!

https://github.com/QNJR-GROUP/EasyTransaction

文章評論

Top