Одновременная запись в общий сетевой ресурс - PullRequest
0 голосов
/ 28 сентября 2019

Вот контекст проблемы, которую я пытаюсь решить.Есть компьютеры A и B, а также сервер S. Сервер S реализует некоторый бэкэнд, который обрабатывает входящие запросы в режиме RESTful.

Бэкэнд S имеет полку.Цель пользователей A и B - заставить S создавать и размещать пронумерованные коробки на этой полке.Уникальным ограничением является то, что никакие два поля не могут иметь одинаковый номер.Как только блок создан, S должен вернуть этот блок (JSON или xml ...) обратно в A и B. с назначенным им номером.

Проблема сводится к параллелизму, как POST для A и B ("Транзакции create-numbered-box ") могут поступать в базу данных в одно и то же время, поэтому они отменяются (?).Напоминаю, что существует уникальное ограничение: ни одному из двух блоков не разрешено иметь одинаковое число.

Каковы возможные способы решения этой проблемы?Я не хотел бы блокировать базу данных, поэтому я ищу альтернативы этому.Вы можете себе представить, что между базой данных и внутренним уровнем, вызывающим базу данных, у нас может быть дополнительный уровень абстракции, например, микросервис, очередь сообщений ... что угодно или вообще ничего - прямой бэкэнд - db exec.запрос вызова.Если вы считаете, что база данных postgres не является хорошим выбором, чтобы сказать графическую или документальную, ключ-значение - смело заменяйте ее.В конце концов, цель заключается в том, чтобы пользователи A и B одновременно записывали ответы на их запросы на создание (POST), и у каждого из них на этой общей полке был ящик с уникальным номером без «К сожалению, что-то пошло не так. Повторите попытку."тип ответа сервера.

Я описал простой мир с пользователями A и B, но теоретически может написать до 10 000 пользователей, а не только 2. В качестве дополнительного вопроса я хотел бы задатьЕсть ли способ проверить конфликтующие параллельные транзакции в Postgres?

Я пойду первым.Моя идея, пусть A и B отправляют запросы и терпят неудачу.Как только они потерпят неудачу, сделайте попытки со случайными тайм-аутами в некотором интервале.Допустим, до 3 повторов.Таким образом, A и BI будут пытаться разделить запрошенные записи в базу данных, и это обеспечит некоторую степень успешного разрешения сценария.Однако я не думаю, что это чистое решение, и я ищу альтернативы, о которых вы можете подумать.Просто имейте в виду ограничения и свободы, о которых я упоминал выше.

...