Python程序中不同的重启机制

[复制链接]
发表于 : 2017-7-31 16:54:54 最新回复:2017-07-31 16:55:09
1835 1
建赟
建赟  专家

分析典型案例:

  1. Celery 分布式异步任务框架
  2. Gunicorn Web容器

之所以挑这两个,不仅仅是应用广泛,而且两个的进程模型比较类似,都是Master、Worker的形式,在热重启上思路和做法又基本不同,比较有参考意义

知识点:

  • atexit
  • os.execv
  • 模块共享变量
  • 信号处理
  • sleep原理:select
  • 文件描述符共享

这几个知识点不难,区别只在于Celery和Gunicorn的应用方式。如果脑海中有这样的知识点,这篇文章也就是开阔下视野而已。。。

Celery和Gunicorn都会在接收到HUP信号时,进行热重启操作

Celery的重启:关旧Worker,然后execv重新启动整个进程

Gunicorn的重启:建立新Worker,再关旧Worker,Master不动

下面具体的看下它们的操作和核心代码。

对于Celery:

  1. def _reload_current_worker(): 
  2.     platforms.close_open_fds([ 
  3.         sys.__stdin__, sys.__stdout__, sys.__stderr__, 
  4.     ]) 
  5.     os.execv(sys.executable, [sys.executable] + sys.argv) 
  6.   
  7.   
  8.    
  9. def install_worker_restart_handler(worker, sig='SIGHUP'): 
  10.     def restart_worker_sig_handler(*args): 
  11.         """Signal handler restarting the current python program.""" 
  12.         import atexit 
  13.         atexit.register(_reload_current_worker) 
  14.         from celery.worker import state 
  15.         state.should_stop = EX_OK 
  16.     platforms.signals[sig] = restart_worker_sig_handler 

HUP上挂的restart_worker_sig_handler 就做了两件事:

  1. 注册atexit函数
  2. 设置全局变量

考虑到这个执行顺序,应该就能明白Celery 是Master和Worker都退出了,崭新呈现。。

看过APUE的小伙伴,应该比较熟悉 atexit 了,这里也不多说。os.execv还挺有意思,根据Python文档,这个函数会执行一个新的函数用于替换掉 当前进程 ,在Unix里,新的进程直接把可执行程序读进进程,保留同样的PID。

在Python os标准库中,这是一整套基本一毛一样的函数,也许应该叫做函数族了:

  • os. execl ( path , arg0 , arg1 , … )
  • os. execle ( path , arg0 , arg1 , … , env )
  • os. execlp ( file , arg0 , arg1 , … )
  • os. execlpe ( file , arg0 , arg1 , … , env )
  • os. execv ( path , args )
  • os. execve ( path , args , env )
  • os. execvp ( file , args )
  • os. execvpe ( file , args , env )

以exec开头,后缀中的l和v两种,代表命令行参数是否是变长的(前者不可变),p代表是否使用PATH定位程序文件,e自然就是在新进程中是否使用ENV环境变量了

然后给worker的state.should_stop变量设置成False。。。 模块共享变量 这个是 Python FAQ里提到的一种方便的跨模块消息传递的方式,运用了Python module的单例。我们都知道Python只有一个进程,所以单例的变量到处共享

而should_stop这个变量也是简单粗暴,worker在执行任务的循环中判断这个变量,即执行异步任务->查看变量->获得异步任务->继续执行 的循环中,如果True就抛出一个【应该关闭】异常,worker由此退出。

这里面有一个不大不小的坑是:信号的发送对于外部的工具,例如kill,是非阻塞的,所以当HUP信号被发出后,worker可能并没有完成重启(等待正在执行的旧任务完成 才退出和新建),因此如果整个系统中只使用HUP信号挨个灰度各个机器,那么很有可能出现全部worker离线的情况

接下来我们看看Gunicorn的重启机制:

信号实质上挂在在Arbiter上,Arbiter相当于master,守护和管理worker的,管理各种信号,事实上它init的时候就给自己起好Master的名字了,打印的时候会打出来:

  1. class Arbiter(object): 
  2.     def __init__(self, app): 
  3.         #一部分略 
  4.         self.master_name = "Master"    
  5.     def handle_hup(self): 
  6.         """\ 
  7.         HUP handling. 
  8.         - Reload configuration 
  9.         - Start the new worker processes with a new configuration 
  10.         - Gracefully shutdown the old worker processes 
  11.         ""
  12.         self.log.info("Hang up: %s", self.master_name) 
  13.         self.reload() 

这里的函数文档里写了处理HUP信号的过程了,简单的三行:

  1. 读取配置
  2. 开启新worker
  3. 优雅关闭旧Worker

reload函数的实现本身没什么复杂的,因为Gunicorn 是个Web容器,所以master里面是没有业务逻辑的,worker都是master fork出来的,fork是可以带着文件描述符(自然也包括socket)过去的。这也是Gunicorn可以随意增减worker的根源

master只负责两件事情:

  1. 拿着被Fork的worker的PID,以供关闭和处理
  2. 1秒醒来一次,看看有没有worker超时了需要***掉
  1. while True
  2.     sig = self.SIG_QUEUE.pop(0) if len(self.SIG_QUEUE) else None 
  3.     if sig is None: 
  4.         self.sleep() 
  5.         self.murder_workers() 
  6.         self.manage_workers() 
  7.         continue 
  8.     else
  9.         #处理信号 

在sleep函数中,使用了select.select+timeout实现,和time.sleep的原理是一样的,但不同之处在于select监听了自己创建的一个PIPE,以供wakeup立即唤醒

总结

以上就介绍了Celery和Gunicorn的重启机制差异。

从这两者的设计来看,可以理解他们这样实现的差异。

Celery是个分布式、异步的任务队列,任务信息以及排队信息实质上是持久化在外部的MQ中的,例如RabbitMQ和redis,其中的持久化方式,这应该另外写一篇《高级消息队列协议AMQP介绍》,就不在这里说了,对于Celery的Master和Worker来说,可以说是完全没有状态的。由Celery的部署方式也可以知道,近似于一个服务发现的框架,下线的Worker不会对整个分布式系统带来任何影响。唯一的例外可能是Beat组件,作为Celery定时任务的节拍器,要做少许改造以适配分布式的架构,并且实现Send Once功能。

Gunicorn作为Python的Web容器之一,会接收用户的请求,虽然我们通常都会使用nginx放在Gunicorn前方做反向代理,通常也可以使用nginx来做upstream offline、online的热重启,但那就不是一个层次的事情了

这里回头来再吐槽Golang

项目中使用到了Golang的一个Web框架,Golang在1.8中也已经支持Http.Server的热关闭了,但是一是因为刚出不就(竟然现在才出),二是因为Golang的进程模型和Python大相近庭,go协程嘛,目前还没有看到那个Web框架中真正实现Gunicorn类似的热重启。

Golang 在fcgi的操作应该就类似Python之于wsgi了。。我感觉我是选择错了一个web框架

也没看见有人用syscall.Exec来用一下execve系统调用,Golang也没看见有人用socket REUSE。。作为一个懒惰的人感觉很蛋疼。。。

先让nginx***做这件事情好了。


  • x
  • 常规:

点评 回复

跳转到指定楼层
建赟
建赟  专家 发表于 2017-7-31 16:55:09 已赞(0) 赞(0)

顶一个!
  • x
  • 常规:

点评 回复

发表回复
您需要登录后才可以回帖 登录 | 注册

警告 内容安全提示:尊敬的用户您好,为了保障您、社区及第三方的合法权益,请勿发布可能给各方带来法律风险的内容,包括但不限于政治敏感内容,涉黄赌毒内容,泄露、侵犯他人商业秘密的内容,侵犯他人商标、版本、专利等知识产权的内容,侵犯个人隐私的内容等。也请勿向他人共享您的账号及密码,通过您的账号执行的所有操作,将视同您本人的行为,由您本人承担操作后果。详情请参看“隐私声明
如果附件按钮无法使用,请将Adobe Flash Player 更新到最新版本!
登录参与交流分享

登录参与交流分享

登录