場景：
每隔一定時間， 從其他系統（可能是異構網絡）獲取相關數據。
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 + 用戶賬戶+密碼?）， 爲了防止暴力破解， 虛擬主機和用戶名的設定的時候儘可能的複雜，然後不要泄露。
5. 可能需要給擼sdk或者client demo。
java: 對於jdk1.5、1.6、1.7、1.8可能依賴不同的jar包和文檔。 （不同版本的jar--含文檔： http://www.rabbitmq.com/releases/rabbitmq-java-client/）
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