У меня есть сценарий, где у меня есть таблица DynamoDB с триггером (потоком) для функции AWS Lambda.Могу ли я гарантировать, что триггеры AWS DynamoDB НЕ обрабатываются параллельно функцией AWS Lambda?
Я хочу использовать DynamoDB в качестве хранилища событий и использовать функцию лямбда для поддержания прогнозируемого/совокупного представления/просмотра данных.
мне нужно, чтобы убедиться, что, когда я сохранить CreateEntity
событие в DynamoDB, а затем, возможно, сразу после того, когда я сохранить UpdateEntity
, что функция Lambda будет обрабатывать CreateEntity
событие перед UpdateEntity
событием.
Я понимаю, что параллелизм триггеров для лямбда зависит от количества Осколков, из которых состоит поток DynamoDB. Поэтому, если поток DynamoDB, который использует функция Lambda, имеет 2 осколка и одно событие переходит в Shard1, а другое событие переходит в Shard2, то их можно обрабатывать параллельно двумя экземплярами функции Lambda.
Так что, если CreateEntity
событие на Shard1 и UpdateEntity
на Shard2 тогда, если Shard1 или функция экземпляра Lambda по какой-то причине происходит медленно, то UpdateEntity
событие Shard2 может быть обработан первым. Это означает, что он не может быть добавлен к проекции, потому что сначала не создается сущность.
Правильно ли я понимаю?
Есть ли способ гарантировать, что события обрабатываются только одним экземпляром функции лямбда, чтобы я мог обеспечить упорядочение обработки сообщений?
Или мне нужно использовать что-то еще, чем Лямбда для этого? Например, поток DynamoDB в Kinesis с моим собственным приложением, где я могу гарантировать, что работает только один экземпляр приложения, и обеспечить порядок таким образом.
99% времени времени он работает каждый раз? Таким образом, я могу потерять 1 из 100 событий, так как порядок может быть переключен? Это не совсем то, что я получаю в такой системе. Я хочу построить проекцию событий. Это может быть в конечном итоге последовательным, но оно должно быть правильным. И как это будет обеспечено в моем случае? Я не могу найти ничего о том, как осколок выбирается на основе ключа. – doorstuck
нет. i meam 99% сценариев. поскольку я написал, что единственный случай, когда вы находитесь в 1%, - это когда у вас небольшое количество уникальных объектов, и многие из них, поэтому ваш объект будет разделен на более чем 1 общий. если это ваш случай, так что вы делаете что-то не так –
Чтобы добавить к этому обсуждению и, возможно, помочь пояснить, потоки dynamodb оцифровываются на основе разделов, поэтому все действия над элементами в одном разделе будут в одном и том же порядке. –