此文已在本人個人微信公眾號（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容器技術，可以很好的結合去實現。

不會下廚的健身愛好者

不是一個好程式設計師

長按二維碼關注