1. 程式人生 > >分散式爬蟲系統隨筆

分散式爬蟲系統隨筆

此文已在本人個人微信公眾號(iwoods100,不會下廚的健身愛好者不是一個好程式設計師)首發,關注可查閱全部文章。

本文主要記錄一些自己在爬蟲系統中加入分散式設計的開發感想。

背景

本文的爬蟲系統行為是:每隔一段時間就去固定頁面獲取內容更新,而不是去層層挖掘新連結與新內容。

爬蟲系統中存在producer與worker,producer負責排程爬蟲任務,worker消費任務,兩者通過任務佇列解耦。

在以上背景下的爬蟲系統中加入分散式特性。

producer的分散式設計

producer負責載入,定時觸發任務,其穩定性要求非常高,對於單producer的系統,一旦僅存的producer掛了,整個系統就無法正常運轉。

因此理想的producer部署應該是:在多機器上各部署一套producer,每次通過選舉來決定leader,只有leader執行真正的任務分發,一旦當前leader掛掉,則立即從剩餘producer中選舉出新的leader繼續工作。

關於producer的選舉,大致有三個做法:

1.利用資料庫鎖特性來實現,缺點是強耦合資料庫的穩定性,優點是實現最簡單。

2.利用第三方框架提供的穩定鎖機制,如consul,zookeeper等,缺點是部署麻煩。

3.直接在系統內加入選舉功能。

綜合考慮後選擇方案3,在producer中自帶選舉功能,一是部署簡單,而是實現成本也不會太高(開源的分散式一致性協議均自帶選舉功能)。

分散式一致性協議主要指Paxos與Raft協議,後者因為更易理解而被業界廣泛應用,且主流語言均有開源實現。

分散式系統的CAP原則:

C:一致性,指節點間具備資料一致性

A:高可用性,指只要有一個節點正常運轉,系統就能正常運轉

P:分割槽容錯性,指系統中大多數節點正常運轉,系統就能正常運轉

分散式系統中,CAP不可能同時滿足,一個系統最多同時滿足其中兩個,業界通用的選擇是保留CP,但具體問題具體分析,在本文中,如果producer之間沒有資料同步的需求,其實可以捨棄C,保留A,這樣即使系統中只剩下一臺producer是正常的,整個系統也能正常運轉。

不過Raft協議並沒有規範單節點模式下的行為模式,所以需要自己去補充協議,使叢集既能在多節點模式下通過選舉出leader正常執行,也能在單機模式下正常運轉。

worker的分散式

worker分散式則相對簡單得多,每個worker只要支援無狀態特性,即可自由水平擴充套件,在實際應用中,利用docker容器技術,可以很好的結合去實現。

不會下廚的健身愛好者

不是一個好程式設計師

長按二維碼關注