这一周处理了几个之前一直出现一直没有正视的坑，总结一下。
sqlalchemy连接池
我写了一个简单的内网dns管理系统，用到flask和sqlalchemy。主要就是通过web页面和api对dns记录进行增删改查，所有这些操作都写入数据库，每次更改后产生一个celery任务来异步的重新生成dns的配置文件。
看起来一个简单的问题，但是在celery中读取数据库的时候出现了问题，每天早上都会报错Mysql has gone away，我重启服务恢复正常，第二天早上又会出现同样的问题，但是在flask的路由下调用的所有数据库操作从未出现任何问题。咨询DBA，DBA说数据库是正常的，所以一定是我的程序处理有问题了。我在网上各种资料查询，最后找到结果。
flask_sqlalchemy默认使用数据库连接池来对理数据库连接进行复用以减少建立连接的开销，他默认会对连接池中的每个连接隔2小时检查一次是否可用，如果不可用就销毁掉，创建新的连接放到连接池中，我们使用db.session的时候就需要从连接池中拿到一个连接，使用完后调用db.session.close来将连接放回到连接池（close并不是关闭连接，关闭连接的操作由连接池来管理）。但是我在路由函数中从来没有使用过db.session.close，也从来没有出现过问题，是因为flask_sqlachemy会自动在请求上下文结束时自动将连接放回连接池，这样放回连接池的连接就会每隔两小时接受一次检查。但是在celery中查询的时候问题就会出现，celery中并没有请求上下文，所有查询完以后并不会将连接放回连接池，也就是说celery中一直使用同一个连接，从来没有放回过连接池，也就从来不会被检查连接的有效性，所以连接断开的时候进行查询，导致报错。
连接为什么会断开呢？原来mysql会把闲置不用超过8小时的连接主动关掉，而dns变更大多是白天上班的时候变更，晚上基本不会变更，这样超过8小时以后mysql的连接已经被断开了，而celery中使用的连接还是前一天早上重启拿到的连接，肯定失效了，拿去查询数据失败，抛出异常。
所以我后来在celery中每次查询结束后都会调用db.session.close，这样会将连接放回连接池，下次查询会重新从连接池中获取新的连接，这个连接每个两个小时会被检查，因此再也没有出现过这个问题。
supervisord 与 celery
这个问题出现在发布系统中，也是让我头疼了好久的一个问题，这一周终于得到解决。我们的发布系统采用celery异步的执行ansible脚本来进行发布的，每次发布大约需要1.5到5分钟不等的时间。我们使用supervisord来管理web端和celery端的启动，每次修改完代码之后上线重启发布系统之后就会出现很多发布任务卡死不再继续执行，每次都需要手动把卡死的发布任务kill掉，然后重发，这周终于找到问题根源了。
众所周知celery有一个warm shutdown的机制，就是给celery master发送一个 SIG_TERM信号，celery master就会通知其管理的workers停止接受新的任务，然后等待手头的任务结束，等到所有workers均完成任务后，master会kill掉所有workers，然后结束运行。我们的发布系统需要的就是这个功能，但是我一直感觉supervisord停止celery的时候并没有采取warm shutdown的方式，因为每次都会又一些celery worker进程未被停止，而且永远不会结束运行，这些celery worker中执行的发布任务就会卡死不动，这个现象叫我百思不得其解。
于是我去查supervisord的文档，发现他停止进程的时候确实默认就发送SIG_TERM信号，而且我也没有这方面的配置，说明应该是使用了warm shutdown的，看celery worker打印出来的日志也确实是有warm shutdown，但是为什么会出现这么诡异的事情呢？我再看supervisord的文档，发现每个由superivsord托管的程序都有一个配置项stopwaitsecs，表示supervisord对这个程序发出SIG_TERM信号（用来杀死该程序）到他收到SIG_CHLD信号（标志着这个程序确实被杀死）之间他愿意等待的时间，如果超过这个时间，supervisord会再次向该程序发出SIG_KILL信号，这个信号是一定会杀死其管理的程序的。也就是说，supervisord会先对celery的master进行warm shutdown的操作，完了之后等待stopwaitsecs秒之后会大开杀戒，直接干掉celery master。而这个stopwaitsecs默认为10s，对于我们一个平均发布时间为3分钟左右的发布任务来说显然等不到warm shutdown真正完成，supervisord就会粗暴的干掉celery master。而这样粗暴的干掉celery master之后，celery worker貌似也出现了异常，再不干活了，因为他是非常依赖master的，而且他干完活之后还需要想master发送ack确认信息的，故此导致这些workers中的发布任务卡死。
当我把stopwaitsecs调整至10分钟之后，再没有出现过类似问题, 因为这个时候，supervisord对celery master进行warm shutdown 操作之后会等待最多10分钟才会粗暴的干掉celery master，而我们的发布任务最长不会超过7分钟，因此10分钟以内warm shutdown一定会成功，supervisord一定会受到SIG_CHILD信号。
总之，以后还是要仔细看文档啊。
网友评论