違章停車被罰了！！！

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

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

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

我要裂開了！

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

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

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

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

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

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

這是用的什麼破訊息佇列在推送？？？

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

訊息佇列

首先什麼是訊息佇列？

訊息佇列，也就是MessageQueue，那它得先是個佇列。

佇列咱們不會陌生，一個遵循先進先出（FIFO）的資料容器，在程式設計開發中，經常會用到佇列。比如一個或多個執行緒產生任務訊息投遞到佇列中，另外一個或多個執行緒從佇列中取出訊息來處理，典型的生產者-消費者模型。

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

訊息佇列很好的解決了這個問題。

使用訊息佇列有三大優勢：

削峰：大量請求懟過來，資料庫往往難以招架，而如果將請求放入訊息佇列中，可起到緩衝削峰的作用。

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

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

常見的四大訊息佇列：

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

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

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

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

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

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

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

遲到的三聯

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

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

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

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

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

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

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

交警叔叔都給我三連了，你們就別吝惜三連了啊～