场景：
每隔一定时间， 从其他系统（可能是异构网络）获取相关数据。
1. 消息队列方案
rabbitMQ
考虑点：
1. 消息保证稳定可靠被处理（因此队列需要声明为可持久化的， 生产者push消息的时候delivery_mode为2）
2. 消息被处理后， 确认后， 及时从内存和硬盘中删除。可能会影响写入的并发性能。
参考： https://groups.google.com/forum/#!topic/rabbitmq-users/MuqmsmwRyXc
ps： 假设不持久化也足够稳定， 那么可以不用持久化，来提高性能， 同时存盘的数据不会被其他人通过其他手段看到（猜测不是立即删除， 满足一定条件：待删除的量达到一定程度。因此可能有时延。）。
3. 设定硬盘和内存使用阀值：https://www.rabbitmq.com/alarms.html。 保证程序不挂掉。
4. 由于对外访问，因此需要权限控制：
概览：https://www.rabbitmq.com/authentication.html
如何：
https://www.rabbitmq.com/man/rabbitmqctl.1.man.html#User%20management
https://www.rabbitmq.com/man/rabbitmqctl.1.man.html#Access%20control
原理：https://www.rabbitmq.com/access-control.html
简单说， 就是（虚拟主机vhost + 用户账户+密码?）， 为了防止暴力破解， 虚拟主机和用户名的设定的时候尽可能的复杂，然后不要泄露。
kafka
http://www.infoq.com/cn/articles/kafka-analysis-part-1
2. web接口方案
http rest api
比如做一个http rest服务器。
考虑点：
1. 数据量，如果数据量很大， 需要分页传送。 一个页面一次http请求， 因此一个比价大的数据可能要进行很多次http请求。建立连接的成本很高。
2. 每个请求写入一次磁盘。数据及时落入磁盘。
3. 授权验证
4. 可以开多进程服务做负载均衡，支持客户端的多线程分页传输
5. 回执（传输成功or失败），方便两边比对数据。
优点：容易实施。可控性好。
缺点：数据量大了，效率低；可能无法完成任务。
3. 文件传输方案
ftp
略
http断点续传
nginx + upload_module
转载请注明来源：http://www.cnblogs.com/Tommy-Yu/p/6387423.html
原文：http://www.cnblogs.com/Tommy-Yu/p/6387423.html