请求量过大，这谁顶得住啊！

这谁顶得住啊！

自从上次项目拆分的优化后，用户的体验好了很多，流量自然是有所增长。对公司对这个项目来说，有增长是好事。但服务器却有些顶不住了。

好在，上次有一名叫小李的程序员，在休息时间摸鱼时了解到了一个新的名词集群。听说使用集群能解决单台服务器资源不足的问题，在把原来单台服务器的项目，同时部署在另外一台服务器上。

小李简单的看了看集群，发现能解决当前服务器顶不住的问题。马上就跑去老板说：“老板!我发现了能解决我们我们项目经常会出现访问繁忙的问题。就是花钱买新的服务器！”。老板一听，发现竟然要花钱，便马上说到：“要花钱？花多少钱，买多少钱台？” “不多不多，只需要再买一台同样配置的服务器就可以了。”。老板听后便呼了一口气，再买一台同样的配置的服务器毕竟也不会贵，一个个月的续费，要是后面要是用不到还可以退了。

新的服务器

老板，通知财务给云服务账号充钱并新买了一台服务器，之后便通知了小李。让小李去完成后续的工作。

小李把这个消息告诉了大家，并让大家把项目打一个稳定版本的包，发给小李。小李需要部署在新的服务器上，很快小李便部署好了。可新的问题是，项目已经在新的服务器部署好了。但，这台服务器上并没有任何的请求量啊。小李被这个问题给难住了，他觉得貌似还缺少了些什么？一拍脑袋发现，是啊！那篇文章我还没有看完。便继续往下翻了翻，发现需要安装一个Nginx，并且需要在Nginx的配置文件里面配置负载均衡，在实现负载均衡的同时还可以做高可用。

小李看到了负载均衡以及高可用后，皱了皱眉说到什么是负载均衡和高可用?便继续往下看了看。

Nginx的负载均衡

关于文章中，负载均衡是这么解释的：负载均衡是高可用网络基础架构的关键组件，通常用于将工作负载分布多台服务器上，来提高网站、应用、数据库或者其他服务的性能和可靠性。，高可用：在实现负载均衡后，Nginx会将流量分别分发到两台不同的服务器中，当一台服务器出现宕机后，新的流量都会分发到剩下的服务器。来保证服务的质量。

小李一看便明白了，原来这就是负载均衡和高可用啊！就像谈恋爱一样，谈一个对象随时可能会分手，一点也不稳定不可靠，想要可靠点就要做负载均衡和高可用。当现任出现情绪不满时，马上去联络备胎维持下感情。

但，还需要再买一台服务器专门用来做负载均衡和高可用才行。小李小心翼翼的跑去跟老板说明情况，老板却意味深长的看了看小李一眼，说到：“再买新的服务器，没问题但一定要尽快解决。要是解决不了，就给我一天想一百个方案出来。”。小李点了点头，便一溜烟的跑了———去配置Nginx。

Nginx负载均衡配置

Nginx的负载均衡算法一共有五种，分别如下：

• 轮询（默认）——每个请求按时间顺序逐一分配到不同的服务器中，如果其中有一台服务器宕机，会自动剔除。
• 指定权重——通过weight指定轮询几率，weight和访问比率成正比，weight数值越大权重越高。对于某些性能不够强劲的机器可以把权重调低。
• ip_hash——对ip进行hash计算，可以用于把不同的ip分配到上次访问的服务器中，比如上次访问的是A，下次再次访问还是A而不会去B服务器。
• fair（第三方）——按服务器响应时间来分配请求，响应时间短的优先分配。
• url_hash（第三方）——对访问的url进行hash计算，按照计算结果来指定服务器。

为了足够真实，我花了巨资买了两块树莓派 3b+来当作部署项目的服务器，笔记本当作Nginx的服务器。

至于Nginx怎么安装，这里便不去详细的说明了，可自行看官网文档

编写负载均衡的配置

配置文件可以写在nginx目录的conf.d下，这里我只采用轮询方式的负载均衡算法：

之后需要在nginx.conf中添加一行include conf.d/*.conf;即可（默认会有这么一行，Windows除外）：

添加完后只需要重启一下Nginx。

测试对比

为了测试负载均衡是否能提升性能，就需要进行压测，这里工具我所使用的是wrk。

测试参数如下：

• Threads:100
• Connections:100
• Duration:1m
• Url:http://api.codedream.xin/hello

wrk -t100 -c100 -d1m http://api.codedream.xin
/hello

单台服务器压测

首先进行单台服务器测试（old-server），结果如下：

Running 1m test @ http://api.codedream.xin/hello
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    92.24ms  103.84ms   1.28s    97.01%
    Req/Sec    13.09      4.73    30.00     67.77%
  76143 requests in 1.00m, 11.62MB read
Requests/sec:   1267.53
Transfer/sec:    197.99KB

压测结果:

• Latency（延迟）

  • Avg: 92.24ms
  • Max: 1.28s

• Req/Sec（处理中的请求数）

  • Avg: 13.09
  • Max: 30.00
• Requests In 1m: 76143
• Timeout: 0
• QPS: 1267.53

服务器信息：

可以看到，这是单台服务器的压测结果，跑了一个Hello的接口，但在多次压测中出现了宕机的情况！

双台服务器压测

接下来测试两台机器的性能，测试结果如下：

Running 1m test @ http://api.codedream.xin:8080/hello
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   118.84ms  216.87ms   1.28s    89.58%
    Req/Sec    22.97      6.74    60.00     53.68%
  116910 requests in 1.00m, 17.83MB read
  Socket errors: connect 0, read 0, write 0, timeout 3
Requests/sec:   1946.19
Transfer/sec:    304.00KB

压测结果:

• Latency（延迟）

  • Avg: 118.84ms
  • Max: 1.28s

• Req/Sec（处理中的请求数）

  • Avg: 22.97
  • Max: 60.00
• Requests In 1m: 116910
• Timeout: 3
• QPS: 1946.19

服务器信息

可以看到，服务器集群的CPU使用情况远比单台服务器要低的多，而且在测试中性能也有一些提高。

由于受限于我的笔记本，无法完全发挥出集群的性能。

后续

虽然小李使用集群解决了请求量过大的问题，而且就算其中一台服务器宕机了也没关系，还有别的服务器能继续处理剩余的请求。老板之后也表扬了小李，并表示要给小李在四月份加薪250块，五月份生效，六月份才发到工资里面。小李对这次加薪并不是很在意，他更在意的是技术，或许他在准备着什么。

集群虽好，但小李这观察集群的这段时间，发现在某些场景下会出现一些奇奇怪怪的问题，也许这就是文章后面所说的集群中存在一些分布式的问题吧...

blog:https://www.codedream.xin

上期文章:从一开始的小项目逐渐变成了大项目而得臃肿，怎么办？