下面是一道面試題，而且我完全想不到我會卡到這道題上，因為也了解過一些分布式問題的解決方案
題目：微服務之間的呼叫路徑為 a->b->c，問如果b呼叫c的時候一直出問題（比如c宕機），我們如何保證資料一致性？
在我理解，這就是典型的分布式事務問題，所以我考慮如下方案：
1. mq：無論a、b、c監聽事件失敗訊息，並針對不同業務型別和業務id進行回滾操作即可
2. tcc：每個服務都開發t、c、c三種型別的介面，a呼叫b的try操作成功，當b呼叫c的try失敗次數達到閾值後，先執行自己的業務cancel方法，然後呼叫a的cancel介面
3. 軟狀態：a呼叫b的時候執行為預操作狀態，b呼叫c如果成功也執行為預操作狀態，這樣無論哪一環出了問題，都不會影響業務資料的一致性。因為中間狀態的資料，對於業務一定是不可用的狀態。我們只需要在呼叫失敗的時候做出相應的通知等其他處理策略即可（比如通知+人工，定時任務處理軟狀態等）。如果都執行為預操作狀態成功，再觸發修改為執行狀態
然後我說這就是分布式事務的問題，比如兩階段提交什麼的都可以解決，然後面試官緊接著來了一句話「其實可以不用分布式事務來解決的」，這是我就陷入了困惑，難道是b呼叫c一直失敗的時候，b直接列印日誌通知人工處理？還是呼叫失敗後我們插入表，等c恢復後批量處理資料？或者直接回滾a->b的操作？
分布式 集群 微服務
微服務是架構設計方式 分布式是系統部署工作方式 集群是個物理形態 微服務是啥？這裡不引用書本上的複雜概論了，簡單來說微服務就是很小的服務，小到乙個服務只對應乙個單一的功能，只做一件事。這個服務可以單獨部署執行，服務之間可以通過rpc來相互互動，每個微服務都是由獨立的小團隊開發，測試，部署，上線，負責...
微服務 分布式服務框架
spring cloud rest與rpc比較 dubbo 和 spring cloud 對比 通訊協議 傳輸的格式都屬於協議 服務路由 分布式服務上線時都是集群組網部署，集群中會存在某個服務的多例項，消費者如何從服務列表中選擇合適的服務提供者進行呼叫，這就涉及到服務路由。分布式服務框架需要能夠滿足...
分布式服務呼叫
分布式服務呼叫策略 1.lvs 中間 負載均衡系統做 優點 代價低，可控性強 缺點 流量壓力大 必由之路，雞蛋不在乙個籃子裡 應用 面向c端 2.名稱服務 各呼叫方機器 自己根據策略進行負載均衡 優點 名稱服務不會直接影響功能 減少了中間的頻寬消耗 缺點 公升級較複雜 當拉起一台伺服器，需要把新的i...