Функции обратного вызова Kinesis Producer - гарантированная доставка? - PullRequest
1 голос
/ 02 марта 2020

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

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

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

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

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

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

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

1 Ответ

1 голос
/ 02 марта 2020

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

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

...