你知道的越多，你不知道的越多

點贊再看，養成習慣

GitHub上已經開源 https://github.com/JavaFamily 有一線大廠面試點腦圖、個人聯絡方式和人才交流群，歡迎Star和完善

前言

訊息佇列在網際網路技術儲存方面使用如此廣泛，幾乎所有的後端技術面試官都要在訊息佇列的使用和原理方面對小夥伴們進行360°的刁難。

作為一個在網際網路公司面一次拿一次Offer的麵霸，打敗了無數競爭對手，每次都只能看到無數落寞的身影失望的離開，略感愧疚（請允許我使用一下誇張的修辭手法）。

於是在一個寂寞難耐的夜晚，暖男我痛定思痛，決定開始寫《吊打面試官》系列，希望能幫助各位讀者以後面試勢如破竹，對面試官進行360°的反擊，吊打問你的面試官，讓一同面試的同僚瞠目結舌，瘋狂收割大廠Offer！

撈一下

上一期，簡單的介紹了一下訊息佇列的基礎知識，裡面有訊息佇列的應用場景，以及使用之後可能帶來的問題，但是上期沒對怎麼解決這些問題做回答，因為要控制篇幅嘛（明明是自己覺得MQ寫不了多少期，要多懟一期出來！渣男）

咳咳，我們言歸正傳，沒看的朋友去看一下，有助於這期的閱讀：

《吊打面試官》系列-訊息佇列基礎

面試開始

一個風度翩翩，穿著格子襯衣的中年男子，拿著一個滿是劃痕的mac向你走來，看著錚亮的頭，心想著肯定是尼瑪頂級架構師吧！但是我們看過暖男敖丙的系列，腹有詩書氣自華，虛都不虛。

沒錯小夥子還是我，上次話說一半你就溜了，這次我非得好好的問問你。

好的面試官，因為上次著急，敖丙的系列更新了所以趕回家去看了！

我信你個鬼，我們開始吧，上次說到了訊息佇列的訊息重複消費，你能跟我介紹這是怎麼樣子的場景麼？

訊息重複消費是使用訊息佇列之後，必須考慮的一個問題，也是比較嚴重和常見的問題，帥丙我在開發過程中，但凡用到了訊息佇列，我第一時間考慮的就是重複消費的問題。

就比如有這樣的一個場景，使用者下單成功後我需要去一個活動頁面給他加GMV（銷售總額），最後根據他的GMV去給他發獎勵，這是電商活動很常見的玩法。

類似累計下單金額到哪個梯度給你返回什麼梯度的獎勵這樣。

我只能告訴你這樣的活動頁面10000%是用非同步去加的（別問我為什麼，因為這個活動的後端是敖丙我做的