在上一個(gè)版本中，record表存儲了7萬多條記錄，爬取的有4萬多條，但是可以明顯的發(fā)現(xiàn)爬取的數(shù)據(jù)量越多的時(shí)候，機(jī)子就越卡。又一次報(bào)錯(cuò)，是有關(guān)JDBC的，還有一次機(jī)子跑卡死了。

　　仔細(xì)一琢磨，上個(gè)版本的爬蟲程序與數(shù)據(jù)庫的讀寫次數(shù)太頻繁，存在以下問題：

　　　　1.程序運(yùn)行，從種子地址開始，對于每次爬取的網(wǎng)站地址先查詢數(shù)據(jù)庫是否存在該條記錄，如果不存在，則立即插入；

　　　　2.當(dāng)前網(wǎng)站地址爬取完畢后，查找數(shù)據(jù)庫從中取出第一個(gè)crawled為0的記錄進(jìn)行爬取，每次只取一條；

　　　　3.存儲電影詳情頁記錄以及短評數(shù)據(jù)都是采用解析一條則立即存儲到數(shù)據(jù)庫。

　　顯然，上面的這種方式是一目了然的效率低下，所以今天下午對相關(guān)代碼進(jìn)行改造，部分實(shí)現(xiàn)了批量插入，盡可能減少與數(shù)據(jù)庫的交互，從而降低時(shí)空成本。

 

　　在git clone完項(xiàng)目后，發(fā)現(xiàn)一個(gè)很詭異的現(xiàn)象，JewelCrawler每次都是爬取種子地址，并沒有一次查詢數(shù)據(jù)庫中crawled字段為0的記錄進(jìn)行一一爬取，但是之前在本機(jī)上是完美運(yùn)行的，可能是在push代碼前做了改動(dòng)影響運(yùn)行了。

既然問題出現(xiàn)了，就順著這個(gè)版本看看，最終發(fā)現(xiàn)問題的原因是對于種子網(wǎng)址并沒有存儲到mysq