服务排队与集群雪崩的解决思路

看别人的文章有这方面的描述，记录下两个比较有启发的思路，仅做记录

服务排队

在服务请求量远远大于服务可供应量时，需要对请求进行排队。
排队是有比较成熟的方案的，通常来说可以考虑在服务器和浏览器两侧进行配合。核心思路如下：

（1）能够在客户端（浏览器）挡住的访问坚决不要放到服务器上来。例如，可以使用JavaScript代码进行“封堵”，至少做一个比较好的倒计时提示来告诉访问着前面还有多少人，或者要倒计时等多久才能排队等到位
（2）能够分散到多个服务器上进行排队提示的内容坚决不要集中到一台服务器上来。这个原则和负载均衡的原则是没有区别的，我们不希望大家都一窝蜂到窗口来问“还差多少人到我”。能够用大广告牌说明的问题就写到大广告牌上，大家自己看。所以在服务器上也可以考虑用类似的方式进行分散性的广播，而不要集中到一台服务器做排队询问。

集群雪崩

在系统架构中提到的雪崩，就是由于一台服务器或者一台服务器中的某个模块发生故障进而引起连锁反应，最后导致大量的服务器或者软件模块无法正常工作，这种现象也较做“急剧变化”现象。例如，常用的负载均衡的集群里就会有类似的现象发生。想要防止雪崩需要做好以下几件事情：

（1）对服务器负载的估算。对服务器的负载应该有一个比较合理的估算。来自前端的HTTP请求或者其他形式的压力都可以通过软件来模拟进行压力测试，测试一台服务器在cpu达到60%左右时的负载数量。
（2）线上测试估算服务器数量。如果计算出峰值时需要2台服务器，每台服务器60% 的负载买时这时候服务器集群是没有真正“冗余”的，因为一旦其中的一台服务器由于故障停止响应立刻会引发雪崩，所以这时应该是在刚刚的基础上加一台服务器更为保险，即一共3台服务器，每台服务器40%的CPU负载。如果计算出需要4台服务器，每台服务器60%的负载，如果一台服务器发生故障，其余3台服务器的CPU负载会被压力推升到80%，但是应该远没有第一种情况危险。