nginx web工具/Redis + Twemproxy + HAProxy + Keepalived 测试 之 后台服务动态扩容（二）

现在来看一下上一篇文章的这个命令：

/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)

其中包含一个选项 -sf，其实还有另一个选项 -st。两个选项都是用来通知先前已经运行的进程：配置文件将被重新加载，同时进程会收到一个要求他们暂时停止监听 port 的 SIGTTOU 信号，以便新的进程可以接管他们。如果这中间出现了任何错误，新进程会给旧进程发送 SIGTTIN 信号，告诉他们继续监听端口并继续正常工作。
两个选项的区别在于，当这中间没有出现任何错误时：

• -sf
  要求旧进程完成他们的工作，然后平滑退出；
• -st
  直接终止进程，打断当前已存在的会话。

下面我们将通过测试来分析两者的区别。

一、-st

1、启动 HAProxy

查看进程信息：

2、运行 python 测试脚本

修改前一篇文章中的 python 测试脚本，将 sleep 时间由 1 秒改成 1 纳秒。

time.sleep(0.000001)

脚本输出结果：

3、查看 HAProxy 管理平台

可以看到，tw_proxy_1 当前存在一个会话：

4、使用 -st 选项热更配置文件

/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -st $(cat /var/run/haproxy.pid)

• 查看进程信息：
  
  可以看到，相比第 1 小节，HAProxy 进程 ID 已完全变更，且比之前多了一个进程：28456（热更配置启动的）。

• 观察第 2 节运行 python 测试脚本的控制台，可以看到脚本在持续输出正确结果。

• 反复刷新 HAProxy 管理平台，可以看到两个关于不同进程 ID 的统计报告：

  • 进程：28456（热更配置启动的），tw_proxy_1 当前存在一个会话；
  • 进程：28462（新启动的 HAProxy 进程），proxy_tw 当前没有回话。
    
    

5、再次使用 -st 选项热更配置文件

• 查看进程信息：
  
  可以看到，相比第 4 小节，HAProxy 进程 ID 又出现完全变更，且比之前多了一个进程：29865（28456 与 29865 都是热更配置启动的）。

• 观察第 2 节运行 python 测试脚本的控制台，可以看到脚本在持续输出正确结果。

• 反复刷新 HAProxy 管理平台，可以看到三个关于不同进程 ID 的统计报告：

  • 进程：28456（第一次热更配置启动的），tw_proxy_1 当前存在一个会话；
  • 进程：29865（第二次热更配置启动的），proxy_tw 当前没有回话；
  • 进程：29876（新启动的 HAProxy 进程），proxy_tw 当前没有回话。
    
    
    

6、第三次使用 -st 选项热更配置文件

执行结果与第 5 小节类似，只不过又多了一个 因热更配置启动的进程，同时反复刷新 HAProxy 管理平台，可以得到四个关于不同进程 ID 的统计报告。

7、终止第 2 小节运行的 python 脚本

可以看到，相比第 6 小节进程信息并未发生变化，同时反复刷新 HAProxy 管理可以得到四个关于不同进程 ID 的统计报告。

二、-sf

1、启动 HAProxy

查看进程信息：

2、运行 python 测试脚本

3、查看 HAProxy 管理平台

可以看到，进程：2567、tw_proxy_1 当前存在一个会话：

4、使用 -sf 选项热更配置文件

/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)

• 查看进程信息：
  
  可以看到，相比第 1 小节，HAProxy 进程 ID 未变更，但比之前多了一个进程：2969（热更配置启动的）。

• 观察第 2 节运行 python 测试脚本的控制台，可以看到脚本在持续输出正确结果。

• 反复刷新 HAProxy 管理平台，只能得到进程：2969 的统计报告，且当前会话数始终为 0：
  

5、再次使用 -st 选项热更配置文件

• 查看进程信息：
  
  可以看到，相比第 4 小节，HAProxy 进程 ID 仍未变更，且原先因热更启动的进程：2969 已经不见，但又新增了进程：3805（热更配置启动的）。

• 观察第 2 节运行 python 测试脚本的控制台，可以看到脚本在持续输出正确结果。

• 反复刷新 HAProxy 管理平台，只能得到进程：3805 的统计报告，且当前会话数始终为 0。

6、第三次使用 -st 选项热更配置文件

执行结果与第 5 小节类似，只不过又多了一个 因热更配置启动的进程，同时反复刷新 HAProxy 管理平台，只能得到进程：4578 的统计报告，且当前会话数始终为 0。

7、终止第 2 小节运行的 python 脚本

可以看到，相比第 6 小节 HAProxy 进程信息已变更，同时反复刷新 HAProxy 管理可以得到2个关于不同进程 ID（4578 与 4827） 的统计报告。

8、第四、五次使用 -st 选项热更配置文件

第四次热更后：

第五次热更后：

可以看到，每次热更后，HAProxy 进程信息会发生变更，且热更后会多了一个因热更配置启动的进程，同时反复刷新 HAProxy 管理平台，只能得到 4 个进程的统计报告。

9、再次运行 python 测试脚本

• 反复刷新 HAProxy 管理平台，除进程：6335 外，其他三个进程的当前会话数始终为 0：
  

10、第六次使用 -st 选项热更配置文件

热更后会多了一个因热更配置启动的进程：8486。

11、终止第 9 小节中运行的测试脚本

HAProxy 进程信息已变更：

三、systemctl reload haproxy

这种方式，功能上与 -sf 类似，都是让 HAProxy 进程平滑退出，区别在于：

• 新增进程：

  HAProxy 进程由三个进程组成：haproxy-systemd-wrapper、haproxy-master、haproxy：

  • -sf：每次热更，只会新增一个 haproxy 进程；
    
  • systemctl reload haproxy：每次热更，会同时新增 haproxy-master、haproxy 两个进程，haproxy-systemd-wrapper 始终不变。

• 热更：

  • -sf：不管 haproxy 进程（因热更产生的）上当前有没有会话，haproxy 进程都不会终止，只有当重启产生的 HAProxy 进程上没有会话时，HAProxy 进程才会终止；

  • systemctl reload haproxy：每次热更后，所有 haproxy-master 与 haproxy 进程对上当前没有会话，这两个进程就会被关闭。

• HAProxy 进程重启：

  • -sf：热更时，若 HAProxy 进程上没有会话时，三个进程立即重启，否则会等到 HAProxy 进程所有会话终止后，再重启。

  • systemctl reload haproxy：热更时，若 HAProxy 进程上没有会话时，则原先的 haproxy-master 与 haproxy 进程对直接退出，热更产生的进程对直接顶上，否则会等到 HAProxy 进程所有会话终止后，原来的 haproxy-master 与 haproxy 进程对再终止。

总结：

注意：以下所指的 HAProxy 进程指的是非因热更而新增的进程。

• 相同点：

• 每次执行命令都会新增一条热更进程，且该进程会一直存在；

• 新会话接管：若存在多个热更新增的进程，则热更后的新会话，可能由任何一个进程接管，有可能是 HAProxy 进程，也有可能是热更进程中的任何一个。

• 区别：

  1）是否终止 HAProxy 进程：

  • -st：直接先终止当前的 HAProxy 进程，并立即重新启动新的 HAProxy 进程；

  • -sf：若 HAProxy 进程当前未存在会话，则功能与 -st 一致，直接关闭当前的 HAProxy 进程并重启，否则会一直等待会话结束（连接关闭），才关闭并重启 HAProxy。

  2）旧会话接管：

  • -st：若原先的 HAProxy 进程上存在会话，则会话会由本次新增的热更进程接管，若此次非第一次热更（本次热更前，已经存在若干个热更进程），且之前的热更进程上存在会话，则本次热更后，原会话仍由原热更进程接管；

  • -sf：由于 HAProxy 进程不会被强制关闭，所以旧会话仍由原 HAProxy 进程接管。