Dopo il resharding

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.

In attesa che il flusso diventi nuovamente attivo

Dopo aver chiamato un'operazione di resharding, splitShard o mergeShards, è necessario attendere che il flusso 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" );
}

Routing dei dati, persistenza dei dati e stato dello shard dopo il resharding

Il flusso di dati Kinesis è un servizio di streaming di dati in tempo reale, ovvero le applicazioni devono presumere che i dati scorrono in modo continuo tra le partizioni nel flusso. 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. In altre parole, gli shard padre non scompaiono quando si verifica il resharding. Rimangono con i dati contenuti prima del resharding. I record di dati nelle partizioni principali sono accessibili tramite le operazioni getShardIterator e getRecords nelle API del flusso di dati Kinesis oppure 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 del 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 resharding, uno shard padre è nello stato OPEN, il che significa che i record di dati possono essere sia aggiunti che recuperati dallo shard.

• CLOSED: dopo un'operazione di resharding, lo shard padre passa allo 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: dopo la scadenza del periodo di conservazione del flusso, tutti i record di dati nello shard padre sono scaduti e non sono più accessibili. In questo momento, lo stesso shard passa a uno stato EXPIRED. Le chiamate a getStreamDescription().getShards per enumerare gli shard nel flusso non includono gli shard EXPIRED nell'elenco degli shard restituiti. Per altre informazioni sul periodo di conservazione di un flusso, vedere Modifica del 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 padre che rimangono dopo il resharding potrebbero ancora contenere una quantità di dati non ancora stati letta, che è stata aggiunta al flusso prima del resharding. 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. Se si stanno leggendo i dati utilizzando la Kinesis Client Library, la libreria assicura che i dati verranno ricevuti in ordine, anche se si verifica un ripartizionamento.