Invia più tipi di record a un singolo stream Kinesis o no?

0

Abbiamo un sacco di servizi che utilizzano AWS Kinesis per comunicare tramite eventi. Abbiamo eventi diversi come MasterDataUpdatedEvent , PriceUpdatedEvent o AvailabilityChangedEvent .

Attualmente stiamo utilizzando un flusso dedicato per evento:

  • MasterDataUpdatedEvent s vai a master-data-updated-event-stream
  • PriceUpdatedEvent s vai a price-updated-event-stream
  • AvailabilityChangedEvent s vai a availability-changed-event-stream

Quindi sappiamo esattamente cosa c'è in ogni flusso. Tuttavia, la configurazione è un grosso problema e alla fine ci saranno molti più eventi.

Esistono buone pratiche per questo caso? Sarebbe "OK" inviare tutto ad un singolo flusso?

    
posta Thomas Uhrig 20.04.2018 - 15:06
fonte

1 risposta

2

Dipende da come i tuoi consumatori elaborano i flussi.

Ogni consumatore elabora ogni tipo di evento, indipendentemente

Questo potrebbe essere un tipico flusso di registrazione: ti interessa che gli eventi accadano, ma non stai eseguendo alcuna elaborazione che deve esaminare più eventi.

In questo caso, la combinazione dei flussi ha senso: hai un singolo lettore per utente e salva gli offset dopo ogni evento o gruppo di eventi.

Un consumatore utilizza solo un singolo tipo di evento e deve eseguire alcune elaborazioni su gruppi di eventi

Questo potrebbe essere il caso in cui stai usando eventi per popolare i database downstream. Per efficienza, ti consigliamo di raccogliere più eventi per un singolo aggiornamento e potresti dover ridurre gli eventi in qualche modo (ad esempio, potresti avere più eventi per un prodotto, ma preoccuparti solo degli ultimi).

In questo caso i flussi separati hanno più senso. potresti scrivere ai tuoi utenti semplicemente per scartare eventi a cui non interessa. Tuttavia, hai una larghezza di banda fissa per letture: 5 transazioni o 2 MB al secondo per frammento. È davvero facile utilizzare questa larghezza di banda solo con i consumatori che si interessano a tutti i record; scartare i record potrebbe rendere il tuo sistema inaccettabilmente lento (o potrebbe spingerti verso implementazioni fan-out, che troverebbero ancora più complesse da gestire).

Un consumatore consuma più tipi di eventi, in lotti

Questo caso è simile al precedente, ma presuppone una sorta di interrelazione tra i tipi di evento. Ad esempio, vuoi combinare diversi tipi di eventi in una singola transazione.

In questo caso potrebbe essere opportuno combinare gli stream e fare affidamento sui dati correlati scritti insieme. In pratica, è troppo facile che i frammenti non vadano sincronizzati, il che significa che si sta effettuando il buffering dei dati e si hanno lunghe attese per salvare gli offset. In questo caso penso che Kinesis sia probabilmente la soluzione sbagliata.

    
risposta data 22.04.2018 - 17:16
fonte

Leggi altre domande sui tag