服务A提供数据一天100W的日志数据, B需要写一个接口去抓取服务A的数据，（假定A的100W可以模拟成从数据库取出来） ， 现在需要设计一个接口，保证接口可以比较快速的获取100W的数据，获取数据突然中断可以断点继续获取，同时还要保证接口安全
这么大的数据量，还要求断点续传，幸好是日志数据，实时性应该要求不高。
可以考虑让服务A定时导出到一个文件，然后服务B通过ftp/sftp之类的直接下载，ftp的速度已经够快的了，如果还要更快，可以搭个NFS共享文件。（都是支持断点续传的哦）
对方提供的接口有没有时间参数什么的？如果有就可以进行分批请求，每次记录最后的时间，下次请求使用这个时间做条件就好
你也可以将收到的数据写入redis的队列中，同时另一个进程从redis队列中读取数据批量写入数据库里
楼上的说法，如果可以使用文本的话， 也可以考虑使用 rsync 进行同步
我做过同样的一个数据统计的服务，
A服务，是一台服务器（A服务器）
B服务，在另外一台服务器上面（B服务器）
最终解决方案是A服务器的数据最终通过文件存储下来，
然后在A服务器上面通过计划任务用 脚本（php的curl）或者简单点 直接rsync命令同步到B服务器，
然后B服务器扫文件内容，然后将数据归档,去重，入库等。。
这么大的数据，使用API传输效率太低了点吧。
* 将每日的数据库直接导出成文件（数据量如果太大，可以每小时的数据导出一个文件，或者10W条一个文件）
* 然后服务器B通过Http获取（Http断点续传很容易实现）
* 获取到以后反向解包数据，导入数据库
这样做的好处是实现起来比较简单，不易出错。
100W的数据量还是很少的。我第一眼看的时候，还以为100M呢。
解决方法比较赞同@sunwenzheng的提议。采用Redis的队列来解决。
解决方法如下：
1.在B服务器搭建队列服务（不搭建在A上，是因为你的A服务器可能是主服务器，减少其压力）
2.A服务器，生成日志之后立即Push到B服务器Redis的队列中。
3.B服务器轮询队列，收集数据插入到数据库。
这样做的好处是，保证了日志记录的时序以及可以控制日志获取的时效。而且针对100W数据绰绰有余。
可以考虑用分页处理方法。比如100W条，我一次处理1W条，处理完后，在处理下一页的数据。至于这个如何处理，可以先获取总数，然后生成队列任务。在依靠服务器去执行获取数据