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