Обработка очень большой пропускной способности с внешней базой данных

Question

Я собираюсь создать загрузочное приложение Java11 Spring.Приложение должно обрабатывать очень большую пропускную способность (будет иметь пики и низкий трафик)

Счастливый путь приложения выглядит следующим образом.

Концептуально это довольно просто.Шаги выглядят примерно так:

• Принять входящий POST-запрос.Объект DTO в конечной точке сохранения.
• Приложение затем проверит DTO и вернет соответствующее сообщение об ошибке, если оно недействительно.
• Преобразование в объект сущности базы данных
• Сохранение сущности в базе данных Postgres.

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

Мой альтернативный подход выглядит следующим образом

Я надеюсь вернуть статус 200, как только входящий DTO пройдет проверку и будет поставлен в очередьв очереди памяти.
Здесь нет внешней блокировки, и если база данных выйдет из строя - это означает, что внутренняя очередь создаст некоторую избыточность.

Поэтому некоторые вопросы / идеи

• Похоже ли это на хороший подход, есть ли подводные камни, на которые я должен обратить внимание?
• Может быть, вы решили похожую проблему лучше / другим способом?
• Могут ли в любом случае помочь реактивные потоки?
• Какие внутренние библиотеки Java мне следует использовать для этого?Я думал о том, чтобы использовать Java LinkedList Queue<SomeDto> myQ = new LinkedList<SomeDto>(); ) для организации внутренних очередей?

Answer 1

Что произойдет, если в приложении произойдет сбой с данными во внутренней очереди?Или, если в памяти переполнены операции сохранения?

Если вы хотите создать что-то более надежное, вы можете рассмотреть решение журнала событий (например, на основе Kafka), когда потребители заполняют базу данных (Kafkaзамените свою внутреннюю очередь).

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

Я бы посоветовал вам прочитать книгу типа Разработка приложений с интенсивным использованием данных : это, безусловно, ценный ресурс, который поможет вам разработать надежное решение с учетом ваших потребностей и вашего контекста.

Answer 2

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

Хранение данныхупорствовать в памяти - это решение, против которого я бы посоветовал.Вы говорите, что ожидаете относительно высокого пика.Если ваша БД недоступна во время пика, я не могу поверить, что вы сможете поставить в очередь все запросы в памяти в течение необходимого промежутка времени.Если они находятся в памяти, то любой тип сервера приложений (или аппаратная проблема, которая влияет на сервер приложений) может привести к полной потере всех ваших запросов в очереди.Это означает, что ваш интерфейс REST обманул своих абонентов.Вы вернули, что успешно сохранили данные, но не из-за сбоя как вашей БД, так и приложения.

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

Answer 3

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