哈嘍！大家好，我是小奇，一位不靠譜的程序員
小奇打算以輕鬆幽默的對話方式來分享一些技術，如果你覺得通過小奇的文章學到了東西，那就給小奇一個贊吧
文章持續更新

一、前言

RabbitMQ有很多高級特性，一般項目用不到，但是總有面試官會問到，被問到的時候我們要假裝這些對我們來説就是小意思一樣。

二、面試

面試官：小奇是吧，你先做一個自我介紹吧

我：面試官您好，我畢業於XXX，我之前在XXX工作，我精通XXX，總之一句話，我就是優秀，你問就完了。

面試官：行，你的自我介紹很強硬啊，那我看看你到底有沒有過硬的實力

我：是騾子是馬拉出來溜溜

三、RabbitMQ怎麼實現消費端限流

面試官：好，那我先問你一個場景題，比如我們公司現在做了一個秒殺系統，在活動當天用户下單太多了，造成消費端崩潰了，這種情況我們該怎麼處理呢

我：好説呀，多買幾台服務器，多搭建幾台消費端的服務，減緩服務端的壓力，這樣不就沒有問題了嗎。

面試官：額。。。你這麼説確實可以解決，實不相瞞我們老闆特別摳。。。不捨得買更多的服務器，就想讓我們一台服務器搞定

我：？？？光讓馬兒跑，不讓馬兒吃草，那特麼能行啊，跟你們老闆説，讓他自己出來頂着消費端的壓力吧，他不是不捨得花錢嗎，等秒殺的時候讓他去用户那裏搗亂，讓用户不能夠同一時間下單不就行了。

面試官：哎呀不行呀，我們也想過給用户搗亂，但是老闆不讓，老闆説必須讓用户在最短的時間內都完成下單

我：可以啊，那就使用MQ，讓客户端下單後將下單信息放入消息隊列中，然後讓消費端去處理唄。

面試官：哎呀我們就是這麼弄的，但是消費端總是崩潰

我：你們消費端服務器配置怎麼樣？

面試官：嗯。。消費端服務器配置是半核CPU、1G運行內存空間、10G磁盤空間

我： 半核？ 你特麼在逗我，另外半個CPU讓別人掰走了？

面試官：嘿嘿，情況就是這麼個情況，事情就是這麼個事情，反正公司就是窮困潦倒，等你進來了我再慢慢跟你講，你現在先幫我想一個解決方案，我用來應付一下老闆

我：那就在消費端實現限流吧。

面試官：怎麼實現呢？

我：使用channel.basicQos(int prefetchSize, int prefetchCount, boolean global)方法來設置限流的配置。

prefetchSize：表示消息的大小（0的話表示不限制大小）
prefetchCount：表示消息的數量
global：true表示該通道下的所有消費者都適用這個策略，而false表示只有當前這一個消費者適用這個策略。

如圖，這裏我們channel.basicQos(0,1,false)；表示不限制消息的大小，但是限制消息的數量，一次只能給消費者發送一條消息。

面試官：為什麼不限流的話會將消費端搞掛掉呢

我：假如現在小明的媽媽有10個餃子給小明吃，小明叫來了9個同學，然後他們一共10個人，一人一個餃子都是一口就吃完了沒有任何問題，但是今天就小明一個人，總不能10個餃子一下塞到小明的嘴裏面吧，這樣直接將小明噎死了。

面試官：那怎麼解決呢

我：現在小明先吃一個餃子，等小明吃完了這一個餃子後告訴他媽，説我吃完了，然後他媽再給他一個餃子吃，這樣的話也是可以吃完10個餃子的，並且小明沒有事。

面試官：我看限流的參數還有數據大小是幹什麼的

我：假如現在小明媽媽為了讓小明一口就吃完十個餃子，他包了一個特別大的餃子，有一斤重，這個時候跟小明説還是一個餃子，一口悶吧，這個時候照樣將小明噎死了，所以數據大小也是要限制的。

面試官：那隊列怎麼知道消費者消費完了一條消息，要給他再發送一條消息呢

我們要配置消費端手動確認，當我們消費端消費完消息後手動確認消息，這個時候隊列就認為整個消費流程走完了，就開始下一個信息的發送了。

開啓手動確認配置

代碼中手動確認。

這裏手動確認有兩個參數，第一個是tag編號，就是這個消息的一個編號，第二個參數為是否確認多條，true的話就是確認多條消息，false的話就是隻確認這一條消息，一般我們都是false。

面試官：可以呀小夥子，有點東西

我：請你不要迷戀哥，哥只是一個傳説。。。

面試官：小夥子真厲害啊，一下子就把RabbitMQ消費端限流講明白了，你面試通過了，明天上崗吧

我：啊，這麼急嗎，我後面還有好多東西沒有講呢。

面試官：不着急，進來了以後慢慢聽你講，加班讓你跟我講

我：啊。。。這也太難了吧

四、總結

這裏關於RabbitMQ還沒有整理完畢，文章後面持續更新，建議收藏。

文章中涉及到的命令大家一定要像我一樣每個都敲幾遍，只有在敲的過程中才能發現自己對命令是否真正的掌握了。

如果覺得我的文章還不錯的話就點個贊吧

本文參與了 SegmentFault 思否徵文「如何“反殺”面試官？」，歡迎正在閲讀的你也加入。