Backup dei messaggi in S3 all'interno di una topologia Storm

0

Nel mio progetto stiamo cercando di costruire un KIND-of-a- lambda storm architettura basata. Il componente sarebbe responsabile dell'indicizzazione degli eventi di utilizzo del sito, quindi ci aspettiamo un carico casuale piuttosto massiccio. La soluzione per l'elaborazione dei messaggi in tempo reale sembra soddisfacente, ma parallelamente al "livello di velocità" vogliamo eseguire il backup dei messaggi in forma non elaborata (proprio come stanno scendendo dalla coda) in Amazon S3. Dal momento che scrivere un file per messaggio è ovviamente fuori questione, dobbiamo in qualche modo bufferizzare / aggregare i messaggi prima di postare su S3 - ed è qui che iniziano i problemi. Abbiamo due approcci concomitanti e nessuno sembra perfetto:

  1. Abbiamo usato Redis come buffer. In pratica i messaggi provenienti da una coda (RabbitMQ) vengono memorizzati in buffer in Redis e una volta raggiunta la dimensione di un batch preconfigurato (ad esempio 1000) il buffer viene svuotato e memorizzato in S3. L'intero ciclo di elaborazione dei messaggi non è transazionale. Una volta che il messaggio è stato memorizzato su Redis, viene riconosciuto in coda. Ciò significa che se Redis muore l'intero lotto si perde e questo non è accettabile. Possiamo pensare al cluster Redis per rendere la cosa più a prova di proiettile, ma ... non sembra come andare in un direzione sbagliata?
  2. Il secondo approccio sarebbe utilizzare la Trident Topologia. Cambiare la coda di input in Kafka rende le cose più semplici. Il ciclo di elaborazione dei messaggi può essere transazionale. TUTTAVIA, c'è una parola chiave fastidiosa che continua a essere ripetuta nella documentazione Trident - piccoli lotti - che Trident assume piccoli lotti. Ad esempio TransactionalTridentKafkaSpout raggruppa i messaggi in blocchi di 2 secondi. Questo è troppo poco per noi. Non sono sicuro del motivo per cui i batch dovrebbero essere piccoli, ma se è davvero necessario forse il primo approccio è migliore?

Quale di questi è meglio? Forse a somoeone sarebbe venuta in mente una "terza" idea?

    
posta macias 01.04.2014 - 23:31
fonte

1 risposta

1

La mia confusione è stata in realtà causata dal non aver ben compreso il concetto di pubblicazione / sottoscrizione MQ di Rabbit MQ. La soluzione è: crea due code in RabbitMQ (esegui il bind di uno scambio). Una coda sarà per l'elaborazione in tempo reale, la seconda per l'elaborazione in batch. Ora il livello batch non dovrebbe essere affatto un temporale, dovrebbe invece essere un processo pianificato che si riattiva periodicamente e raccoglie tutti i messaggi che sono stati accodati nel frattempo.

    
risposta data 03.04.2014 - 22:50
fonte

Leggi altre domande sui tag