01、uwsgi、gunicorn如何实现优雅重启

这篇具有很好参考价值的文章主要介绍了01、uwsgi、gunicorn如何实现优雅重启。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

1、为何需要优雅重启

在实际开发过程中,我们会不断迭代升级产品,每次迭代后,都需要在线上服务器更新代码。一般小公司的迭代升级,是没有做到像金丝雀发布或者使用到kubernetes这些东西的。那如何保证更新的时候,之前接收到的请求能够正常处理完成呢,这个时候就需要实现优雅重启了。

那如何实现优雅重启呢,其实,我们部署python web服务所用到的uwsgi和gunicorn已经实现了优雅重启了,下面就讲讲如何实现优雅重启

2、uwsgi 如何实现优雅重启

以下实验是基于以下版本进行的。

python3.6.8

flask==2.0.3
uwsgi==2.0.21

2.1 编写 web 服务

main.py

import time

from flask import Flask

app = Flask(__name__)


@app.route("/")
def index():
    time.sleep(10)
    return "hello eeee"


if __name__ == "__main__":
    app.run()

2.2 编写 uwsgi.ini 配置文件

[uwsgi]
#uwsgi启动时,所使用的地址和端口(这个是http协议的)
http=0.0.0.0:8000
#指向网站目录
chdir=./
#python 启动程序文件
wsgi-file=main.py
#python 程序内用以启动的application 变量名
callable=app
#处理器数
processes=4
#线程数
threads=2

#####实现优雅重启添加下面两行配置即刻#####
lazy-apps = true
#监听 test.txt 文件 当 test.txt 发生改变时优雅重启uwsgi。这个名字可以随便起
touch-chain-reload = /Users/xx/work/test/py_test/sample_test/flask_graceful_restart/test.txt

2.3 启动uwsgi 服务

uwsgi --ini uwsgi.ini

2.4 测试优雅重启

1、请求 http://127.0.0.1:8000/

2、更新 main.py 中返回的内容,改为: return "hello xxxxx"

2、在/Users/xx/work/test/py_test/sample_test/flask_graceful_restart 目录下,执行 touch test.txt。有这个文件时,更改这个文件的内容也可以优雅重启 uwsgi 服务

3、得到第一步的返回结果,返回结果为:"hello eeee"

5、再次请求 http://127.0.0.1:8000/ ,返回结果为:"hello xxxxx"

通过上述测试,可以发现实现了优雅重启。

优雅重启的日志过程:

整个时间还挺久的,差不多4分钟。

开始:12:14:45。

结束:12:18:57。

1、先查看 uwsgi 进程信息

501  7758  4633   0 12:13PM ttys005    0:00.04 uwsgi --ini uwsgi.ini
501  7759  7758   0 12:13PM ttys005    0:00.27 uwsgi --ini uwsgi.ini
501  7760  7758   0 12:13PM ttys005    0:00.27 uwsgi --ini uwsgi.ini
501  7761  7758   0 12:13PM ttys005    0:00.27 uwsgi --ini uwsgi.ini
501  7762  7758   0 12:13PM ttys005    0:00.26 uwsgi --ini uwsgi.ini
501  7763  7758   0 12:13PM ttys005    0:00.00 uwsgi --ini uwsgi.ini
501  7789  6013   0 12:13PM ttys006    0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox uwsgi

2、生成 test.txt 时的现象:当 出现 chain reloading complete 时,代表了优雅完成。

Mon Apr 10 12:14:45 2023 - *** /Users/mashili/work/test/py_test/sample_test/flask_graceful_restart/test.txt has been touched... chain reload !!! ***
Mon Apr 10 12:14:45 2023 - chain next victim is worker 1
Gracefully killing worker 1 (pid: 7759)...
Mon Apr 10 12:15:46 2023 - worker 1 (pid: 7759) is taking too much time to die...NO MERCY !!!
worker 1 killed successfully (pid: 7759)
Respawned uWSGI worker 1 (new pid: 7847)
Mon Apr 10 12:15:47 2023 - chain is still waiting for worker 1...
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x7fc33e00da00 pid: 7847 (default app)
Mon Apr 10 12:15:48 2023 - chain next victim is worker 2
Gracefully killing worker 2 (pid: 7760)...
Mon Apr 10 12:16:49 2023 - worker 2 (pid: 7760) is taking too much time to die...NO MERCY !!!
worker 2 killed successfully (pid: 7760)
Respawned uWSGI worker 2 (new pid: 7885)
Mon Apr 10 12:16:50 2023 - chain is still waiting for worker 2...
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x7fc33e00da00 pid: 7885 (default app)
Mon Apr 10 12:16:51 2023 - chain next victim is worker 3
Gracefully killing worker 3 (pid: 7761)...
Mon Apr 10 12:17:52 2023 - worker 3 (pid: 7761) is taking too much time to die...NO MERCY !!!
worker 3 killed successfully (pid: 7761)
Respawned uWSGI worker 3 (new pid: 7905)
Mon Apr 10 12:17:53 2023 - chain is still waiting for worker 3...
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x7fc33e00da00 pid: 7905 (default app)
Mon Apr 10 12:17:54 2023 - chain next victim is worker 4
Gracefully killing worker 4 (pid: 7762)...
Mon Apr 10 12:18:55 2023 - worker 4 (pid: 7762) is taking too much time to die...NO MERCY !!!
worker 4 killed successfully (pid: 7762)
Respawned uWSGI worker 4 (new pid: 7910)
Mon Apr 10 12:18:56 2023 - chain is still waiting for worker 4...
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x7fc33e00da00 pid: 7910 (default app)
Mon Apr 10 12:18:57 2023 - chain reloading complete

3、优雅重启过程中,查看进程信息。ps -ef|grep uwsgi

发现即存在新的进程,也存在老的进程。测试的时候,发现,优雅重启过程中,并不一定会将重启过程中的请求转发到新的进程中去。

  501  7758  4633   0 12:13PM ttys005    0:00.08 uwsgi --ini uwsgi.ini
  501  7761  7758   0 12:13PM ttys005    0:00.27 uwsgi --ini uwsgi.ini
  501  7762  7758   0 12:13PM ttys005    0:00.26 uwsgi --ini uwsgi.ini
  501  7763  7758   0 12:13PM ttys005    0:00.00 uwsgi --ini uwsgi.ini
  501  7847  7758   0 12:15PM ttys005    0:00.26 uwsgi --ini uwsgi.ini
  501  7885  7758   0 12:16PM ttys005    0:00.26 uwsgi --ini uwsgi.ini
  501  7889  6013   0 12:17PM ttys006    0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox uwsgi

2.5 线上如何更新

1、首先将代码更新到服务器。

2、ps -ef|grep uwsgi 查看现在的进程号。

2、查看 test.txt是否存在,存在就更新文件内容,不存在就生成 test.txt。

3、观察uwsgi的日志或者进程,待所有的worker进程都重启生成后,即完成了优雅重启。

3、gunicorn 如何实现优雅重启

3.1 编写 web 服务

main.py

import time

from flask import Flask

app = Flask(__name__)


@app.route("/")
def index():
    # time.sleep(3)
    return "hello fdaf fdafd "


if __name__ == "__main__":
    app.run()

3.2 编写 conf.py 配置gunicorn 文件

conf.py

# 是否开启debug模式
debug = True
# 访问地址
bind = "0.0.0.0:8888"
# 工作进程数
workers = 2
# 工作线程数
threads = 2
# 超时时间
timeout = 600
# 输出日志级别
loglevel = 'info'
# 存放日志路径
pidfile = "log/gunicorn.pid"
# 存放日志路径
accesslog = "log/access.log"
# 存放日志路径
errorlog = "log/debug.log"

######注意,下面这个不能加,加了就不能达到优雅重启的效果,切记切记!!
# gunicorn + apscheduler场景下,解决多worker运行定时任务重复执行的问题
# preload_app = True

3.3 启动 gunicorn 服务

gunicorn -c conf.py main:app

3.4 测试优雅重启

1、pstree -ap|grep gunicorn 找到主进程

pstree -ap|grep gunicorn

2、执行 kill -HUP masterpid

kill -HUP 1540847

3、再次 执行 pstree -ap|grep gunicorn,发现worker 进程id不一样后,即更新完成。或者查看日志

[2023-04-10 15:36:51 +0800] [11623] [INFO] Handling signal: hup
[2023-04-10 15:36:51 +0800] [11623] [INFO] Hang up: Master
[2023-04-10 15:36:51 +0800] [11681] [INFO] Booting worker with pid: 11681
[2023-04-10 15:36:51 +0800] [11682] [INFO] Booting worker with pid: 11682
[2023-04-10 15:36:51 +0800] [11644] [INFO] Worker exiting (pid: 11644)
[2023-04-10 15:36:51 +0800] [11645] [INFO] Worker exiting (pid: 11645)

3.5 线上如何更新

1、通过 pstree -ap|grep gunicorn 找到主进程ID

2、执行 kill -HUP masterpid 命令

3、等待gunicorn优雅重启完成文章来源地址https://www.toymoban.com/news/detail-409639.html

到了这里,关于01、uwsgi、gunicorn如何实现优雅重启的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • k8s中的PVC为何需要延迟绑定?(WaitForFirstConsumer)

    有一个pod, 使用的pvc叫pvc-1, 我们希望它只运行在node-2上,在当前的集群中存在两台主机符合pod的pvc的要求, 假如node-1上是pv-1, node-2上是pv-2,这两个完全一样. 这时如果创建pod, pv控制器看到pv-1与pvc-1是匹配的,因此将它们绑定在一起, 如果没有其它限制条件, 在调度阶段pod将

    2024年02月14日
    浏览(42)
  • 【区块链】从社区平台MOJOR看,为何Web3需要原生?

    在大环境的影响之下,Web3 和传统行业似乎正处于一种两极分化的状态。 众所周知,大放水时代的余温正在逐渐褪去,席卷全球的寒冬似乎正在降临:后疫情时代经济滞涨带来的负面影响日益显现;美欧等地区的通胀高企,使货币政策收紧将成为未来几个月的主旋律。经济衰

    2024年02月02日
    浏览(49)
  • Golang | Web开发之Gin多服务配置及优雅关闭平滑重启

    欢迎关注「 全栈工程师修炼指南 」公众号 点击 👇  下方卡片  即可关注我哟! 设为 「 星标⭐ 」 每天带你  基础入门  到  进阶实践  再到  放弃学习 ! 专注  企业运维实践、网络安全、系统运维、应用开发、物联网实战、全栈文章  等知识分享 “    花开堪折直须折

    2024年02月08日
    浏览(44)
  • 【深度思考】如何优雅的实现脱敏?

    最近做了个脱敏的需求,要对系统中的敏感信息,如手机号、车牌号、身份证号、银行卡号等进行脱敏显示。 效果类似下面这样: 简单来说,就是对敏感信息中的某几位进行掩码显示,常见的一般是使用*。 本篇文章就来讲解下在项目中该如何优雅的实现脱敏。 首先,需要

    2024年02月11日
    浏览(34)
  • 如何优雅的实现前端国际化?

    JavaScript 中每个常见问题都有许多成熟的解决方案。当然,国际化 (i18n) 也不例外,有很多成熟的 JavaScript i18n 库可供选择,下面就来分享一些热门的前端国际化库! i18next 是一个用 JavaScript 编写的全面的国际化框架,提供标准的 i18n 功能,包括复数、上下文、插值、格式等。

    2024年01月23日
    浏览(61)
  • SpringBoot如何优雅的实现异步调用?

    Spring Boot 提供了多种方式来实现异步任务,这里介绍三种主要实现方式。 Spring Boot 提供了多种方式来实现异步任务,这里介绍三种实现方式。 @Async 注解是 Spring 提供的一种轻量级异步方法实现方式,它可以标记在方法上,用来告诉 Spring 这个方法是一个异步方法,Spring 会将

    2024年02月07日
    浏览(35)
  • 【SpringBoot系列】如何优雅地实现异步调用

    1.前言 在现代的应用程序开发中,异步调用是提高系统性能和响应能力的重要手段之一。 Spring Boot作为一个快速开发框架,提供了多种方式来实现异步调用,使得开发者能够更加优雅地处理并发和异步任务。 本文将介绍如何在Spring Boot中实现异步调用的方法和技巧,帮助开发

    2024年02月07日
    浏览(41)
  • 金融用户敏感数据如何优雅地实现脱敏?

    日志脱敏是常见的安全需求。普通的基于工具类方法的方式,对代码的入侵性太强,编写起来又特别麻烦。 sensitive 提供了基于注解的方式,并且内置了常见的脱敏方式,便于开发。 为了金融交易的安全性,国家强制规定对于以下信息是要日志脱敏的: 用户名 手机号 邮箱

    2024年02月07日
    浏览(41)
  • 如何优雅的实现接口防刷,看过来!!!

    在我们的app、网站等互联网应用系统中,如果接口直接暴露在外网下,是存在着接口安全问题的。当我们的接口没有任何防刷的措施,就相当于在互联网上裸奔一样!当被一些不怀好意的人利用,那就是发生灾难的时候了! 那应该怎么确保我们的接口安全呢? 通常来说,我

    2024年02月08日
    浏览(32)
  • SpringBoot如何优雅的实现重试功能

    在有些特定场景,如和第三方对接。 我们调用接口时需要支持重试功能,第一次调用没成功,我们需要等待x秒后再次调用。 通常会设置重试次数,避免业务。 一般我们会这样写 这样写本身,没什么问题。 但是如果多个接口都需要重试的话,代码就不优雅了。 spring系列的

    2024年02月08日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包