Il modo giusto per l'accodamento di attività ridondanti?

Question

Il modo giusto per l'accodamento di attività ridondanti?

#1 da (0 voti)

0

Attualmente sto lavorando per la refacting di un progetto esistente. Fondamentalmente, ho bisogno di eseguire richieste ai servizi remoti. La soluzione attuale è scrivere le attività su un database e poi interrogarle tramite cron job. Questo approccio crea un carico piuttosto elevato sul database. Sto pensando di utilizzare una coda di attività, come ad esempio Celery, per accodare le richieste e fornire ridondanza in caso di interruzione dei servizi.

La mia preoccupazione è che cosa succede se la coda stessa va giù? L'utilizzo di cron garantisce che l'attività alla fine venga elaborata. E quando una coda di attività è inattiva, tutte le attività vengono perse. Certo, possiamo ancora mantenere le attività nel database, ma ci restituisce il problema del polling.

Quindi, qual è la giusta direzione?

design architecture cron queue

posta mcferden 08.09.2017 - 19:16

fonte

1 risposta

Leggi altre domande sui tag design architecture cron queue

Firma del metodo di aggiornamento in radice aggregata - DDD Aggiornamento del database in Micro-service

score 0 · Accepted Answer

This approach creates quite high load on the database. I'm thinking of using a task queue, like Celery for example, to queue requests and provide redundancy in case of services' downtime.

Questa è una grande idea! Devi togliere il carico dal database.

My concern is what if the queue itself goes down?

Se ciò accade, sei un po 'hosed a meno che tu non abbia un broker con garanzie di persistenza come RabbitMQ, Redis Pub / Sub con il registro append acceso, ecc. Questo non è diverso da se la tua casella che esegue cron decide che la vita è non vale più la pena di vivere per qualsiasi motivo.

The usage of cron guarantees that task will eventually be processed.

A meno che la macchina non si spenga e il disco rigido ritorni all'etere.

And when a task queue is down all tasks are lost.

Non è vero in ogni circostanza, molti sistemi di messaggistica persistono sul disco.

Of course, we can still keep tasks in the database, but it returns us to the problem of polling.

Non usare il tuo database per questo a meno che tu non abbia davvero bisogno di farlo. Usa un archivio dei risultati, registra ogni richiesta che devi fare e riconcilialo con le richieste che fai DID dall'archivio dei risultati.