AWS Kinesis, processamento simultâneo de Lambda com pedido garantido

Question

Eu tenho um Lambda com uma fonte de evento apontada para um Kinesis Stream Consumer (com um número arbitrário de fragmentos)

Gostaria de garantir que os itens no fluxo com a mesma 'chave de partição' sejam processados ​​pelo Lambda em sequência e não simultaneamente. (Isso está sendo usado como a identidade do objeto, e não quero que vários Lambdas executem lógica no mesmo objeto simultaneamente.)

Por exemplo, se os itens no fluxo tiverem chaves de partição:

1,2,1,3,4,1,2,1

Se considerarmos a ordem de processamento da esquerda para a direita, o Lambda processará um item com cada uma das chaves de partição 1,2, 3 e 4 simultaneamente. Então, quando terminar um item com uma chave de partição específica, ele pode começar a processar outro com essa chave.

Isso é possível de alguma forma, sem o uso de um bloqueio distribuído que tornaria o uso ineficiente do Lambda?

obrigado

Answer 1

Parece que estou lidando com o problema da maneira errada. O Lambda garante que dentro de um fragmento, a instância do Lambda seja chamada em um lote por vez. Portanto, não há necessidade de um bloqueio distribuído, pois, na pior das hipóteses, haverá vários registros pertencentes à mesma entidade no mesmo lote e o processamento deles em ordem pode ser gerenciado na memória dentro da própria função Lambda.

Referência das Perguntas frequentes da AWS http://aws.amazon.com/lambda/faqs/

P: Como o AWS Lambda processa dados de streams Amazon Kinesis e Amazon DynamoDB Streams?

Os registros de Streams do Amazon Kinesis e DynamoDB enviados para sua função AWS Lambda são estritamente serializados, por fragmento. Isso significa que se você colocar dois registros no mesmo fragmento, o Lambda garante que sua função Lambda será chamada com sucesso com o primeiro registro antes de ser chamada com o segundo registro . Se a invocação de um registro atingir o tempo limite, for limitada ou encontrar qualquer outro erro, o Lambda tentará novamente até obter êxito (ou o registro atingir a expiração de 24 horas) antes de passar para o próximo registro. A ordem dos registros em diferentes shards não é garantida e o processamento de cada shard ocorre em paralelo.