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à.

Esegui la migrazione da KCL 2.x a 3.x KCL

Questo argomento fornisce step-by-step istruzioni per migrare il consumatore da KCL 2.x a 3.x. KCL KCL3.x supporta la migrazione in loco dei consumatori 2.x. KCL Puoi continuare a utilizzare i dati del tuo flusso di dati Kinesis mentre migri i tuoi lavoratori in modo continuativo.

Fase 1: prerequisiti

Prima di iniziare a utilizzare KCL 3.x, assicurati di disporre di quanto segue:

Passaggio 2: aggiungere dipendenze

Se utilizzi Maven, aggiungi la seguente dipendenza al tuo file. pom.xml Assicurati di aver sostituito 3.x.x con la versione più recente. KCL

<dependency>
    <groupId>software.amazon.kinesis</groupId>
    <artifactId>amazon-kinesis-client</artifactId>
    <version>3.x.x</version> <!-- Use the latest version -->
</dependency>

Se stai usando Gradle, aggiungi quanto segue al tuo file. build.gradle Assicurati di aver sostituito 3.x.x alla versione più recente. KCL

implementation 'software.amazon.kinesis:amazon-kinesis-client:3.x.x'

Puoi verificare la presenza dell'ultima versione di KCL sul Maven Central Repository.

Passaggio 3: configurare la configurazione relativa alla migrazione

Per migrare da KCL 2.x a KCL 3.x, è necessario impostare il seguente parametro di configurazione:

configsBuilder.coordiantorConfig().clientVersionConfig(ClientVersionConfig.CLIENT_VERSION_CONFIG_COMPLATIBLE_WITH_2X)

Di seguito è riportato un esempio di come impostare la CoordinatorConfig.clientVersionConfig migrazione da KCL 2.x a 3.x. È possibile modificare altre configurazioni in base alle esigenze specifiche:

Scheduler scheduler = new Scheduler(
    configsBuilder.checkpointConfig(),
    configsBuilder.coordiantorConfig().clientVersionConfig(ClientVersionConfig.CLIENT_VERSION_CONFIG_COMPLATIBLE_WITH_2X),
    configsBuilder.leaseManagementConfig(),
    configsBuilder.lifecycleConfig(),
    configsBuilder.metricsConfig(),
    configsBuilder.processorConfig(),
    configsBuilder.retrievalConfig()
);

È importante che tutti i lavoratori dell'applicazione consumer utilizzino lo stesso algoritmo di bilanciamento del carico in un determinato momento, poiché KCL 2.x e 3.x utilizzano algoritmi di bilanciamento del carico diversi. L'utilizzo di lavoratori con algoritmi di bilanciamento del carico diversi può causare una distribuzione del carico non ottimale poiché i due algoritmi funzionano in modo indipendente.

Questa impostazione di compatibilità KCL 2.x consente all'applicazione KCL 3.x di funzionare in una modalità compatibile con KCL 2.x e di utilizzare l'algoritmo di bilanciamento del carico per KCL 2.x fino a quando tutti i worker dell'applicazione consumer non saranno aggiornati alla versione 3.x. KCL Una volta completata la migrazione, KCL passerà automaticamente alla modalità con funzionalità KCL 3.x completa e inizierà a utilizzare un nuovo algoritmo di bilanciamento del carico KCL 3.x per tutti i lavoratori in esecuzione.

Fase 4: Segui le migliori pratiche per l'implementazione del shutdownRequested metodo ()

KCL3.x introduce una funzionalità chiamata graceful lease handoff per ridurre al minimo la rielaborazione dei dati quando un contratto di locazione viene ceduto a un altro lavoratore come parte del processo di riassegnazione del contratto di locazione. Ciò si ottiene selezionando l'ultimo numero di sequenza elaborato nella tabella del leasing prima della cessione del leasing. Per assicurarvi che il grazioso comando di lease funzioni correttamente, dovete assicurarvi di richiamare l'oggetto all'interno del metodo della classe. checkpointer shutdownRequested RecordProcessor Se non state invocando l'checkpointeroggetto all'interno del shutdownRequested metodo, potete implementarlo come illustrato nell'esempio seguente.

/**
 * Invoked when either Scheduler has been requested to gracefully shutdown
 * or lease ownership is being transferred gracefully so the current owner
 * gets one last chance to checkpoint.
 *
 * Checkpoints and logs the data a final time.
 *
 * @param shutdownRequestedInput Provides access to a checkpointer, allowing a record processor to checkpoint
 *                               before the shutdown is completed.
 */
public void shutdownRequested(ShutdownRequestedInput shutdownRequestedInput) {
    try {
       // Ensure that all delivered records are processed 
       // and has been successfully flushed to the downstream before calling 
       // checkpoint
       // If you are performing any asynchronous processing or flushing to
       // downstream, you must wait for its completion before invoking
       // the below checkpoint method.
        log.info("Scheduler is shutting down, checkpointing.");
        shutdownRequestedInput.checkpointer().checkpoint();
    } catch (ShutdownException | InvalidStateException e) {
        log.error("Exception while checkpointing at requested shutdown. Giving up.", e);
    } 
}

Fase 5: Verificare i prerequisiti KCL 3.x per la raccolta delle metriche dei lavoratori

KCL3.x raccoglie metriche di utilizzo, ad esempio CPU l'CPUutilizzo da parte dei lavoratori, per bilanciare il carico tra i lavoratori in modo uniforme. I consumer application worker possono funzionare su Amazon EC2ECS, AmazonEKS, Amazon o AWS Fargate. KCL3.x può raccogliere i parametri di CPU utilizzo dai lavoratori solo quando vengono soddisfatti i seguenti prerequisiti:

Amazon Elastic Compute Cloud(AmazonEC2)

Amazon Elastic Container Service (AmazonECS) su Amazon EC2

Amazon ECS su AWS Fargate

Amazon Elastic Kubernetes Service (Amazon) su Amazon EKS EC2

Amazon EKS su AWS Fargate

Passaggio 6: Aggiornare le autorizzazioni per 3.x IAM KCL

È necessario aggiungere le seguenti autorizzazioni al IAM ruolo o alla politica associati all'applicazione consumer KCL 3.x. Ciò comporta l'aggiornamento della IAM politica esistente utilizzata dall'KCLapplicazione. Per ulteriori informazioni, consulta IAMautorizzazioni necessarie per le applicazioni destinate ai consumatori KCL.

Fase 7: Distribuisci il codice KCL 3.x ai tuoi lavoratori

Dopo aver impostato la configurazione richiesta per la migrazione e completato tutte le liste di controllo sulla migrazione precedenti, puoi creare e distribuire il codice ai tuoi worker.

Fase 8: Completare la migrazione

Durante la distribuzione del codice KCL 3.x, KCL continua a utilizzare l'algoritmo di assegnazione del lease di 2.x. KCL Dopo aver distribuito con successo il codice KCL 3.x a tutti i lavoratori, KCL lo rileva automaticamente e passa al nuovo algoritmo di assegnazione del leasing basato sull'utilizzo delle risorse dei lavoratori. Per ulteriori dettagli sul nuovo algoritmo di assegnazione del leasing, vedere. Come assegna i contratti di locazione ai lavoratori e bilancia il carico KCL

Durante la distribuzione, è possibile monitorare il processo di migrazione emettendo le seguenti metriche a. CloudWatch È possibile monitorare le metriche durante l'operazione. Migration Tutte le metriche sono per-KCL-application metriche e impostate sul livello metrico. SUMMARY Se la Sum statistica della CurrentState:3xWorker metrica corrisponde al numero totale di lavoratori nell'KCLapplicazione, indica che la migrazione alla KCL versione 3.x è stata completata correttamente.

KCLfornisce funzionalità di rollback alla modalità compatibile con 2.x durante la migrazione. Una volta completata la migrazione alla KCL versione 3.x, si consiglia di rimuovere l'CoordinatorConfig.clientVersionConfigimpostazione «CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2Xse il rollback non è più necessario». La rimozione di questa configurazione interrompe l'emissione di metriche relative alla migrazione dall'applicazione. KCL