Также появилось глобальное хранилище вещей, хотя вы не можете гарантировать, что лямбда не прекратит работу, это не очень хорошая идея.
Правильно -- это вообще нежизнеспособно.Обратите внимание, что когда вы говорите «лямбда», вы имеете в виду процесс внутри контейнера ... и каждый раз, когда ваша лямбда-функция обрабатывает более одного вызова одновременно, вы гарантируете , что они будутне работать в одном и том же контейнере - поэтому «глобальные» переменные полезны только для оптимизации, а не для состояния.Любые два одновременных вызова одной и той же функции имеют две совершенно разные глобальные среды.
Забудем на мгновение все о лямбде - я не говорю, что не используйте лямбду;Я говорю, что то, используете ли вы Lambda, не имеет отношения к остальной части написанного ниже, - я бы сказал, что параллельные / параллельные действия в целом, возможно, являются одним из наиболее важных факторов, которые многие разработчики склонны игнорироватькогда пытаешься создать что-то похожее на то, что ты описываешь.
Чрезвычайно важно рассмотреть, как вы будете назначать работу из этой «очереди».Вы не можете просто «найти следующий элемент» и показать его работнику.
У вас должен быть способ сделать все эти вещи:
- найти следующий элемент, который кажется доступным
- убедиться, что он действительно доступен
- назначить его конкретному работнику
- пометить его как недоступный для назначения
Не только это, но вы должны быть в состоянии сделать все эти вещи атомарно - как одно логическое действие - и без коллизий.
Наивная реализация рискует назначить один и тот же рабочий элемент двум или более людям, при этом первое назначение будет переписано вслепую и незаметно.последующими присвоениями, которые происходят почти в одно и то же время.
DynamoDB позволяет условные обновления - обновлять запись тогда и только тогда, когда определенное условие выполняется.Это критически важная часть функциональности, которую должно обеспечить ваше решение - например, назначить рабочий элемент x пользователю y тогда и только тогда, когда элемент x в настоящее время не назначен. Условное обновление не будет выполнено и ничего не изменится, если условие не выполняется в момент, когда происходит обновление , и в этом заключается сила функции.
S3 не поддерживает условные обновления,потому что, в отличие от DynamoDB, S3 в большинстве случаев работает только на модели конечной согласованности .После того, как объект в S3 обновлен или удален, нет гарантии, что следующий запрос к S3 вернет самую последнюю версию или что S3 не вернет элемент, который был недавно удален.Это не дефект в S3 - это оптимизация, но это делает S3 непригодным для аспекта «рабочая очередь».
Пропустите это соображение, и у вас будет система, которая работает и работает правильно.большую часть времени ... но в других случаях это "таинственно" ведет себя неправильно.
Конечно, если ваши рабочие элементы имеют сопроводительные документы (отсканированные изображения, PDF и т. д.), хранить их совершенно правильноих в S3 ... но S3 - неправильный инструмент для хранения "состояния".Хранилище параметров SSM является неправильным инструментом по той же причине - невозможно, чтобы два действия работали совместно, когда им обоим необходимо одновременно изменить «состояние».
«Триггеры событий»полезный, конечно, но из вашего описания, наиболее заметное «событие» связано не с данными или созданием рабочего элемента, а с тем, что работник говорит: «Я готов к следующему рабочему элементу».В этот момент - запускается кодом веб-сайта / приложения - когда выполняются вышеуказанные шаги, чтобы выбрать элемент и назначить его работнику.(На практике это может быть браузер → API Gateway → Lambda).Из вашего описания может не потребоваться создание нового рабочего элемента для запуска «события», или, если оно есть, оно не является самым значимым среди событий.
Для этого вам понадобится соответствующая база данных.DynamoDB, как и RDS, является кандидатом.
Очереди, предоставляемые SQS, предназначены для разделения двух частей вашего приложения - когда два процесса работают на разных скоростях, SQS используется в качестве буфера, что позволяет X безопасносохраните работу, которую необходимо выполнить, а затем продолжайте с чем-то другим, пока Y не сможет выполнить работу.Очереди SQS непрозрачны - вы не можете сами проанализировать, что находится в очереди, вы просто берете следующее сообщение и отвечаете за его обработку.На первый взгляд это, кажется, частично описывает то, что вам нужно, но не совсем подходит для этого варианта использования.Очереди ограничены в том, как долго сообщения могут быть сохранены, и как только сообщение успешно обработано, оно полностью исчезает.
Обратите также внимание, что SQS соответствует только вашему варианту использования с включенной функцией очереди FIFO, котораягарантирует идеальную доставку по заказу и доставку точно в один прием - стандартные очереди SQS по причинам оптимизации производительности не гарантируют безупречную доставку по заказу и могут при определенных условиях доставлять одно и то же сообщение более одного раза одному и тому же потребителю или другомупотребитель.Но функция очереди SQS FIFO не сосуществует с триггерами событий, для которых требуются стандартные очереди.
Таким образом, SQS может иметь роль, но вам нужна авторитетная база данных для хранения работы и результатов бизнес-процесса.