Допустимо ли использовать AWS SQS в качестве очереди записи в базу данных Aurora для повышения производительности системы?

Я разрабатываю сервер веб-приложений на AWS, который должен поддерживать высокую пропускную способность при чтении и записи. Мой босс дал мне такой высокоуровневый дизайн.

введите здесь описание изображения

Я застрял в "Очереди записи". Команда сказала мне, что нам это нужно для повышения производительности записи, потому что у нас может быть только 1 главная реплика, в которую мы можем писать. У меня есть некоторые базовые знания об очередях сообщений, таких как SQS и RabbitMQ, но я ничего не знаю об использовании их в качестве очереди записи в базу данных.

На данном этапе у меня есть 3 вопроса:

  1. Действительно ли с помощью этой архитектуры можно повысить производительность записи в базу данных (в отличие от записи непосредственно в мастер-реплику).

  2. Как обрабатывать транзакции, особенно как откатывать, когда возникают ошибки при записи. Обычно мы контролируем транзакцию в коде приложения таким образом, что при возникновении ошибки вся транзакция откатывается, а сервер приложений отвечает клиенту с некоторым кодом ошибки.

  3. Я упомянул, что исследовал использование очереди сообщений в качестве очереди записи, но я не уверен, что смотрю в правильном направлении. Может быть, уже есть какая-то другая технология, подходящая для очереди записи в БД?

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


person asinkxcoswt    schedule 12.09.2019    source источник
comment
ИМХО, очередь следует рассматривать/использовать только как буфер, если бывают случаи, когда сама база данных не может легко обрабатывать количество входящих вставок. В конце концов, очередь сможет записать столько, сколько уже может обработать база данных. Вы также можете убедиться, что здесь вам действительно нужна очередь, так как это усложнит логику вашего приложения, а также затруднит отладку.   -  person Tim Biegeleisen    schedule 12.09.2019


Ответы (1)


В подобных случаях очереди используются как средство разделения двух систем. При реализации таких архитектурных шаблонов есть несколько преимуществ и недостатков. Постараюсь перечислить основные, на мой взгляд.

Преимущества

  1. Улучшенное время отклика

    Поскольку очереди не требуют сложных транзакций, они обычно являются быстрым и, при правильной настройке, безопасным хранилищем. Это означает, что предполагаемая задержка ответа со стороны клиента уменьшится, создавая ощущение, что служба работает «быстрее».

  2. Разделение интересов

    Правильное разделение сервисов повышает их устойчивость к ошибкам. Например, если БД не может принимать больше запросов на запись, это не повлияет на клиентов, и их запросы все равно не будут потеряны, поскольку они будут находиться в очереди. Это дает операторам больше времени для реагирования на проблемы, в то время как ценность услуги снижается лишь частично.

  3. Улучшенная масштабируемость

    Когда операции становятся сложными, обычно рекомендуется разделить их на микрокомпоненты. Масштабировать микрокомпоненты гораздо проще, чем монолитные сервисы. Очереди заданий позволяют использовать такие шаблоны проектирования.

Недостатки

  1. Восстановление после ошибок становится более сложным

    Как было сказано выше, если БД перестанет принимать запросы, задания будут накапливаться в очереди. Теперь у вас есть две проблемы: полная БД и полная очередь заданий. Системные проблемы начинают распространяться по вашей архитектуре, как рябь, вызывая несколько побочных эффектов и затрудняя понимание основной причины.

  2. Выявление узких мест требует больше времени

    Если запись в БД идет медленно, установка очереди перед ней не ускорит работу. Задания по-прежнему будут накапливаться в очереди, и вашей следующей задачей будет выяснить, почему это происходит. При работе со сложными конвейерами ETL повышение производительности становится довольно утомительной операцией «ударь по кроту», когда ваши узкие места просто перемещаются от системы к системе.

  3. Стоимость операции увеличивается

    Чем больше этапов нужно пройти работе для ее завершения, тем больше времени и денег потребует эта работа.

Компоненты развязки обычно рассматриваются как серебряная пуля для решения проблем с производительностью. Правильное разделение задач и обязанностей — очень полезная практика, но она требует большого опыта и осторожности. В настоящее время монолитные сервисы рассматриваются как корень всех зол. Лично я предпочитаю иметь дело с монолитной связкой спагетти, а не с распределенной.

person noxdafox    schedule 12.09.2019
comment
Если я использую некоторые очень конкретные примеры, чтобы развить вопрос, как это повлияет на производительность? Итак, пусть очередь будет AWS-SQS, а запись dB будет на MySQL. Имеет ли все же смысл писать в очередь и отдельно иметь другой процесс, пишущий из очереди в дб? Это быстрее, чем писать напрямую в дБ и возвращать ответ обратно во внешний интерфейс? (надеюсь, мой вопрос имел смысл) - person Rohitesh; 20.07.2021