定頻數據收集方案

場景：

　　每隔必定時間， 從其餘系統（多是異構網絡）獲取相關數據。

 

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.五、1.六、1.七、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