AWS SQS + SNS + лямбда


11

Мені було цікаво, чи можу я надіслати повідомлення до черги SQS і підписатись на тему SNS, щоб викликати лямбда для надсилання електронного листа.

SQS -> SNS -> (Lambda) -> SES

Я знаю, що повідомлення SNS можуть надсилатися до SQS, але мені цікаво, чи можливо навпаки

Відповіді:


11

Одне, що я зробив, - створити сигнал CloudWatch ApproximateNumberOfMessagesVisible(( >= 1 for 5 minutes) для черги SQS. Сигналізація публікується до теми SNS, яка запускає функцію лямбда. Функція лямбда петлює, поки не очистить чергу.

Щоб спрацювати з тривоги, може зайняти до 5 хвилин, але це працює фантастично для виконання пакетних завдань, не потребуючи опитування черги. (Сигналізація тривоги становить 5 хвилин для активних черг.)


Я думаю про те, щоб зробити це саме те саме. Чи знаєте ви, якщо вам стягують плату щоразу, коли хмарочос перевіряє вашу чергу? Не те, що ми з цими речами говоримо великі гроші просто цікавіше.
Brian F Leighty

Крім того, я припускаю, що ви говорите, тривога продовжує надсилати SNS тривогу знову і знову? Який час у вашій лямбда-функції встановлено?
Brian F Leighty

Ще одна річ. Вибачте за всі коментарі. Я трохи хвилювався з "Приблизною" частиною: Ви коли-небудь мали час, коли там чекали повідомлення, з яким не розбиралися, оскільки думали, що там замість 1 предмета лише 0 предметів?
Brian F Leighty

@BrianFLeighty чеки безкоштовні. Але це не тривожить постійно; може знадобитися друга тривога для повідомлень, що сидять у черзі (додається між завершенням виконання лямбда та наступним сигналом). Опитування може бути кращим рішенням; шахта працює для типово дуже тихої черги (отже, не варто
опитуватись

Пропущено "приблизний" коментар. Здається, це працює добре, але ymmv
squidpickles

7

Ти не можеш їхати SQS -> SNS, тільки SNS -> SQS.

Тепер Lambda підтримує планування, так що одним із варіантів є впровадження запитувача SQS у функцію Lambda та запуск його часто.

Ще один варіант, який слід врахувати - чи вам справді потрібна черга. Lambda підтримує асинхронну обробку (через режим виклику події) і повинен прозоро масштабувати горизонтально для обробки паралельних викликів. Якщо ваша лямбда-функція не потребує доступу до центрального магазину стану, який може обмежувати паралельне виконання, ви, ймовірно, можете просто запустити всі виклики паралельно. Я вважаю, що існує 100 одночасних лімітів виконання для кожного облікового запису, тому вам може знадобитися згрупувати свої повідомлення, щоб залишатися під цим.


3
також немає нічого поганого в тому, щоб використовувати традиційні трюки для опитування черги з лямбда: наприклад, якщо лямбда видаляє повідомлення під час виконання, потім повторно запускає функцію в кінці; інакше нехай виконується наступне, як було заплановано
nik.shornikov

1

SQSЧерга може бути підписана на SNSтему і так для обробки отриманих SNSповідомлень. В даний час це неможливо здійснити в іншому напрямку без додаткового кодування (див., Наприклад, LambdaFAQ ).

Я б сказав, що існує кілька варіантів, як це зробити, але це не так елегантно, як використання більш поширеної системи, керованої подіями AWS event->SQS->Lambda. Інакше вам може знадобитися налаштувати / реалізувати код, як SQSобробляються черги:

  1. Ви можете реалізувати власні джерела подій
  2. у вас може бути якийсь проміжний екземпляр EC2, щоб слухати SQSчерги та потім запускати Lambdaподії SQS

0

Про це запитували і відповіли деякий час тому, але, лише подумавши про це, я подумав, що додам підхід.

Як уже згадувалося, джерела подій тут можуть бути найкращою ставкою. Крім того, я не перевіряв цього і не задумувався над цим (тому це є начебто академічним), але це можливо зробити за допомогою шаблону вентиляторів з SNS таким чином:

 1. Create a SNS topic.............................: SNS-topic-01
 2. Subscribe a SQS queue to that topic............: SQS-queue-01
 3. Subscribe a Lambda Function to that topic......: LAMBDA-func-01

Використовуючи цю конфігурацію, подання повідомлення в тему SNS призведе до черги SQS, одночасно запустивши функцію Lambda-супутника. Ця функція Lambda була б написана для читання тієї самої черги SQS, але з увімкненим довгим опитуванням (до 20 секунд), щоб вона не читала черги до завершення enqueue (тобто умови гонки).

По суті, ця схема вчасно залучає одну функцію Lambda для кожного інтегрованого повідомлення SQS. Я не знаю, як одночасно працюють читачі Довгого опитування на SQS (... хтось випадає?), Але це лише інший спосіб розглянути це рішення. = :)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.