程序員過關斬將–分佈式系統消息異常該何去何從

異步處理模型

一旦談到分佈式,微服務等這些具有很高逼格的代名詞,總能讓你在面試中脫穎而出,不是因為這些詞的英文翻譯的好,而是現代互聯網乃至企業級開發確實在分佈式,微服務等模式下取得了良好的架構效果。無論是微服務,還是之前的SOA,總是離不開異步處理模型,小到程序中IO的處理,大到系統間的消息交互,處處都有異步的身影。

談到系統之間的消息異步處理,就不能不談消息隊列(MQ),目前業界比較流行的MQ類型請自行百度腦補。但是需要提醒一下,MQ只是實現數據異步處理的一種解決方案,沒有MQ能不能實現異步處理呢?當然能,最簡單粗暴的莫過於採用數據庫方式,消息生產者直接把數據插入數據庫,消費者採用讀取數據庫的方式來獲取數據,所以MQ並不等於異步處理哦。

異步消息處理最大程度上解耦了各個系統,為每個系統獨立擴展提供了更大空間,但是異步消息處理也同時面臨着一些挑戰,比如:消息管道性能,消息管道的高可用等,其中最貼近業務層的可能非“數據異常處理”莫屬,基本上可認為這是數據處理模型的最末端,數據流向的尾部,但往往卻是業務中比較重要的部分。

如果一條異步消息作為一個分佈式事務中的一環,那還設計到消息處理結果的反饋,分佈式協調器會根據消息結果的成功與否來決定的事務的結果。

單就異步消息消費端來講,根據不同的業務場景就有以下幾種異常處理方案

直接忽略

這是所有異常數據處理方案中最粗暴,同時也是最簡單的一種:發生異常的時候,直接忽略,什麼都不做。

面對異常不採取任何措施,乍一聽這可能是個很糟糕的方案,但是在實際業務中,這可能是完全可以接受的。如果因為錯誤導致的損失很小,甚至可以忽略,但是建立一套錯誤糾正機制的成本遠遠高於忽略異常,這種場景下選擇直接忽略往往是一種更優的方案。而且當錯誤糾正機制設計到需要人工介入操作的時候,代價會更高,而且還會引入影響其他業務的可能,更為可怕的是如果錯誤糾正機制本身出現問題,那代價更是…..

舉個很簡單的栗子:像一些登錄日誌的統計操作,如果處理某個人登錄的數據出現異常,往往會選擇直接忽略。因為統計這種業務本身就帶有數據的容錯機制,100000和100001在統計需求看來沒有什麼區別。

重試

當直接忽略的方案不可行的時候,你可能需要重試的操作。如果在重試的情況下有足夠高的成功率,那重試就是合理的選擇。重試雖然可以改正間接性的錯誤,但是它對那些違反業務規則,違反數據模型的數據無能為力。

在最理想的情況下,如果重試操作是冪等性的,什麼叫冪等性能(自己去百度吧)?事情就會簡單很多,重試操作可以放心大膽的去實施。但是在重試操作經過一段時間或者一定次數之後還未成功的話,多數情況下可能需要有一定的後續策略,比如:重試10次之後如果還是失敗,則放棄。

補償

這個策略是分佈式事務中經常用到的,與其說是補償,不如說是回滾操作。特別是在程序接收到數據會有一系列的操作的情景下,補償操作類似於事務回滾的概念,讓系統回到發生這一系列操作之前的狀態。這種補償的機制非常適合於那種有“事務”需求的場景。

你的業務中有哪些“事務”的需求場景呢?歡迎在留言中體現,另外再稍微提一下,每周送架構書籍的活動仍然在進行哦,歡迎關注

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

您可能也會喜歡…