这是一个创建于 3959 天前的主题，其中的信息可能已经有所发展或是发生改变。
我的程序是个采集程序
有时候 可能数据库出现问题 比如连接不上
我使用了 try 语句
在出错的时候，我想让他 延时1分钟， [也就是等待一分钟，]
然后重启自身 [重新启动 重新连接]
有时候 可能数据库出现问题 比如连接不上
我使用了 try 语句
在出错的时候，我想让他 延时1分钟， [也就是等待一分钟，]
然后重启自身 [重新启动 重新连接]
 |
1
tan9le 2014-01-08 14:34:28 +08:00  1
不可以是两个python程序么？A程序就是你的正常应用，发生异常以后将错误码作为参数唤起B应用，B应用记录LOG信息,sleep/wait一分钟以后唤起A应用，同时B应用结束。
|
 |
3
a591826944 2014-01-08 14:56:13 +08:00 1
time 不是有个sleep么 你可一 try 失败的时候 sleep啊 然后 递归 不久好了么
|
|
4
tan9le 2014-01-08 15:08:47 +08:00 1
@loading 木有demo，我是做J2EE的，Python应该也有类似于Java中的Runtime.exec的机制吧，就是调用系统命令。
刚刚查了一下，import os之后，os module里的popen、system方法貌似都可以调用系统命令，可以os.system('命令');来执行呀，python Path of B程序就是了。 |
 |
5
clino 2014-01-08 15:10:03 +08:00 1
用 supervisor 来管理这样的进程吧, 配置一下相关参数就可以了
|
 |
6
loryyang 2014-01-08 15:16:19 +08:00
你为什么一定要退出？你确定有必要这么做吗？
|
 |
7
strak47 2014-01-08 15:21:06 +08:00 1
time.sleep(60)就行了吧
|
 |
8
nybux 2014-01-08 15:24:41 +08:00 1
后台启动一个shell执行，sleep 60 && <你的脚本>
类似于这样: echo "sleep 60 && echo 'a'" | sh |
 |
9
ritksm 2014-01-08 15:29:51 +08:00 1
为什么没有人提http://docs.python.org/2/library/subprocess.html
a.py用subprocess调用b.py.然后监控退出.异常退出重启即可 a.py可以有自己的退出逻辑，不如b.py失败10次，一个while的事情 |
 |
10
fdsfsdfsdf3334 OP @loryyang 退出的目的是为了重启， 连接失败后，我该怎么引导程序再次执行链接数据库呢 如果一直连接不上呢 不太方便哦 又要写很多代码 主要是太麻烦了 重启比较简单
|
 |
11
Maslino 2014-01-08 16:25:38 +08:00 1
@fdsfsdfsdf3334 ORM或者数据库driver一般可以配置自动重连。如果抛异常，考虑截住异常然后sleep一段时间（比如指数退避）然后重试。
|
|
12
loryyang 2014-01-08 16:52:06 +08:00
@fdsfsdfsdf3334 总感觉从程序逻辑讲，处理连接异常也是你的python程序需要处理的一种情况，把这种情况交给python外部的程序处理有点责任混乱了。
但是如果是你自己玩玩那倒无所谓，你用一个守护进程就ok了，守护进程通过pid监控python程序，如果发现python程序消失了，sleep60秒，重启python程序就ok |
|
13
fdsfsdfsdf3334 OP @loryyang 是个企业级应用 同步公司的一些数据 目前 可以长期运行在服务器上， 不会出现意外，唯一的意外是 如果远程数据库重启了， 那么这里的成就会报错 奔溃， 目前我还没写 数据库连接的容错代码，想选个安全 高效 齐全的方法
|
 |
14
9hills 2014-01-08 17:14:11 +08:00
又是一个X-Y问题，不去解决数据库重连，反倒是想重启整个Python脚本。。
|
|
15
loryyang 2014-01-08 17:15:22 +08:00
@fdsfsdfsdf3334 那就在python代码里面改吧，数据库连接重试是个常见问题，肯定有很多的解决方案了的，不会花费太多精力的
|
 |
17
suriv520 2014-01-08 20:21:16 +08:00 1
我的经验是：当你发现自己的某个设计做起来很难的时候，一定是打开方式有问题……这种情况放开思路多想想，比往牛角尖里钻要划算……
普通青年 用Supervisord这个神器护身，或者subprocess开工，或者调外部命令（Linux下的at命令你知道的吧）重启。也懒得管程序里崩出了什么错误，反正最外面有专业防泄漏直接重启进程。 2B青年 有时候不知道到底是数据层出问题了，还是应用出问题了，还是系统哪个地方死翘翘了。怎么搞？不怕！把所有的必需服务都设成开机自启动，cronjob里加检测脚本，一旦出问题，祭出reboot大杀器…… 文艺青年 在DB层的connection handler里加入异常重连。重连几次仍然失败的情况下直接抛出异常，让主循环的循环体直接崩掉，sleep一段比较长的时间后再开始主循环。 砖家叫兽 这种问题简直不叫问题了……你一定还没听过DBUtil、SQLAlchemy之类的杀器吧…… |
|
18
fdsfsdfsdf3334 OP @suriv520 确实没听过 我去研究看看
|
 |
19
Muninn 2014-01-08 23:03:52 +08:00
我写类似的东西,都是先连接然后捕获
要是没连接上 隔30秒重试 再不行隔1分钟 然后2分钟 4分钟 设置个最多的次数 三四行就搞定了... |
 |
20
vbs 2014-01-09 00:19:45 +08:00
supervisor +1
|
 |
21
mongodb 2014-01-09 00:57:01 +08:00
|
 |
22
stevenyou 2014-01-09 09:25:17 +08:00
|
 |
23
arcas 2014-01-09 10:13:51 +08:00
一个master 多个 worker?
|
|
24
suriv520 2014-01-09 10:49:23 +08:00
@mongodb 角度不一样，结论不一样。
从运维的角度来讲，你的观点完全正确，并且也是主流的。 从商业角度讲，你的观点也完全正确。 但如果你们公司的开发把这样的产品交付给你们，还认为重启是理所当然的，那你大可让他们按照上述分类对号入座。 |
 |
25
lixm 2014-01-09 15:07:32 +08:00
@suriv520 重启是理所当然的，一旦出现问题，尽快退出，交由supervisor善后重启，这样的思路很对啊，erlang就是这么干的
|
|
26
suriv520 2014-01-09 15:32:41 +08:00
@lixm 『重启』本质上是最粗暴的『异常处理』,怎能说『理所当然』？如果Nginx三天两头崩一次，如果MySQL三天两头崩一次，你敢用？
|
Select Language