首先，你們系統裡面為什麼要用mq
不少去面試的人，都知道自己以前專案裡面用過mq、redis，但是為什麼用這個，卻不知道，這種人說白了就是為了用而用，又或者這個框架就是別人設計的，他自己都沒了解過裡面的東西，自然也不知道為什麼要用。如果面試的時候面試官問你這種問題你答不上來，可能已經被pass百分之三十了，面試官通常對這種人印象很不好，他怕你進了公司只會埋頭苦幹，不懂得自己思考。
第二，你既然用了mq，那你知不知道mq有什麼好處和壞處
如果沒考慮過這個問題一定要慎重回答，因為你沒考慮過這個，盲目的弄個mq進系統，當下的問題可能是解決了，但萬一後面出了問題不是給公司留坑嗎，面試官就怕這樣的人，招進來幹了一年，自己跳槽了，給系統挖一堆坑，留下無窮禍患。
第三，既然你用了mq，比如其中一種mq，那你當時做沒做過調研
別看別人用了mq，咦，感覺挺好的，就自己瞎弄了乙個，根本沒考慮過mq的選型，比如kafka，每個mq並沒有絕對的好處和壞處，現在業界流行的mq各有各的好處，各有各的壞處，你要做的就是揚長避短，挑選最適合自己系統的mq。
①為什麼要使用mq
其實面試官問你這個問題就是想知道，你們公司有個什麼樣的業務場景，這個業務場景有個什麼技術挑戰，如果不用mq可能會比較麻煩，包括現在用了mq以後有哪些好處等等。先說一下mq常見的使用場景吧，mq的使用場景有很多，但是比較核心的就是：解耦、非同步、削鋒。
系統解耦
首先舉例下面這個場景，現有abcde五個系統，最初的時候bcd三個系統都要呼叫a系統的介面獲取資料，一切都很正常，但是突然，d系統說：我不要了，你不用給我傳資料了，a系統無奈，只能修改**，將呼叫d系統的**刪除，這時候還沒刪除呢，e系統傳送了請求，但是a系統這時候還沒處理完d系統的請求，a系統卒！！！徹底崩潰。看下圖↓↓↓↓↓↓↓↓↓↓↓
上述場景中，bcde都需要用到a系統提供的資料，a系統跟其他四個系統嚴重耦合，需要時時刻刻考慮其他四個系統要是掛了怎麼辦，需不需要重新傳送資料給他們，這個時候的a系統內心是崩潰的。
但是如果使用了mq之後 ，a系統的資料只需要放到mq裡面，其他的系統想請求獲取資料只需要去mq裡面消費即可，如果突然不想請求了，就取消對mq的消費就行了，a系統根本不需要考慮給誰去響應這個資料，也不需要去維護**，也不用考慮其他系統是否呼叫成功，失敗超時等情況。詳細看下圖↓↓↓↓↓↓↓↓
面試技巧：你需要思考一下，在你自己的系統裡面有沒有類似的情況，乙個系統或者模組，呼叫了多個系統或者模組，它們互相之間的呼叫非常複雜，並且維護起來很麻煩，但其實這個呼叫是不需要直接同步呼叫介面的，如果用mq給它非同步化解耦也是可以的，你就需要思考在你的專案裡，是不是可以用mq給它進行系統的解耦，可以自己組織一下語言回答。非同步呼叫
場景二，還是abcd四個系統，a系統收到乙個請求，需要在自己本地寫庫，還需要往bcd三個系統寫庫，a系統自己寫本地庫需要3ms，往其他系統寫庫相對較慢，b系統200ms ，c系統350ms，d系統400ms，這樣算起來，整個功能從請求到響應的時間為3ms+200ms+350ms+400ms=953ms，接近一秒，對於使用者來說，點個按鈕要等這麼長時間，基本是無法接受的，側面也反映出這家研發人員技術不咋地。詳情如下圖↓↓↓↓↓↓
一般的網際網路企業，對於使用者請求響應的時間要求在100ms-200ms之間，這樣，使用者的眼睛存在視覺暫停現象，使用者響應時間在此範圍內就可以了，所以上面的現象是不可取的。
如果用了mq，使用者傳送請求到a系統耗時3ms，a系統傳送三條訊息到mq，假如耗時5ms，使用者從傳送請求到相應3ms+5ms=8ms，僅用了8ms，使用者的體驗非常好。
流量削峰
如果使用了mq，每秒百萬個請求寫入mq，因為jd系統每秒能處理1w+的請求，jd系統處理完然後再去mq裡面，再拉取1w+的請求處理，每次不要超過自己能處理的最大請求量就ok，這樣下來，等到八點高峰期的時候，系統也不會掛掉，但是近乙個小時內，系統處理請求的速度是肯定趕不上使用者的併發請求的，所以都會積壓在mq中，甚至可能積壓千萬條，但是高峰期過後，每秒只會有一千多的併發請求進入mq，但是jd系統還是會以每秒1w+的速度處理請求，所以高峰期一過，jd系統會很快消化掉積壓在mq的請求，在使用者那邊可能也就是等的時間長一點，但是絕對不會讓系統掛掉。
優點上面已經說過了，系統解耦，非同步呼叫，流量削峰。
缺點①系統可用性降低：系統引入的外部依賴越多，系統要面對的風險越高，拿場景一來說，本來abcd四個系統配合的好好的，沒啥問題，但是你偏要弄個mq進來插一腳，雖然好處挺多，但是萬一mq掛掉了呢，那樣你系統不也就掛掉了。
②系統複雜程度提高：非要加個mq進來，如何保證沒有重複消費呢？如何處理訊息丟失的情況？怎麼保證訊息傳遞的順序？問題太多。
③一致性的問題：a系統處理完再傳遞給mq就直接返回成功了，使用者以為你這個請求成功了，但是，如果在bcd的系統裡，bc兩個系統寫庫成功，d系統寫庫失敗了怎麼辦，這樣就導致資料不一致了。
所以。訊息佇列其實是一套非常複雜的架構，你在享受mq帶來的好處的同時，也要做各種技術方案把mq帶來的一系列的問題解決掉，等一切都做好之後，系統的複雜程度硬生生提高了乙個等級。
四大主流mq（kafka、activemq、rabbitmq、rocketmq）各自的優缺點
目前業界四大主流的mq有kafka、activemq、rabbitmq、rocketmq。其他的mq也有，不過比較冷門。就不用多說了，畫個表就明白了。↓↓↓↓↓↓↓↓
一般的業務系統要引入mq，最早大家都用activemq，但是現在確實大家用的不多了，沒經過大規模吞吐量場景的驗證，社群也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；
後來大家開始用rabbitmq，但是確實erlang語言阻止了大量的j**a工程師去深入研究和掌控他，對公司而言，幾乎處於不可控的狀態，但是確實人是開源的，比較穩定的支援，活躍度也高；
不過現在確實越來越多的公司，會去用rocketmq，確實很不錯，但是我提醒一下自己想好社群萬一突然黃掉的風險，對自己公司技術實力有絕對自信的，我推薦用rocketmq，否則回去老老實實用rabbitmq吧，人是活躍開源社群，絕對不會黃
所以中小型公司，技術實力較為一般，技術挑戰不是特別高，用rabbitmq是不錯的選擇；大型公司，基礎架構研發實力較強，用rocketmq是很好的選擇
如果是大資料領域的實時計算、日誌採集等場景，用kafka是業內標準的，絕對沒問題，社群活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規範
ok，訊息佇列寫到這裡就結束了，記得點個在看！！！！！
我對訊息佇列的理解
用訊息佇列進行程序間的通訊，需要記住兩個結構，4個函式 第乙個結構 struct ipc perm 此結構主要用於用於 許可權。第二個結構 struct msgid ds 四個函式 int msgget key t key,int flag 建立乙個訊息佇列結構 int msgctl int msg...
詳細說說shape model的使用
基於形狀匹配shape model是工程上用的最多的，掌握它就有了一張王牌。針對roi小區域建模板，應用場合 模板的形狀和大小一經製作完畢便不再改變，在查詢模板的過程中，只會改變模板的方向和位置等來匹配目標影象中的影象。定位物件內部的灰度值可以有變化，但物件輪廓一定要清晰平滑。匹配速度比灰度快 建立...
windows佇列訊息和非佇列訊息的詳細解釋
我們已經談到過，windows給視窗傳送訊息，這意味著windows呼叫視窗訊息處理程式。但是，windows程式也有乙個訊息迴圈，它呼叫getmessage從訊息佇列中取出訊息，並且呼叫dispatchmessage將訊息傳送給視窗訊息處理程式。那麼，windows程式是依次等待訊息 類似於普通程...