Я сделал это, вероятно, 5 разными способами для разных проектов, над которыми я работал с различными требованиями. Самый простой способ - смоделировать разрыв между производителем / потребителем (основываясь на показателях того, сколько элементов в очереди / насколько далеко отстает «текущий» в потоке), и отрегулировать поведение либо производителя, либо потребителя на основе значения этого показателя ( автоматически масштабировать потребителей, или производить другой тип или меньше предметов). Если вы можете описать поведение, вы можете смоделировать и кодировать его.
ичок в распределенной потоковой обработке (Spark). Я прочитал некоторые учебные пособия / примеры, в которых рассказывается о том, как обратное давление приводит к замедлению работы производителя (ов) в ответ на перегрузку потребителей. Классический пример, приведенный здесь, - это принятие и анализ твитов. Когда происходит неожиданный всплеск трафика, из-за которого потребители не могут справиться с нагрузкой, они применяют противодавление, и производитель реагирует, снижая его скорость.
Что я действительно не вижу, так это то, какие подходы используются на практике для обработки огромного количества входящих данных в реальном времени, которые не могут быть немедленно обработаны из-за меньшей емкости всего конвейера?
Я думаю, что ответ на этот вопрос зависит от сферы бизнеса. Для некоторых проблем было бы хорошо просто отбросить эти данные, но в этом вопросе я хотел бы сосредоточиться на случае, когда мы не хотим потерять какие-либо данные.
Поскольку я буду работать в среде AWS, моей первой мыслью было бы «буферизовать» лишние данные в очереди SQS или потоке Kinesis. Это так просто на практике, или это более стандартное потоковое решение этой проблемы (возможно, как часть самой Spark)?