背景

重启python服务之后，课表推送服务莫名失效

可能性

  • 调用微信推送接口逻辑有问题
  • 重写推送服务之后，服务部署失败
  • 由于服务器内存资源有限导致推送的时候，处理课表数据的时候，OOM导致进程被干掉了。

解决方案及思路

  1. 本地测试了一遍，推送课表服务，发现推送成功，排除第一种可能性

  2. 重写推送服务之后，服务部署失败，发现在启动celery服务的时候确实启动失败了，因为通过微信后台的接口调用数据，发现到时间点的时候，即使调用失败也应该有调用接口次数统计，于是重新部署服务并打好了日志，防止后续出错，以便快速找到问题。

  3. 排查服务器资源

    1. 上python的服务器之后，发现当时部署定时推送服务的时候没有打log（这是一个重大失误，以后一定要打不然很难找到问题的），后面重新部署了一遍，中途遇到了如下问题：

      1. 多次nohup同一任务的时候，应该查看此任务进程是否还存在，如果存在就需要kill，否则会服务器后台会挂起多个相同的进程，导致服务器资源浪费，甚至可能导致宕机。。。比如昨天就是nohup多次同一个任务进程，导致资源浪费甚至被干宕机了

    2. 等到推送的时候，查看celery打出来的日志，发现，返回的是40001，然后根据微信公众号的官方文档，发现是因为目前的accession_token失效导致的。

    3. 分析原因如下：

      python服务器和主服务器都可能会请求公众号的token，如果python先请求token并保存在了本地redis里面，然后在7200s内，主服务器又请求了一次公众号的token，那么这时候python服务器的redis里面存的token就会失效（即使没有超时也会失效），然后推送课表的时候又是从python服务器的redis里面拿的失效的token，所以一直没有推送成功

总结：

部署python服务流程：

  1. 进入activate虚拟环境
  2. 如果python代码更新，需要重新部署，需要重新启动guincorn，命令如下：
1
gunicorn --config config/gunicorn.conf.py gateway.app:app
  1. 如果使用的是本地的redis，需先打开docker，再启动redis
1
2
3
sudo systemctl start docker

docker start redis_name //在docker容器里面给某个redis取的别名
  1. 重启celery beat，好像是类似于im一样的心跳机制，worker需要通过beat的心跳来保证正常运行。
  2. 重启cerlery worker来守护进程，使得定时任务后台挂起。