Функции обратного вызова Kinesis Producer — гарантированная доставка?

Потоковая передача в Kinesis миллиардов сообщений в день.

Мы ищем реализацию, которая позволила бы нам доставлять сообщения в Kinesis с гарантией ровно один раз.

Наша структура производителя требует, чтобы приемник потоковой передачи был идемпотентным для гарантии однократной доставки, чего Kinesis не обеспечивает. Таким образом, в настоящее время мы получаем по крайней мере один раз доставку. (возможны дубликаты, и мы их видим, когда потоковые микропакеты должны перезапускаться по какой-либо причине на стороне производителя)

Мы начали изучать функции обратного вызова библиотеки Kinesis Producer Library (KPL). По сути, мы будем отслеживать состояние того, какие сообщения были доставлены, а какие нет в DynamoDB, на основе ключа, присутствующего в каждом сообщении. И если мы знаем, что сообщение уже было отправлено, мы пропустим его для повторной попытки доставки. Тогда кажется, что возможен ровно один раз... с двумя проблемами:

1) Единственный вопрос, который у нас есть - насколько вероятно, что мы потеряем вызов функции обратного вызова (например, сбой сети и т. д.), или сама функция обратного вызова не удалась (например, мы столкнулись с ограничением / сбоем DynamoDB и т. д.) - это это где-то задокументировано? Я знаю, что шансы невелики, но мы хотим разработать систему, которая была бы устойчива к некоторым ожидаемым вещам, подобным этим.

2) Сроки. Допустим, если по какой-либо причине Kinesis вызвал callback-функцию с задержкой (5-15 миллисекунд было бы достаточно, чтобы нарушить некоторые допущения в вышеупомянутых callback-функциях, которые сохраняют состояние доставки в DynamoDB). И хотя мы не получили подтверждения о доставке, наша структура потокового производителя предприняла попытку повторной доставки, которая, по ее мнению, еще не была доставлена. Любые обходные пути для этой потенциальной проблемы?

пс. Мы знаем, что один из способов обойти это — выполнить дедупликацию на стороне приложения (получателя из этого потока Kinesis), но это за пределами нашего проекта, и у нас есть жесткое требование — попасть ровно один раз в этот поток Kinesis.




Ответы (1)


Что касается № 1, на любом пути вы окажетесь в крайних случаях, которые могут привести к потере данных или дублированию вызовов. Даже использование двухэтапного протокола фиксации здесь не работает, если потребитель не участие в этом протоколе.

Для № 2 Kinesis упорядочен, поэтому, если вы получаете дубликаты, вы должны быть в состоянии надежно предположить, что они будут в одном и том же сегменте и, следовательно, не будут обработаны, пока другой считыватель все еще обрабатывает (при условии, что один считыватель на сегмент). Просто убедитесь, что вы используете строго согласованное чтение. при вызове DynamoDB.

person Jason Wadsworth    schedule 02.03.2020