1樓：千鋒java學院
題主的這個問題是乙個分布式事務的問題，根據題主對問題的描述，應該是需要保證事務的最終一致性。目前保證事務最終一致性的實現方式很多，但是基本採用的是TCC方案。在聊TCC方案之前先需要弄清楚事務如何保證一致性的問題。
傳統單體資料來源的事務一致性形象比如如下圖實現：
如上圖所示，只有一條道（好比程式異常），如果帶路不通，所有人就無法到達終點，都只能掉頭回去（程式回滾）。這裡的道路就好比單個資料來源。但是如果有多個資料來源，情況就不一樣了，看下圖：
（圖2）
如上圖，多個資料來源就好比上面的多個道路，有兩個人，分別從上下兩條路到終點匯合。但是綠色的1號線路不通，1號人只能回頭並終止計畫；但是2好人道路暢通可以到達終點。這就導致最開始約定終點匯合的計畫失敗。
這就好比多個資料來源，大家約定一起新增資料成功是最終目標（一致性）。但是不確定因素太多，有資料失敗了，就無法達成資料一致性了。要解決這個問題，就可以採用如下這套方案：
還是上圖的兩條路，1號人和2號人出發之前，先派人去探路，確認兩個路都是通的。（Try）
之後1號人和2號人再分別選擇兩個路線出發。（Confirm）
最終到達終點。
回到第一步，如果探路的人發現路不通，那麼直接告訴大家不要走了，終止計畫。這樣就不會導致乙個人成功乙個人失敗了。（cancel）
上面這個方案就是TCC方案的簡單理解。什麼是TCC呢？分別是三個單詞Try-Confirm-Cancel。
字面意思就是嘗試-確認-取消。就跟我上面步驟中第1步後面寫的try，因為第1步就是嘗試找個人先探路，不是真的執行任務；當探路沒有問題就執行第二步，也就是Confirm了。如果探路有問題就執行第4步，也就是Cancel了。
在實際操作過程中，可能業務不同，服務架構不同，使用的技術實現也不同。分布式事務理論還有2PC和3PC方案。還有借助MQ的方案如下：
2樓：
Elasticsearch 不支援事務，這個單獨說。
Mysql 和 Redis 這件事情好做，只要讓其二者的 Transaction 同時結束即可，一般不用考慮在 Commit 階段同時失效的問題。
對於Elasticsearch 建議是監聽 Mysql/Redis Commit 的成功事件，然後再寫入，畢竟 Elasticsearch 插入都是非同步的模式。
3樓：kido-spread
僅通過spring的事務是無法滿足你的要求的~針對這種情況，我們一般會用binlog工具來實現（canal或databus），通過解析binlog來更新redis
至於更複雜的業務，我推薦你看下《快取與資料庫一致性系列》，由淺入深的分析各種方案
DevOps 研發（Java）和 Java 開發我該選擇哪乙個？
任衛 大量公司理解錯了Devops，我不騙你，不過我建議你加入devops和我一起宣傳正確的Devops姿勢。devops是一種軟體專案 特別是網際網路專案 的全生命期管理理念。僅僅維護個jenkins維護個ci cd工具，並不是完整的devops。devops本質上就是開發人員運維人員通力合作，開...
為什麼JAVA中有多個public存在？
佐玄 並不是只有乙個public，public是標明訪問許可權的，可以放在類上和方法上屬性上，乙個類可以有多個方法多個屬性，所以你可以分別在每個方法每個屬性上都設定他們的訪問許可權，但是類只能有乙個公開的類，也就是乙個檔案裡只能有乙個類是用public修飾的，也可以寫其他的類但是不能是public修...
java開發真的超捲了嗎？
教育巨頭 其實很多人並不清楚內捲是什麼？甚至會以為這指的是頭髮天然卷向內捲。那咱們首先要知道內卷到底是什麼？內捲是2020年出現的流行語之一，最開始是由美中國人類學家格爾茨提出來的，其意義指的是 向內演化 所有沒有實質意義的消耗都可以稱作內卷，而這個詞傳到中國之後，多用以形容高校或者職場裡面的 非自...