了解過tcc分布式事務的都知道它有三個階段：try，confirm，cancel，但很多文章就只有原理圖，和對原理圖的解釋，看一遍也留不下印象，這裡用實際場景舉個例子，說明tcc分布式事務原理
tcc分布式框架推薦：bytetcc，tcc-transaction，himly最終一致性方案一般都是有訊息中介軟體來完成的，核心流程如上圖所示
下面來考慮這中間會有什麼問題了，為什麼這樣能保證分布式事務的最終一致性？
越大的公司，考慮的就越多，任何元件都可能掛掉，mq如果就乙個集群，就要考慮這個集群壓力過大到爆掉了怎麼辦？資金雄厚併發壓力大的公司可以直接搞再搞一套備用的，當mq請求不通後，立即自動切換到備用mq集群，當然這肯定會造成資源的浪費，畢竟要再搞一套mq不執行一直放那裡，這裡再給出一套參考方案（如果你們有redis集群的話）
參考：拜託，面試請不要再問我tcc分布式事務的實現原理！
最終一致性分布式事務如何保障實際生產中99.99%高可用？
memcache分布式原理解析
所謂的分布式就是將不同的資料放在不同的伺服器上，獲取資料時需要根據路由從不同的伺服器上獲取。在memcache中，伺服器端並不支援分布式，而只是在客戶端程式中設定分布式。如果有多個memcache伺服器，那麼他們之間並不互相通訊，資料也無法同步。所以在很多語言對memcache操作的類庫中都可以配置...
Redis分布式鎖原理解析
首先設定上鎖的方式，用setnx lockkey，currenttime timout 來表示設定鎖，其中lockkey為我們所需要爭取到的鎖，value值則由當前時間和設定的超時時間組成。當我們爭取到鎖後，進行常規操作即可，接下來我們討論競爭鎖失敗後的優化。首先我們去得到lockkey的value...
分布式事務的理解
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...