菜菜哥，如今北京疫情這麼厲害，出京到外地都會被排斥呢程序員
因此呀，你應該老實的呆在北京，不要給國家添亂web
爲了給國家少些負擔，昨天我去作了核酸檢測，那人多人，排好長的隊面試
新冠疫情，人人有責嘛數據庫
你猜怎麼着，這種排隊和程序中的消息隊列好像微信
同窗，你果真骨骼驚奇，是塊程序員的料cookie
這讓我想到分佈式系統中，那些消息隊列的數據處理，消費者若是處理消息異常了怎麼辦呢？session
那就要看具體場景具體需求了，不過多數狀況下也不外乎如下幾種情形架構
一旦談到分佈式，微服務等這些具備很高逼格的代名詞，總能讓你在面試中脫穎而出，不是由於這些詞的英文翻譯的好，而是現代互聯網乃至企業級開發確實在分佈式，微服務等模式下取得了良好的架構效果。不管是微服務，仍是以前的SOA，老是離不開異步處理模型，小到程序中IO的處理，大到系統間的消息交互，到處都有異步的身影。併發
談到系統之間的消息異步處理，就不能不談消息隊列（MQ），目前業界比較流行的MQ類型請自行百度腦補。可是須要提醒一下，MQ只是實現數據異步處理的一種解決方案，沒有MQ能不能實現異步處理呢？固然能，最簡單粗暴的莫過於採用數據庫方式，消息生產者直接把數據插入數據庫，消費者採用讀取數據庫的方式來獲取數據，因此MQ並不等於異步處理哦。app
異步消息處理最大程度上解耦了各個系統，爲每一個系統獨立擴展提供了更大空間，可是異步消息處理也同時面臨着一些挑戰，好比：消息管道性能，消息管道的高可用等，其中最貼近業務層的可能非「數據異常處理」莫屬，基本上可認爲這是數據處理模型的最末端，數據流向的尾部，但每每倒是業務中比較重要的部分。
若是一條異步消息做爲一個分佈式事務中的一環，那還設計到消息處理結果的反饋，分佈式協調器會根據消息結果的成功與否來決定的事務的結果。
單就異步消息消費端來說，根據不一樣的業務場景就有如下幾種異常處理方案
這是全部異常數據處理方案中最粗暴，同時也是最簡單的一種：發生異常的時候，直接忽略，什麼都不作。
面對異常不採起任何措施，乍一聽這多是個很糟糕的方案，可是在實際業務中，這多是徹底能夠接受的。若是由於錯誤致使的損失很小，甚至能夠忽略，可是創建一套錯誤糾正機制的成本遠遠高於忽略異常，這種場景下選擇直接忽略每每是一種更優的方案。並且當錯誤糾正機制設計到須要人工介入操做的時候，代價會更高，並且還會引入影響其餘業務的可能，更爲可怕的是若是錯誤糾正機制自己出現問題，那代價更是.....
舉個很簡單的栗子：像一些登陸日誌的統計操做，若是處理某我的登陸的數據出現異常，每每會選擇直接忽略。由於統計這種業務自己就帶有數據的容錯機制，100000和100001在統計需求看來沒有什麼區別。
當直接忽略的方案不可行的時候，你可能須要重試的操做。若是在重試的狀況下有足夠高的成功率，那重試就是合理的選擇。重試雖然能夠改正間接性的錯誤，可是它對那些違反業務規則，違反數據模型的數據無能爲力。
在最理想的狀況下，若是重試操做是冪等性的，什麼叫冪等性能（本身去百度吧）？事情就會簡單不少，重試操做能夠放心大膽的去實施。可是在重試操做通過一段時間或者必定次數以後還未成功的話，多數狀況下可能須要有必定的後續策略，好比：重試10次以後若是仍是失敗，則放棄。
這個策略是分佈式事務中常常用到的，與其說是補償，不如說是回滾操做。特別是在程序接收到數據會有一系列的操做的情景下，補償操做相似於事務回滾的概念，讓系統回到發生這一系列操做以前的狀態。這種補償的機制很是適合於那種有「事務」需求的場景。
你的業務中有哪些「事務」的需求場景呢？歡迎在留言中體現，另外再稍微提一下，每週送架構書籍的活動仍然在進行哦，歡迎關注
那我核酸檢測的結果，會不會直接採用忽略的策略呀，讓人擔憂
不用擔憂，這應該是一個事務性的操做，檢測結果確定會通知你的，由於你掏錢了....
本文分享自微信公衆號 - dotNET跨平臺（opendotnet）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。