Modelli per la creazione di una regolazione adattiva del crawler web

Suggerisco di consultare Zookeeper per aiutarti con questo. Utilizziamo Zookeeper per consentire ai server di coordinarsi tra loro mentre hanno il compito di parlare con i domini.

Pattern funziona come segue:

1. Vengono popolati i nodi permanenti che rappresentano il set di domini Zookeeper.
2. I lavori che interessano tali domini "bloccano" quei domini con nodi effimeri. Puoi sintonizzare quanti lock sono consentiti nel tuo codice, specificando così il numero massimo di utenti concorrenti.
3. È inoltre possibile utilizzare il nodo del corpo stesso per tenere traccia delle singole richieste ai fini della limitazione della velocità in tutto il cluster o specificando la tariffa per ciascun singolo consumatore, a seconda dell'approccio desiderato. Potresti anche utilizzare una ricetta "AtomicLong" (guarda in Curator ) per limitare le dimensioni del download.
4. Quindi si assegnano gli ascoltatori ai nodi rilevanti per consentire la propagazione delle informazioni sullo stato ai consumatori durante l'aggiornamento. L'ordine FIFO è garantito, quindi non è un problema per te.
5. Facoltativamente, puoi propagare ulteriori informazioni sui cluster su un nodo centralizzato e avere un nodo leader (vedi la ricetta Curator 'Elezione di leadership') gestire il controllo di tali informazioni in modo da poter rivedere le prestazioni effettive nel tempo.

Ecco come lo facciamo e funziona come pubblicizzato.

Vorrei suggerire un'architettura che si adatti ragionevolmente bene e funzioni più velocemente dei casi di sonno casuale.

Ogni dominio è associato a una coda di pagine conosciute da scansionare e a due campi aggiuntivi:

1. Il tempo che intercorre tra le richieste per questo dominio.
2. La prima volta in cui è possibile richiedere la pagina successiva.

Ora abbiamo una coda di priorità dei domini. In questa coda, i domini vengono ordinati in base all'orario della richiesta successiva. Questi oggetti di dominio sono unità di lavoro. I thread di lavoro prendono le unità di lavoro dalla coda, con la coda che garantisce che questo sarà il primo dominio in cui verrà effettuata la richiesta successiva. Quando un lavoratore riceve un'unità di lavoro, controlla innanzitutto se il tempo di richiesta specificato si trova in futuro. In tal caso, il thread rimane in sospeso fino a quel momento. In caso contrario, / dopo:

1. La pagina successiva per quel dominio è richiesta ed elaborata. Eventualmente, vengono aggiunte nuove pagine a quel dominio per essere sottoposte a scansione.
2. Se il server richiede una limitazione della velocità, aumenta il tempo tra le richieste per quel dominio.
3. L'unità di lavoro viene restituita alla coda dei lavori e viene richiesto un nuovo lavoro.

Quando la coda dei lavori riceve la proprietà posteriore dell'oggetto dominio, prima controlla se vi sono altre pagine da sottoporre a scansione. In tal caso, viene calcolato il tempo per la richiesta successiva. Potrebbe essere il tempo tra le richieste aggiunte al momento della richiesta precedente o un valore casuale con il tempo minimo o medio.

Questa architettura ha il vantaggio che la proprietà è chiaramente definita, quindi solo un thread sta facendo richieste a un determinato dominio alla volta. Gli svantaggi sono il thread della coda di lavoro che fa molto lavoro e il sovraccarico della comunicazione tra i thread.

C'è un ulteriore punto di cui occuparsi: come si aggiungono le pagine a un dominio che è ancora sconosciuto al sistema o che è attualmente di proprietà di un altro thread? Questo dovrebbe essere gestito dalla coda dei lavori per evitare problemi di concorrenza.

Le prestazioni possono essere aumentate facendo sì che ogni thread di lavoro richieda più pagine contemporaneamente utilizzando operazioni asincrone. In questo modo, il tempo che intercorre tra l'invio di una richiesta HTTP e la ricezione di una risposta può essere utilizzato per lavorare su altre cose.