面試題
1、分布式事務了解嗎？
2、你們是如何解決分布式事務問題的？
面試官心理分析
隻要聊到你做了分布式系統，必問分布式事務，你對分布式事務一無所知的話，确實會很坑，你起碼得知道有哪些方案，一般怎麼來做，每個方案的優缺點是什麼。
現在面試，分布式系統成了标配，而分布式系統帶來的分布式事務也成了标配了。因為你做系統肯定要用事務吧，如果是分布式系統，肯定要用分布式事務吧。先不說你搞過沒有，起碼你得明白有哪幾種方案，每種方案可能有啥坑？比如 TCC 方案的網絡問題、XA 方案的一緻性問題。
面試題剖析
分布式事務的實作主要有以下 5 種方案：
- XA 方案
- TCC 方案
- 本地消息表
- 可靠消息最終一緻性方案
- 最大努力通知方案
兩階段送出方案/XA方案
所謂的 XA 方案，即：兩階段送出，有一個事務管理器的概念，負責協調多個資料庫（資料總管）的事務，事務管理器先問問各個資料庫你準備好了嗎？如果每個資料庫都回複 ok，那麼就正式送出事務，在各個資料庫上執行操作；如果任何其中一個資料庫回答不 ok，那麼就復原事務。
這種分布式事務方案，比較适合單塊應用裡，跨多個庫的分布式事務，而且因為嚴重依賴于資料庫層面來搞定複雜的事務，效率很低，絕對不适合高并發的場景。如果要玩兒，那麼基于
Spring+JTA
就可以搞定，自己随便搜個 demo 看看就知道了。
這個方案，我們很少用，一般來說某個系統内部如果出現跨多個庫的這麼一個操作，是不合規的。我可以給大家介紹一下， 現在微服務，一個大的系統分成幾十個甚至幾百個服務。一般來說，我們的規定和規範，是要求每個服務隻能操作自己對應的一個資料庫。
如果你要操作别的服務對應的庫，不允許直連别的服務的庫，違反微服務架構的規範，你随便交叉胡亂通路，幾百個服務的話，全體亂套，這樣的一套服務是沒法管理的，沒法治理的，可能會出現資料被别人改錯，自己的庫被别人寫挂等情況。
如果你要操作别人的服務的庫，你必須是通過調用别的服務的接口來實作，絕對不允許交叉通路别人的資料庫。
TCC 的全稱是：Try、Confirm、Cancel。
- Try 階段：這個階段說的是對各個服務的資源做檢測以及對資源進行鎖定或者預留。
- Confirm 階段：這個階段說的是在各個服務中執行實際的操作。
- Cancel 階段：如果任何一個服務的業務方法執行出錯，那麼這裡就需要進行補償，就是執行已經執行成功的業務邏輯的復原操作。（把那些執行成功的復原）
這種方案說實話幾乎很少人使用，我們用的也比較少，但是也有使用的場景。因為這個事務復原實際上是嚴重依賴于你自己寫代碼來復原和補償了，會造成補償代碼巨大，非常之惡心。
比如說我們，一般來說跟錢相關的，跟錢打交道的，支付、交易相關的場景，我們會用 TCC，嚴格保證分布式事務要麼全部成功，要麼全部自動復原，嚴格保證資金的正确性，保證在資金上不會出現問題。
而且最好是你的各個業務執行的時間都比較短。
但是說實話，一般盡量别這麼搞，自己手寫復原邏輯，或者是補償邏輯，實在太惡心了，那個業務代碼很難維護。
本地消息表其實是國外的 ebay 搞出來的這麼一套思想。
這個大概意思是這樣的：
- A 系統在自己本地一個事務裡操作同時，插入一條資料到消息表；
- 接着 A 系統将這個消息發送到 MQ 中去；
- B 系統接收到消息之後，在一個事務裡，往自己本地消息表裡插入一條資料，同時執行其他的業務操作，如果這個消息已經被處理過了，那麼此時這個事務會復原，這樣保證不會重複處理消息；
- B 系統執行成功之後，就會更新自己本地消息表的狀态以及 A 系統消息表的狀态；
- 如果 B 系統處理失敗了，那麼就不會更新消息表狀态，那麼此時 A 系統會定時掃描自己的消息表，如果有未處理的消息，會再次發送到 MQ 中去，讓 B 再次處理；
- 這個方案保證了最終一緻性，哪怕 B 事務失敗了，但是 A 會不斷重發消息，直到 B 那邊成功為止。
這個方案說實話最大的問題就在于嚴重依賴于資料庫的消息表來管理事務啥的，會導緻如果是高并發場景咋辦呢？咋擴充呢？是以一般确實很少用。
這個的意思，就是幹脆不要用本地的消息表了，直接基于 MQ 來實作事務。比如阿裡的 RocketMQ 就支援消息事務。
大概的意思就是：
- A 系統先發送一個 prepared 消息到 mq，如果這個 prepared 消息發送失敗那麼就直接取消操作别執行了；
- 如果這個消息發送成功過了，那麼接着執行本地事務，如果成功就告訴 mq 發送确認消息，如果失敗就告訴 mq 復原消息；
- 如果發送了确認消息，那麼此時 B 系統會接收到确認消息，然後執行本地的事務；
- mq 會自動定時輪詢所有 prepared 消息回調你的接口，問你，這個消息是不是本地事務處理失敗了，所有沒發送确認的消息，是繼續重試還是復原？一般來說這裡你就可以查下資料庫看之前本地事務是否執行，如果復原了，那麼這裡也復原吧。這個就是避免可能本地事務執行成功了，而确認消息卻發送失敗了。
- 這個方案裡，要是系統 B 的事務失敗了咋辦？重試咯，自動不斷重試直到成功，如果實在是不行，要麼就是針對重要的資金類業務進行復原，比如 B 系統本地復原後，想辦法通知系統 A 也復原；或者是發送報警由人工來手工復原和補償。
- 這個還是比較合适的，目前國内網際網路公司大都是這麼玩兒的，要不你舉用 RocketMQ 支援的，要不你就自己基于類似 ActiveMQ？RabbitMQ？自己封裝一套類似的邏輯出來，總之思路就是這樣子的。
這個方案的大緻意思就是：
- 系統 A 本地事務執行完之後，發送個消息到 MQ；
- 這裡會有個專門消費 MQ 的最大努力通知服務，這個服務會消費 MQ 然後寫入資料庫中記錄下來，或者是放入個記憶體隊列也可以，接着調用系統 B 的接口；
- 要是系統 B 執行成功就 ok 了；要是系統 B 執行失敗了，那麼最大努力通知服務就定時嘗試重新調用系統 B，反複 N 次，最後還是不行就放棄。
你們公司是如何處理分布式事務的？
來源：https://tinyurl.com/y4wzhojj