目錄
微服務架構不可避免的要解決分佈式事務的問題，爲了避免出現分佈式事務，在進行微服務劃分的時候，我們一般儘量保證業務操作獨立，但是有時候分佈式事務又是不可避免的。業界關於分佈式事務的處理方案也有幾種，網上搜到比較多的就是TX-LCN框架。
官網：https://www.txlcn.org/zh-cn/index.html
1 TX-LCN框架的基本思路
這裏借用一張官網流程圖
可以看到，整體來說，每個微服務的事務還是由Spring自身處理，只不過，不管對於調用方還是被調用來說，在相關操作處理完之後，事務不會立馬提交，而是掛起的狀態。等到調用方處理完所有的業務操作之後，調用方會通知tm，tm會通知該事務組對應調用鏈上的所有tc，提交或者回滾對應的事務。
這裏有幾點需要注意：
（1）tm在通知tc進行事務的回滾和提交時，可能會因爲網絡或者超時參數配置原因出現失敗，如果出現失敗，tm會忘t_tx_exception表中插入一條記錄，然後自動進行事務補償，即：重試通知。
（2）TCC模式可以處理非數據庫事務方式的“事務”操作，例如A調用B和C，其中C使用的是不支持事務的數據庫，此時A和B使用LCN模式，C使用TCC模式，TCC模式會自己重寫onConfirm和onCancel方式，即事務的提交和回滾操作需要自己定義，這就爲不支持事務的數據庫提供瞭解決方案。
下面記錄下使用TX-LCN框架時候遇到的問題以及注意點。
2 遇到的問題記錄
2.1 事務提交/回滾失敗，鎖表問題
問題描述：日誌查看都正常，但是就是數據插入失敗，而且後續再操作會一直表鎖。
默認情況下TC是使用應用名稱(spring.application.name)加端口號作爲模塊名稱的。這種情況在單服務情況下沒問題，但是如果微服務橫向擴展集羣部署的時候，就會有問題。例如A服務進行集羣部署分爲A1和A2。此時在TM上註冊的模塊名稱有兩個一模一樣的記錄。當TM通知的時候，會因爲模塊名稱標識一樣，出現該提交的事務沒收到提交消息提醒，造成事務一直不提交，表鎖的問題。
解決方法：
針對這種方式，官網也有解決辦法，可以通過TC模塊標識自定義方式來解決
@Component
public class MyModIdProvider implements ModIdProvider
{
@Value("${eureka.instance.ip-address}")
private String ip;
@Value("${server.port}")
private String port;
@Override
public String modId()
{
return ip+":"+port;
}
}
這裏貼一個截圖，第一條是自定義模塊標識，第二條是默認的。
解決了模塊標識唯一的問題，也就解決了事務通知混亂的問題，也就沒有表鎖了。
2.2 事務補償失敗
tc和tm之間的通信是通過tcp建立的可靠有保障的長鏈接，但是通訊總是難免受到網絡狀況的影響，當tm通知tc時候的時候，tm會自動進行事務補償，但是測試的過程中，發現事務沒有補償，而且在管理平臺上也查看不到相關異常記錄，對應的t_tx_exception表中也沒有記錄。跟蹤應用的日誌發現，有包jpa的相關異常。查看源碼後，發現引起該問題的主要原因是TxException表的生成策略設置的AUTO，AUTO的話主鍵的生成策略是JPA自己的策略。
但是對應表t_tx_exception的主鍵是自增，這就造成在出現異常的時候，無法把異常插入到異常表，最終導致事務補償失敗。
解決方案：
修改爲IDENTITY然後重新編譯下即可。