一週領了三次罰單，這是什麼破消息隊列？_風聞

罰單  

上週四，正在努力coding，家裏那位突然在微信上甩過來一張截圖：

違章停車被罰了！！！  

頓時慌得一逼，這個月的生活費又要扣錢了～

稍稍緩了緩，再詳細看了一下違停的拍照，想起來了：時間發生在前天（星期二）早晨，我就停在路邊去買了個早餐，全程不超過3分鐘！3分鐘=扣3分+罰款100元，這早餐吃的也太TM貴了。

約莫一分鐘後，我突然意識到：我今天（星期四）早上，又停在這裏買了一次早飯！！！

我要裂開了！

不過我還是抱着僥倖心理，説不定交警叔叔看在我連續停了兩次，看我不知道違章就把第二次給我免了呢？

然而事實狠狠的打了我的臉，幾個小時後，媳婦又給我發來了一張截圖：

當時心中一萬頭草泥馬奔騰而過，今晚下班，我是不是得把公司的鍵盤帶回家了···

幸好週三限號沒開成，要不然還不直接給我來個三連？？？

之前我也一直停在這裏買早飯，從來沒有被拍過，這攝像頭估計是最近才裝上去的，要怪只能怪自己吧，唉～

但隨後我開始琢磨起一個問題來：為什麼前天和今天的違停消息，今天一次性給我推送過來了？ 要是前天的違章信息也能當天就發送，我也不至於連續違停兩次啊。

這是用的什麼破消息隊列在推送？？？

假如這交警隊的系統用到了消息隊列，那到底用的什麼消息隊列呢？

消息隊列  

首先什麼是消息隊列？

消息隊列，也就是MessageQueue，那它得先是個隊列。

隊列咱們不會陌生，一個遵循先進先出（FIFO）的數據容器，在編程開發中，經常會用到隊列。比如一個或多個線程產生任務消息投遞到隊列中，另外一個或多個線程從隊列中取出消息來處理，典型的生產者-消費者模型。

上面描述的場景是單機上的情況，如何實現跨越多台服務器的生產者-消費者模型呢？

消息隊列很好的解決了這個問題。

使用消息隊列有三大優勢：

削峯：大量請求懟過來，數據庫往往難以招架，而如果將請求放入消息隊列中，可起到緩衝削峯的作用。

解耦：生產者只管將消息寫入，至於誰來讀取消費，什麼時候消費不必關心，以此實現將生產者與消費者徹底解耦。

異步：如果一個任務處理的時間太長，可將任務投遞到隊列中，不必阻塞等待處理鏈上後續處理，實現異步。

常見的四大消息隊列：

Kafka：使用Scale和Java開發，單機吞吐量達到10W級，時效性達到ms級，支持分佈式部署，消息穩定性高！常用於日誌處理分析場景。

RabbitMQ：使用冷門語言erlang開發，吞吐量達到萬級別，時效性達到微秒級，可以説是非常快了。

ActiveMQ：使用Java開發，吞吐量同樣是萬級別，時效性也是ms級，消息可靠度也要低一些。

RocektMQ：同樣使用Java開發，阿里巴巴出品，從名字可以看出，如火箭一般快，支持10W級吞吐量。

這幾個消息隊列都很快啊，沒有哪個達到了天級別的延時，所以這鍋消息隊列應該不能背。

真要是用了消息隊列，我多麼希望是一個特別容易丟消息的隊列，把我的違停消息丟掉吧。只可惜RocketMQ和Kafka理論上基本不會丟失，ActiveMQ和RabbitMQ也只是很小很小的概率會丟失數據。

交警局的違章記錄應該是有人工審核，所以這事兒，多半還是人的問題，所以···

遲到的三聯  

然鵝，三連只會遲到，不會缺席。就在週末出門辦事兒，停在路邊一盞茶的功夫，交警叔叔給我送來了第三張罰單：

我這不是被交警蜀黍盯上了吧？此刻，我已經不敢回頭看媳婦臉上的表情了

不過我還是抱了一點點的僥倖心理：這只是違停通知，説不定不會給我報上去，畢竟之前也遇到過貼了罰單但最後沒處理的情況呢！

不知道怎麼回事，這一次的消息隊列特別給力，沒多久，啪的一下，短信又來了，很快啊！

我對這神秘的消息推送機制徹底迷茫了，一會兒快，一會兒慢，一會兒甚至卡幾天！

這個月還未過半，交罰款就好幾百出去了，兜裏的零花錢不知道還能不能撐到月底了···

關於罰單消息延遲推送，這事兒你怎麼看？你們有遇到這樣的情況嗎？