[[357933]]

 罰單

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

違章停車被罰了!!!

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

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

約莫一分鐘后，我突然意識到：我今天(星期四)早上，又停在這里買了一次早飯!!!

我要裂開了!

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

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

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

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

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

但隨后我開始琢磨起一個問題來：為什么前天和今天的違停消息，今天一次性給我推送過來了? 要是前天的違章信息也能當天就發(fā)送，我也不至于連續(xù)違停兩次啊。

這是用的什么破消息隊列在推送???

假如這交警隊的系統(tǒng)用到了消息隊列，那到底用的什么消息隊列呢?

消息隊列

首先什么是消息隊列?

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

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

上面描述的場景是單機上的情況，如何實現(xiàn)跨越多臺服務器的生產者-消費者模型呢?

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

使用消息隊列有三大優(yōu)勢：

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

解耦：生產者只管將消息寫入，至于誰來讀取消費，什么時候消費不必關心，以此實現(xiàn)將生產者與消費者徹底解耦。

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

常見的四大消息隊列：

Kafka：使用Scale和Java開發(fā)，單機吞吐量達到10W級，時效性達到ms級，支持分布式部署，消息穩(wěn)定性高!常用于日志處理分析場景。

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

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

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

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

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

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

遲到的三聯(lián)

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

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

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

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

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

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

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

本文轉載自微信公眾號「編程技術宇宙」，可以通過以下二維碼關注。轉載本文請聯(lián)系編程技術宇宙公眾號。