在上一個版本中，record表存儲了7萬多條記錄，爬取的有4萬多條，但是可以明顯的發(fā)現(xiàn)爬取的數(shù)據(jù)量越多的時候，機(jī)子就越卡。又一次報錯，是有關(guān)JDBC的，還有一次機(jī)子跑卡死了。
仔細(xì)一琢磨，上個版本的爬蟲程序與數(shù)據(jù)庫的讀寫次數(shù)太頻繁，存在以下問題：
1.程序運(yùn)行，從種子地址開始，對于每次爬取的網(wǎng)站地址先查詢數(shù)據(jù)庫是否存在該條記錄，如果不存在，則立即插入；
2.當(dāng)前網(wǎng)站地址爬取完畢后，查找數(shù)據(jù)庫從中取出第一個crawled為0的記錄進(jìn)行爬取，每次只取一條；
3.存儲電影詳情頁記錄以及短評數(shù)據(jù)都是采用解析一條則立即存儲到數(shù)據(jù)庫。
顯然，上面的這種方式是一目了然的效率低下，所以今天下午對相關(guān)代碼進(jìn)行改造，部分實現(xiàn)了批量插入，盡可能減少與數(shù)據(jù)庫的交互，從而降低時空成本。
在git clone完項目后，發(fā)現(xiàn)一個很詭異的現(xiàn)象，JewelCrawler每次都是爬取種子地址，并沒有一次查詢數(shù)據(jù)庫中crawled字段為0的記錄進(jìn)行一一爬取，但是之前在本機(jī)上是完美運(yùn)行的，可能是在push代碼前做了改動影響運(yùn)行了。
既然問題出現(xiàn)了，就順著這個版本看看，最終發(fā)現(xiàn)問題的原因是對于種子網(wǎng)址并沒有存儲到mysq
