我最近参与讨论了很多有关应用程序如何处理高负载的能力，这个为的核心在于如何在,如何在不浪费大量的特定资源的情况下保持程序的稳定性，而这些特定的资源只会流量峰值的时候起作用。
很多应用服务，这样的典型case 十分差常见，例如：
博客应用程序可能会在每次发文后出现峰值。再比如，博客应用程序可能会在每次发布的帖子上出现峰值。
像Groupon或One Kings Lane这样的日交易比较活跃的网站，每当发布一个新产品时，都会经历巨大的流量高峰。
而One Kings Lane 的优势在于他们确切的知道流量峰值的出现时间：每天早上8点。让我们使用日常交易网站作为例子，因为它是一个众所周知的问题。
解决方案1:更多资源
解决这个问题的一个方法是总是有过剩的容量等待峰值。如果您能够估计出在任何给定的一天中您同时拥有的最大流量，那么就可以保持足够的服务器运行来处理最大负载。有了这个解决方案，总是可以利用超出本日最大值的额外容量来预防即将今天的峰值来临。
解决方案2:峰值时禁用某些特性（俗称降级）
当流量峰值出现的时候，超过了你应用程序的负载能力，可以选择禁用某些特性或者使用应用程序的“轻量级”备份版本，Groupon 和 Google 都推荐这么做。这之所以有效，是因为他以牺牲了应用的部分功能的代价，来降低应用的负载，所以这并不是最佳的选择
解决方案3:自动伸缩（俗称扩容）
当流量激增时，可以通过快速自动地启动新的服务器来处理他们。看起来很棒了，但实施起来确实困难重重。首先，设置自动缩放系统需要花费大量的精力。其次，它必须能够非常迅速地利用这些额外的资源，如果太慢，你的系统可能已经崩溃了。再次，自动扩展程序决定是时候销毁那些额外的实例之前，还有可能出现资源利用不充分的问题。如果你的峰值出现在随机时间，你最终会一直向上和向下伸缩。
解决方案4:使用消息队列
消息队列作用之一就是流量削峰。当负载教轻的时，队列总是空的。当负载峰值，队列开始被逐步填满，而我们的应用程序可以稳步的按照自己的处理速度来逐步处理这些消息，当让如果队列持续增长，我们也可以通过启动更多的服务器也就是消费方来消耗队列。
这不仅避免了不必要的费资也不必禁用站点/应用程序的任何功能。
至于消息队列还能解决什么问题，可以参考我另一篇博文MQ可以解决哪些实际问题?
原文地址
赞赏一下
