У меня есть пара указателей на всякий случай.Прежде всего, убедитесь, что ваш лямбда-предел параллелизма на самом деле больше 10. Он должен быть, так как он по умолчанию равен 1000, но это не помешает проверить.
Об объяснениио том, как работают потребители лямбда-потоков, вы можете найти подробности в лямбда-документах .
Одна вещь, которую я часто видел с потоками данных Kinesis, - это проблема с ключом разделения записей,Как вы, вероятно, знаете, Kinesis Data Streams отправит все записи с одним и тем же ключом раздела в один и тот же сегмент , поэтому они могут быть обработаны в правильном порядке.Если записи были отправлены в какой-либо осколок (например, с использованием простого циклического перебора), то у вас не было никакой гарантии, что они будут обработаны по порядку, поскольку разные осколки читаются разными процессорами.
Это важночтобы убедиться, что вы распределяете свои ключи как можно более равномерно.Если большинство записей имеют один и тот же ключ раздела, один из сегментов будет очень занят, в то время как другие не получают трафик.Возможно, вы используете только 10 различных значений для ключей раздела, и в этом случае вы будете отправлять данные только на 10 сегментов, а поскольку выполнение лямбда-функции будет связано только с одним фрагментом, у вас будет только 10 одновременных выполнений..
Вы можете узнать, какой идентификатор шарда вы используете, проверив вывод PutRecord .Вы также можете принудительно установить идентификатор осколка, переопределив механизм хеширования.Дополнительную информацию об обработке ключей разделов и сортировке записей можно получить в Документациях SDK .
. Также обязательно прочитайте Руководство по устранению неполадок , так как иногда вы можете обрабатывать записи.одновременно двумя процессорами, и вы, возможно, захотите быть к этому готовыми.
Я не знаю, будет ли ваша проблема связана с этими указателями, но разделение ключей является постоянной проблемой, поэтому я решил прокомментироватьв теме.Удачи!