建站
咨詢
售后
建站咨詢
新聞中心
分布式事務(wù)往往是服務(wù)化的痛點，很多場景通過業(yè)務(wù)避免了分布式事務(wù)，但是還是存在一些場景必須依賴分布式事務(wù)，下面來講講如何處理分布式事務(wù)
成都創(chuàng)新互聯(lián)長期為上千余家客戶提供的網(wǎng)站建設(shè)服務(wù)，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為新洲企業(yè)提供專業(yè)的網(wǎng)站建設(shè)、成都網(wǎng)站制作，新洲網(wǎng)站改版等技術(shù)服務(wù)。擁有10多年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
一 常用解決方案
分布式事物解決方式有很多，網(wǎng)上博客也有一大堆 總結(jié)一般有如下兩種
1 剛性分布式事務(wù)，兩階段提交 強一致性
2 柔性分布式事務(wù) 最大努力提交 ,tcc,可靠消息服務(wù)
首先解決分布式事務(wù)前提保障：接口必須冪等性，防止消息重復(fù)發(fā)送對業(yè)務(wù)影響
二 可靠消息系統(tǒng)設(shè)計（這個感覺不錯比較簡單，就拿來分享下）
如上圖
開始執(zhí)行 比如：try{if(prepare()) { //預(yù)發(fā)送階段doService(); //執(zhí)行業(yè)務(wù)邏輯updateMsgStatus();//更新消息為確認狀態(tài)}}
1 預(yù)發(fā)送消息，try階段，如果預(yù)發(fā)送消息失敗了，業(yè)務(wù)還未執(zhí)行，所以 系統(tǒng)A，B還是一致性的 不需要處理
這一點容易理解
2 預(yù)發(fā)送消息成功了，開始執(zhí)行業(yè)務(wù)邏輯。執(zhí)行成功 更新預(yù)發(fā)送消息轉(zhuǎn)態(tài)為確認發(fā)送。如果 此時 業(yè)務(wù)邏輯執(zhí)行失敗了，那預(yù)發(fā)送消息就不會跟新狀態(tài)，此時消息確認系統(tǒng)就開啟工作，到業(yè)務(wù)系統(tǒng)1上回查此消息狀態(tài)，此時發(fā)現(xiàn)業(yè)務(wù)執(zhí)行失敗了，就更新預(yù)發(fā)送狀態(tài)至失敗狀態(tài)。
3 如果此時 業(yè)務(wù)執(zhí)行成功了消息也被更新成確認發(fā)送了 那就ok 完美。如果消息更新失敗，還是由消息確認系統(tǒng)回查轉(zhuǎn)態(tài) 更新此消息被刪除狀態(tài)還是確認發(fā)送狀態(tài)。
4 消息者開始消費
1> 比如消費失敗了，此時產(chǎn)生不一致， 消息恢復(fù)系統(tǒng)檢測消息狀態(tài)，重新發(fā)送消息
2>如果執(zhí)行業(yè)務(wù)失敗了，此消息也就不會被確認了，還是由消息恢復(fù)系統(tǒng)檢測消息狀態(tài)，重新發(fā)送消息
3>如果ask失敗了，還是以上邏輯重新發(fā)送上訴重新發(fā)送當然有次數(shù)限制，不能一直發(fā)送，超過最大次數(shù)就要進入死信隊列，等待人工干預(yù)了
4> ask成功，消息也就成功消費了，完美，解決了消息可靠服務(wù)
三 努力提交
這個比較簡單 ，將失敗的消息重復(fù)提交，實時性比較弱的一些場景，確保消息推送成功。
比如交易完成推送第三方消息。 此時可以使用努力提交
當前題目：可靠消息服務(wù)實現(xiàn)具體方案
文章來源：http://www.dlmjj.cn/article/djiidgs.html
