我目前有一个用Python 2.7编写的脚本，它整理了一系列变量。这个脚本每天24小时在Linux操作系统上运行。
我要做的是将数据从这些列表移动到远程服务器。这种数据传输将通过3G互联网连接，因此，我热衷于在本地写入数据，然后在连接可用时传输数据（由于覆盖范围不佳等）...
我的意图是，在代码运行开始时，捕获POSIX中的实际时间并创建一个新的.txt文件。然后，我将在开始时间后30分钟计算，并将此值也添加到变量中。我打算让我的脚本检查它的连续循环来检查时间。如果它匹配30分钟的POSIX值，我会在创建一个全新的文本文件并一遍又一遍地重复此过程之前，将列表中的所有信息写入.txt文件。然后，我将使用RSync将.txt文件同步到中央服务器。
这是完成此过程的有效方法吗？如上所述，我将通过移动互联网（3G）将数据同步到远程服务器，因此可能存在覆盖范围较差的区域。因此，我发现在同步文件之前在本地编写数据更简单。
我决定每隔30分钟创建一次文件，这样，如果脚本失败或出现断电，最多只能丢失30分钟的数据而不会损失数小时。
我想对我的思考过程提出任何反馈。
由于
答案 0 :(得分：1)
您的设计确实没有效率问题。
你有一个持续的循环，可能是做了一些重要的工作。通过循环增加获得当前时间和进行一次浮动比较的成本与你正在做的任何事情相比都是如此便宜，因为它没有任何区别。
如果你不大部分时间在循环中做任何重要的工作，那么循环本身可能是你的主要性能成本，你最好不要经常运行它。< / p>
然而，打开文件很奇怪，让它静坐30分钟，然后立即写入/关闭/上传。一个更好的解决方案是在你写它之前创建它。或者，更好的是，随着时间的推移写入（而不是维护列表），可能每隔几秒刷一次，然后每隔30分钟关闭/上传/替换。
同时，如果Python代码每隔30分钟尝试做一次，那么你的cron工作也是如此，它们显然会不同步。由于3G问题，你预计它可能会有几个小时不同步，这可能不是问题。
最后，您正在做的是非常接近syslog样式的日志记录和日志轮换。即使它在技术上不是通常意义上的日志文件，它仍然值得查看linux的syslog和logrotate和/或Python的logging（特别是类似的东西） TimedRotatingFileHandler或其他处理程序之一）可以为您做到。
答案 1 :(得分：0)
这就是我要做的事。
我会不断地将数据写入输出文件，刷新每N条记录。如果你只损失1秒的价值，为什么要在崩溃中丢失30分钟的数据呢？
一旦文件大小一定或超过30分钟，我就会关闭文件并将其移至outbound/目录。然后我将创建一个新文件作为输出文件。
单独的脚本将控制上传。一个粗略的例子：
inotifywait -q -m -e create /path/to/outbound | while read fpath cmd fname; do
fullpath=$f{fpath}/${fname}
rsync $f{fullpath} remotehost && rm ${fullpath}
done
这将侦听出站目录中的创建事件，因此一旦您的脚本移动了文件，rsync就会启动。您也可以考虑从{cron连续运行rsync --remove-source-files。