一周领了三次罚单,这是什么破消息队列?
罚单
上周四,正在努力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也只是很小很小的概率会丢失数据。
交警局的违章记录应该是有人工审核,所以这事儿,多半还是人的问题,所以···
迟到的三联
然鹅,三连只会迟到,不会缺席。就在周末出门办事儿,停在路边一盏茶的功夫,交警叔叔给我送来了第三张罚单:
图片我这不是被交警蜀黍盯上了吧?此刻,我已经不敢回头看媳妇脸上的表情了
图片不过我还是抱了一点点的侥幸心理:这只是违停通知,说不定不会给我报上去,毕竟之前也遇到过贴了罚单但最后没处理的情况呢!
不知道怎么回事,这一次的消息队列特别给力,没多久,啪的一下,短信又来了,很快啊!
我对这神秘的消息推送机制彻底迷茫了,一会儿快,一会儿慢,一会儿甚至卡几天!
这个月还未过半,交罚款就好几百出去了,兜里的零花钱不知道还能不能撑到月底了···
关于罚单消息延迟推送,这事儿你怎么看?你们有遇到这样的情况吗?
交警叔叔都给我三连了,你们就别吝惜三连了啊~