概況：幫周同學做小說采集做了有一段時間了。一開始是從其它網站的頁面上直接寫正則去采集，然后慢慢的轉為采集別人提供的API。

環境：CENTOS+NGINX+PHP5.2.17。基于JIEQI小說管理系統。

直接采集其它網站頁面的時候，主要改的是JIEQI自帶的采集系統，印象比較深的，是加上了判斷章節順序的功能，還修改了其它的“BUG”(呀，其它具體什么來著，我現在都快忘了，做了好久了)。這回感觸比較深的是，是采集API。

背景：采集數十個小說站的API(目前有五個，預計有40，50個)

設計：共用一個顯示頁面，邏輯分開處理。可批量采集，可單篇采集。

上個圖：

其中，兩個實體，是根據我需要的信息，自己定義的。為什么要規定這個實體(或者是接口)，主要是因為，每個API給的信息都是不一樣的，要統一后，才能操作。

單篇采集 VS 多篇采集

單篇采集相對比較簡單，想怎么寫都行，問題不大。

而多篇批量采集，這次寫了四個版本。

V1：將所有的操作，寫在了同一PHP進程里面。

優勢：邏輯簡單，容易實現。

缺點：PHP進程容易龐大，容易掛悼。

問題：最大只能設置5篇，而且，不能看到采集的過程。

V2：將所有的操作分開，用file_get_contents遍歷訪問。

優勢：類似“異步”采集，將所有操作分開到每個進程，單進程不容易掛。效率很高。

缺點：采集過程將產生N多個PHP進程，NGINX會出現504等錯誤。

問題：如上述缺點，如果一作品的章節較多，在短時間內(0.1S或更短)產生上百個HTTP請求，NGINX出現問題，服務器吃不消。

改進：在PHP中加上sleep，導致NGINX不穩定，集中耗資源。偶爾還出現file_get_contents的錯誤。

V3：結合V1和V2,用JS做定時。

思路：使用iframe，定時刷新采集的每個頁面(V2)，根據頁面返回信息，做下一步操作。即：循環設置iframe的SRC。

優勢：將采集時集中對服務器的壓力分散掉，章節按順序來入庫。

缺點：采集的間隔時間，不太好設置。哪怕是根據iframe的返回值，再判斷，也要多加定時(采用父頁面定時刷新，定時抓取iframe的數據來判斷)。

問題：setTimeout出各種問題，會出現無法控制的情況。因為JS也是單線程的。setInertval也一樣。

V4:結合前面三，主要改進是在V3的基礎上，再次分開。

思路：不再循環設置iframe的SRC，而是，新建N多個iframe。

優勢：可以很輕松的控制時間(即：間隔多少S，打開新的iframe)。

缺點：若前面的章節操作比較慢(即：比如說，第一章卡殼了，2S都還沒有連接上采集的PHP的URL。而第二章，在第0.5S后，已經開始，且連接上了，那么第二章就會在第一章之前入庫)，這里就涉及到一個章節的順序問題。還有，同上，第一章已經連接上了，但，操作特慢，2S才搞定；而第二章，字數少(或其它原因)，1S就搞定了，問題同上。

問題：同上缺點所述，還有一個問題要注意。因為有些字段，必須要在采集完之后，更新表的。SO，采用了一個方法：就是子頁JS，調用父頁的JS的一個方法，在父頁中設置一個iframe(ajax或script一樣)，訪問修正作品的URL。

實用：果然，實用的時候，缺點所產生的問題已經出現了。

修正：將章節排序的字段，做到和章節信息一樣，放到數組里面，同步更新。這樣，哪怕第二章先入庫，但它的order，還是2。第一章后入庫，其order為1。在顯示時，還是第一章在前面。問題解決。

每個采集站的API和模版都分開了，這樣的好處就是統一了接口，其它的自由發揮。做這個玩意，也被周同學說了幾次，不過想想，確實，一開始做的時候，沒有考慮這么細，做得不夠好，看來，還是經驗不夠啊。

當然，采集的話，建議使用.net做成一個EXE。有向周同學提，但他覺得更麻煩，也懶得重新來弄過。現在這個版本，夠用了，符合要求了。還有優化的地方繼續優化。

此拋磚引玉，期待大牛們的指點。

總結

以上是生活随笔為你收集整理的小说站源码php采集,关于PHP批量采集----采集小说站有感的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。