Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Completa l'azione di ripartizionamento
Dopo qualsiasi tipo di procedura di ripartizionamento in Flusso di dati Amazon Kinesis e prima della ripresa dell'elaborazione record normale, sono necessarie altre procedure e considerazioni. Le sezioni seguenti descrivono queste procedure.
Argomenti
Attendi che uno stream torni ad essere attivo
Dopo aver chiamato un'operazione di resharding, splitShard
omergeShards
, devi attendere che lo stream diventi nuovamente attivo. Il codice da usare è lo stesso di quando si attende che il flusso diventi attivo dopo la creazione di un flusso. Il codice è il seguente:
DescribeStreamRequest describeStreamRequest = new DescribeStreamRequest(); describeStreamRequest.setStreamName( myStreamName ); long startTime = System.currentTimeMillis(); long endTime = startTime + ( 10 * 60 * 1000 ); while ( System.currentTimeMillis() < endTime ) { try { Thread.sleep(20 * 1000); } catch ( Exception e ) {} try { DescribeStreamResult describeStreamResponse = client.describeStream( describeStreamRequest ); String streamStatus = describeStreamResponse.getStreamDescription().getStreamStatus(); if ( streamStatus.equals( "ACTIVE" ) ) { break; } // // sleep for one second // try { Thread.sleep( 1000 ); } catch ( Exception e ) {} } catch ( ResourceNotFoundException e ) {} } if ( System.currentTimeMillis() >= endTime ) { throw new RuntimeException( "Stream " + myStreamName + " never went active" ); }
Prendi in considerazione il routing dei dati, la persistenza dei dati e lo stato dello shard dopo una reshard
Kinesis Data Streams è un servizio di streaming di dati in tempo reale. Le tue applicazioni devono presupporre che i dati fluiscano continuamente attraverso gli shard del tuo stream. Quando si esegue il resharding, i record di dati che scorrevano verso gli shard padre vengono instradati agli shard figlio in base ai valori chiave hash che sono mappati dalle chiavi di partizione del record di dati. Tuttavia, qualsiasi record di dati presente negli shard padre prima del resharding rimane in tali shard. Gli shard principali non scompaiono quando si verifica un nuovo shard. Rimangono con i dati contenuti prima del resharding. I record di dati negli shard principali sono accessibili utilizzando le getRecords
operazioni getShardIteratorand in Kinesis Data API Streams o tramite la Kinesis Client Library.
Nota
I record di dati sono accessibili dal momento in cui sono stati aggiunti al flusso fino al periodo di conservazione attuale. Questo vale indipendentemente da eventuali modifiche apportate agli shard nel flusso durante tale periodo di tempo. Per altre informazioni sul periodo di conservazione di un flusso, vedere Modifica il periodo di conservazione dei dati.
Nel processo di resharding, uno shard padre passa dallo stato OPEN
allo stato CLOSED
allo stato EXPIRED
.
-
OPEN: Prima di un'operazione di reshard, uno shard principale è nello
OPEN
stato, il che significa che i record di dati possono essere sia aggiunti allo shard che recuperati dallo shard. -
CLOSED: Dopo un'operazione di reshard, lo shard principale passa a uno stato.
CLOSED
Ciò significa che i record di dati non sono più aggiunti allo shard. I record di dati che dovevano essere aggiunti a questo shard sono ora aggiunti allo shard figlio. Tuttavia, i record di dati possono essere ancora recuperati dallo shard per un periodo di tempo limitato. -
EXPIRED: Una volta scaduto il periodo di conservazione dello stream, tutti i record di dati nello shard principale sono scaduti e non sono più accessibili. In questo momento, lo stesso shard passa a uno stato
EXPIRED
. Le chiamate agetStreamDescription().getShards
per enumerare gli shard nel flusso non includono gli shardEXPIRED
nell'elenco degli shard restituiti. Per altre informazioni sul periodo di conservazione di un flusso, vedere Modifica il periodo di conservazione dei dati.
Dopo che è stato eseguito il resharding e il flusso è nuovamente nello stato ACTIVE
, è possibile iniziare immediatamente a leggere i dati dagli shard figlio. Tuttavia, gli shard principali che rimangono dopo il reshard potrebbero ancora contenere dati che non hai ancora letto e che sono stati aggiunti allo stream prima del reshard. Se si leggono i dati dagli shard figlio prima di aver letto tutti i dati dagli shard padre, è possibile leggere i dati per una determinata chiave hash che non rientra nell'ordine fornito dai numeri di sequenza dei record di dati. Pertanto, presupponendo che l'ordine dei dati è importante, è necessario, dopo il resharding, continuare sempre a leggere i dati dagli shard padre finché non è scaduto. Solo dopo si può iniziare a leggere i dati dagli shard figlio. Quando getRecordsResult.getNextShardIterator
restituisce null
, indica che sono stati letti tutti i dati nello shard padre.