背景：还是两台服务器的同步问题。以前我们使用了坚果云同步，这一次我们用网络策略解决。
整个流程：
- 用户上传图片至 aliyun 的 input 文件夹【格式：13位时间戳+media_id】，自定义风格图片传至 input_user 文件夹；风格图片传至 style 文件夹【格式：13时间戳】
- 将 aliyun 的 input 文件同步到 dnn 的 input，同时将原图片 mv 到temp 文件夹【避免同文件夹的新文件判断】；同步 input_user，切至 temp；同步 style，不移动【根据 input_user 图片的前13位时间戳可以推出风格图访问路径】
- dnn 服务器拿到 dnn 的 input 图片处理，同时切至 dnn 的 temp，移动策略同 aliyun；输出图片到 ouput【格式：原来的基础上加“O”前缀】；
- dnn 服务器将 dnn 的 output 图片同步至 aliyun 的 output 文件夹，同时将原图片 mv 到 copy 文件夹【避免同文件夹的新文件判断】；
- aliyun 将 output 的图片通过文件名与 MySQL 记录找到图片用户发送推送，同时将原图片切至 copy 文件夹。
线程：
根据以上流程，我们规划为以下线程
- 微信服务相关，包括数据库支持，token jssdk校验请求...
由阿里云服务器的 php + MySQL + nginx 环境支持； - 阿里云 input 同步至 dnn服务器 input
dnn 服务器部署 python RESTful API：
nohup python app_get_id.py > app_get_id.out 2>&1 &
阿里云脚本每30s扫描 input 文件夹，将图片名发往 dnn 接口：
nohup python check_input.py > check_input.out 2>&1 &
阿里云脚本每30s扫描 input_user 文件夹，将图片名发往 dnn 接口：
nohup python check_input_user.py > check_input_user.out 2>&1 &
dnn 接口获取图片名称后拼出 url 下载图片，实现阿里云 input 同步 dnn input，input_user、style同理； - dnn 服务器的深度学习程序：
nohup ./supervise.sh & - dnn output 同步至 阿里云 output
阿里云部署 python RESTful API：
nohup python app_get_upload.py > app_get_upload.out 2>&1 &
dnn 每30s扫描 output 文件夹，将图片上传至阿里云 API 接口：
nohup python check_output.py > check_output.out 2>&1 & - 阿里云服务器设置 crontab 任务扫描 output，发送微信推送
->crontab -e
->* * * * * sleep 15; /usr/bin/php -f /home/webwe/www/piconline/mubanxiaoxi.php >> /home/webwe/www/piconline/mubanxiaoxi.txt
比较：
以上可以看出，整个服务由多个接口任务组成，频繁扫描文件夹，有点多看起来很繁琐。
另一种方案：环环相扣回调，比如用户上传完图片后通过回调启动 input 同步。dnn 完成图片加工后通过回调启动 output 同步，同步后再回调启动推送。一气呵成。
这种方案最大的缺点是逻辑过度耦合，各种服务嵌在一起，一旦某一环节挂掉，整个服务流程需要排除，十分困难。
将整个服务拆成多个任务后，各任务相互独立互不干涉，input 同步进程只管同步 input 的事情，其他一概不管。进程挂掉的时候只需在自身小范围解决，其他的 output 照样同步，dnn 照样跑图片。
