스크립트
00:00:00SQS, Kafka и RabbitMQ могут отправляться на свалку, ведь теперь вы можете управлять своими очередями прямо
00:00:05в Postgres с помощью PGMQ. И я уже слышу, как люди говорят, что это не масштабируется.
00:00:11Ну вообще-то масштабируется, потому что Postgres с легкостью справляется с миллионами строк и
00:00:15тысячами запросов в секунду. Так что, если вы хотите сохранить свою инфраструктуру простой,
00:00:20сегодня мы рассмотрим создание высоконагруженных распределенных приложений с помощью PGMQ.
00:00:30Ладно, хватит болтовни, переходим сразу к демо. Я настроил проект
00:00:34с использованием Docker и установил PGMQ. Доступно два варианта: либо только SQL, либо одна из
00:00:41официальных клиентских библиотек, таких как Rust или Python, плюс куча библиотек от сообщества, например Ruby или
00:00:47несколько вариантов TypeScript. Поскольку мы никогда не придем к согласию насчет языка, я запущу это демо
00:00:52только с использованием SQL. Начнем с создания новой очереди. Выполним select pgmq.create и передадим
00:00:58само имя очереди. Каждая очередь здесь представляет собой отдельную таблицу. Если мы посмотрим в базу данных напрямую,
00:01:04то увидим, что появилась новая таблица. Затем мы можем отправлять сообщения в нашу очередь, указав ее имя,
00:01:09а затем само сообщение в формате JSON. Опционально можно указать задержку. Тогда сообщение попадает в
00:01:15очередь, но не может быть обработано, скажем, в течение пяти секунд. Хорошо, теперь сообщения в очереди.
00:01:20Давайте их получим. Это можно сделать с помощью команды read. VT — это время видимости (visibility timeout).
00:01:26Здесь это означает, что прочитанные вами сообщения будут видны в течение 30 секунд, поэтому никакой другой процесс их не подберет.
00:01:31Именно так PGMQ гарантирует доставку ровно один раз. Quantity — это количество сообщений, которые мы хотим
00:01:38прочитать. И если они не будут удалены или помещены в архив за это время, они снова станут видимыми. Чтобы сделать
00:01:44это, вы можете выполнить либо archive, что удаляет сообщение из очереди и добавляет его в архивную таблицу, либо просто
00:01:49запустить delete. Например, здесь я удаляю сообщение с ID 2. И небольшая ремарка: если вы находите это
00:01:54полезным, пожалуйста, сделайте нам огромное одолжение, подписавшись на канал. Это помогает нам продолжать создавать бесплатный контент,
00:01:59чтобы помочь как можно бóльшему количеству разработчиков. Итак, давайте проведем стресс-тест PGMQ. Сначала я добавлю 100 000 строк
00:02:06в очередь. Это занимает примерно 0,4 секунды. Теперь я запущу 100 воркеров, каждый из которых будет обрабатывать задачи
00:02:13пачками по 10 штук, и посмотрим, сколько времени уйдет на чтение всех сообщений. Здесь все, что делает воркер, — это читает
00:02:18сообщение, логирует прочитанное, а затем удаляет его. Конечно, в реальной жизни вы бы делали что-то полезное с этими данными,
00:02:23но сейчас меня интересует тестирование производительности именно PGMQ. И это заняло девять секунд.
00:02:29Каждый воркер обрабатывал в среднем 111 сообщений в секунду, а в сумме — около 11 100 сообщений в секунду.
00:02:37Я специально ограничил Docker-контейнер двумя процессорными ядрами и двумя гигабайтами памяти, что типично для продакшен-сервиса.
00:02:44Теперь, как я упоминал ранее, вы также можете использовать клиентские библиотеки для работы с PGMQ.
00:02:49Используя TypeScript с Prisma, мы можем создать очередь, отправить сообщение, прочитать пачку сообщений, и вы
00:02:55можете сделать то же самое на Python. Так что, если вы не хотите лишних зависимостей, вы действительно можете запускать
00:03:01масштабируемые очереди прямо внутри Postgres с помощью PGMQ. И мы заходим гораздо дальше в замене большей части
00:03:08стека на Postgres, о чем я рассказываю в этом видео.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기