常见的简单的设计云平台淄博seo公司

1、内存队列满了应该怎么办

如图：

大家可以看到，虽然现在发短信和广告投递，彼此之间的执行效率不受彼此影响，但是请大家注意，投放广告之后还要把请求放到内存队列里面去，而内存空间是很有限的，比方说有一个很热情的厨师，他强行的把自己做好的菜，往客人嘴里塞，然而作为一个普通人你的肠胃对食物的消化速度远远比不了人家做菜的速度，就这样，你肠胃里的食物，还没消化完，厨师还是不停的往你嘴里送。

不用多说这样下去你的肠胃一定会有问题，那么同理发短信的速度，远远比不上商户们投放广告速度，内存就像人的肠胃样，是会被撑爆的，那么如果现在我们没办法改变我们肠胃的消化能力，又不想被热情的厨师做的菜撑爆，那我们最好先客人跟厨师说明，它的饭量大概是多少，当厨师发现你快吃不下的时候人家厨师或许就放慢做菜速度，乃至停止继续做菜了。

内存队列也是一样，我们可以通过对发送短信系统的压测，评估出一个对数据处理的执行效率，从而制定内存队列的大小，投放广高系统，刚知道队列快满的时候可以选择，延缓将数据放入队列的速度甚至极端情况，就可以将数据丢弃，因为本来发短信也不是什么太重要的事情。

2、问题要治本——发短信导致吞吐量降低的问题不能忽略！！

内存被撑爆的问题，算是解决了，但是不是有一种治标不治本呢？因为最根本的问题是还是发送短信的环节导致的？我们所谓的调整内存队列大小，换句话说就是因为发送短信的效率低下最终还是影响了系统的吞吐量，是不是很不爽呢？那么你可能会问了，创建多个线程，多部署几台与短信运营商交互的机器不就行了吗？如图

是的，没错，这样三个线程消费队列中的请求的的确确是加强了消费速度，但是还是有令人不舒服的地方：

线程是宝贵的系统资源，确实不想为发短信这样的事情开辟更多资源

单个线程的利用率还是很低，只要进行了短信发送就意味着这个线程将被长时间阻塞，还是没能解决消费过慢的根本原因

以一个购物狂的生活状态为背景，思考如何解决队列数据消费过慢的问题

假如有怎么一个购物狂，人生最大的快乐就是网购，拆包裹，由于对购物的热情已达到一种病态的程度，以至于当他买了一将商品之后，就日日夜夜的在快递存放点蹲守等着收自己的快递，直到拿到了才罢休。

我们把这种取快递的方式如果比作是IO操作的一种方式，那就是阻塞IO了，也就是说我只要调用了read方法我必须读取到所要的信息才行，否则我就一直在这里阻塞着。这也是发短信系统中的线程所采取的IO读写方式。

过了几天，购物狂也明白了，毕竟他还要买买买啊，老在这花大把的时间干等，也不是一个事儿，所以他现在稍微理性了些，不管在快递存放点取没取到包裹，就会回去了，但是别忘了拆包裹对他来说也是很重要的一部分。

所以他来往快递存放点的频率非常高，快递还没有送达，他就来快递存放点好几个来回，这也就表示他空手而归成了将常便饭，你想每天都要去一个地方好几回，而且也都是做的无用功，但这个过程对购物狂的时间消耗是实实在在的。

像上面这种情况就可以被看做是非阻塞IO的处理方式，当你发起IO请求的时候&#x