非同步處理模型
一旦談到分散式，微服務等這些具有很高逼格的代名詞，總能讓你在面試中脫穎而出，不是因為這些詞的英文翻譯的好，而是現代網際網路乃至企業級開發確實在分散式，微服務等模式下取得了良好的架構效果。無論是微服務，還是之前的SOA，總是離不開非同步處理模型，小到程式中IO的處理，大到系統間的訊息互動，處處都有非同步的身影。
談到系統之間的訊息非同步處理，就不能不談訊息佇列（MQ），目前業界比較流行的MQ型別請自行百度腦補。但是需要提醒一下，MQ只是實現資料非同步處理的一種解決方案，沒有MQ能不能實現非同步處理呢？當然能，最簡單粗暴的莫過於採用資料庫方式，訊息生產者直接把資料插入資料庫，消費者採用讀取資料庫的方式來獲取資料，所以MQ並不等於非同步處理哦。
非同步訊息處理最大程度上解耦了各個系統，為每個系統獨立擴充套件提供了更大空間，但是非同步訊息處理也同時面臨著一些挑戰，比如：訊息管道效能，訊息管道的高可用等，其中最貼近業務層的可能非“資料異常處理”莫屬，基本上可認為這是資料處理模型的最末端，資料流向的尾部，但往往卻是業務中比較重要的部分。
如果一條非同步訊息作為一個分散式事務中的一環，那還設計到訊息處理結果的反饋，分散式協調器會根據訊息結果的成功與否來決定的事務的結果。
單就非同步訊息消費端來講，根據不同的業務場景就有以下幾種異常處理方案
直接忽略
這是所有異常資料處理方案中最粗暴，同時也是最簡單的一種：發生異常的時候，直接忽略，什麼都不做。
面對異常不採取任何措施，乍一聽這可能是個很糟糕的方案，但是在實際業務中，這可能是完全可以接受的。如果因為錯誤導致的損失很小，甚至可以忽略，但是建立一套錯誤糾正機制的成本遠遠高於忽略異常，這種場景下選擇直接忽略往往是一種更優的方案。而且當錯誤糾正機制設計到需要人工介入操作的時候，代價會更高，而且還會引入影響其他業務的可能，更為可怕的是如果錯誤糾正機制本身出現問題，那代價更是.....
舉個很簡單的栗子：像一些登入日誌的統計操作，如果處理某個人登入的資料出現異常，往往會選擇直接忽略。因為統計這種業務本身就帶有資料的容錯機制，100000和100001在統計需求看來沒有什麼區別。
重試
當直接忽略的方案不可行的時候，你可能需要重試的操作。如果在重試的情況下有足夠高的成功率，那重試就是合理的選擇。重試雖然可以改正間接性的錯誤，但是它對那些違反業務規則，違反資料模型的資料無能為力。
在最理想的情況下，如果重試操作是冪等性的，什麼叫冪等效能（自己去百度吧）？事情就會簡單很多，重試操作可以放心大膽的去實施。但是在重試操作經過一段時間或者一定次數之後還未成功的話，多數情況下可能需要有一定的後續策略，比如：重試10次之後如果還是失敗，則放棄。
補償
這個策略是分散式事務中經常用到的，與其說是補償，不如說是回滾操作。特別是在程式接收到資料會有一系列的操作的情景下，補償操作類似於事務回滾的概念，讓系統回到發生這一系列操作之前的狀態。這種補償的機制非常適合於那種有“事務”需求的場景。
你的業務中有哪些“事務”的需求場景呢？歡迎在留言中體現，另外再稍微提一下，每週送架構書籍的活動仍然在進行哦，歡迎關注
