海关申报系统的流程是：
1. 每个海关开一个进程，从数据库中捞取数据。
2. 海关进程取到数据后，先解析回执，再进行申报，这样的目的是防止程序中途崩溃的话，至少可以将回执解析，回执解析的不成功会造成雪崩
以上的模型有一个问题，当数据量大的时候，选取数据需要非常久，可能这个时间都已经到达了雪崩的窗口期，每次数据还没有选完，后面数据就开始重推，所以需要在选取申报数据之前就解析回执，这一点在数据量不大的时候是完全察觉不出来的
ftp上传脚本
ftp上传看起来是个很简单的问题，但是本人在这上面踩了非常多的坑。
程序流程是这样：
1. 脚本开始运行，先将对方服务器上的回执拉取到本地（用ftp中的mget ，delete ），供批跑程序解析，拉取后删除
2. 将指定目录下的报文上传到对方服务器，供对方程序读取解析。这些报文对方在读取之后会被对方程序删掉，无需关心。
ftp上传下载脚本有以下几点坑
1. ftp每次执行命令时，会出现mget 时的数据与mdelete 时的数据集合不相同的情况。比如执行mget 花费了10分钟，这10分钟之内又产生了新的文件，再执行delete 时这些文件就被删除了，并且没有被拉取下来。
2. 由于我们是有两台机器一起运行以分担压力，并用作容灾，两台机器上的脚本如果同时运行，会出现两台机器重复拉取到同一份回执文件，并且，会出现同时删除同一份文件的情况，重复拉取同一份回执文件，对于我们的业务来说，并不算什么问题，解析回执是可以重入的，但是同时删除同一份回执会让命令执行失败就是大问题，而我们的脚本是有重试机制，并且两次重试之间会有2到3秒的间隔，这样会让我们的程序每拉取一份回执，就有一台机器上的脚本要停止2到3秒，换位思考，哪怕你们的重试没有间隔，如果删除时冲突失败的数据量达到几万，几十万，也是一个很蛋疼的事情。所以拉取并删除的时候，千万不能并行，或者并行，但是不要在一个目录下，每台机器新建个自己的临时目录，先把要下载的文件mv到临时目录，下载完后再删除
3. 由于ftp的速度不可靠，数据很大时，上传下载的时间过长，也会出现雪崩，这个时候不能一次性下载或者上传所有文件，因为我们是用脚本写，是批量上传文件，只有等文件上传完毕之后，才会删除已上传文件。如果上传完一笔，就删除一笔，这样会出现大量的ftp短连接，对对方的服务器是一种很大的压力。一次性规定一个合理的文件数，保证一次只上传或者下载这么多文件，不然后面的永远没办法执行。
4. 超时时间的设置在任何接口调用中都很重要，非常重要。一定要记得设置合理的超时时间，不然你的程序卡在那里一年都有可能。
5.