История изменений
Исправление vbr, (текущая версия) :
в сообщении незачем указывать никакие id, читатель сам их из базы узнает
id в сообщении служит неявным статусом. Если его там не будет, значит статус должен быть в БД. Ну и нагрузка на БД увеличивается: по id выбрать проще, чем даже по индексу (а если ещё БД дурковать с фуллсканом начнёт…). В целом понятно, помимо прочего читатель может, примеру, минуту ждать сообщения из очереди, а по прошествии минуты сделать селект на всякий случай, хуже не будет.
в чём тут конкретно проблема
Данные сохранились, но дальше обработка не пошла. Грубо говоря - покупатель сделал заказ на сайте, а менеджер про него не узнал.
А если процесс умер не успев ничего записать в базу, то оно тоже потеряется.
Иными словами процесс записи в БД и отправки в очередь предлагается сделать, как одну операцию и отправителю исходного сообщения, которое запустило всю операцию, отправлять HTTP 500 или Connection reset, если процесс умер или что-то подобное произошло. И пускай отправитель ещё раз кнопку тыкает или чего-то подобное делает. А второй раз вставку в БД нужно сделать идемпотентно (ну или вообще забыть про старую запись, считая её мусором и вставить новую копию, хотя этот вариант мне не очень нравится). Разумно, это мне в голову почему-то не пришло. Пожалуй это и есть самый правильный вариант в такой постановке.
Исправление vbr, :
в сообщении незачем указывать никакие id, читатель сам их из базы узнает
id в сообщении служит неявным статусом. Если его там не будет, значит статус должен быть в БД. Ну и нагрузка на БД увеличивается: по id выбрать проще, чем даже по индексу (а если ещё БД дурковать с фуллсканом начнёт…). В целом понятно, помимо прочего читатель может, примеру, минуту ждать сообщения из очереди, а по прошествии минуты сделать селект на всякий случай, хуже не будет.
в чём тут конкретно проблема
Данные сохранились, но дальше обработка не пошла. Грубо говоря - покупатель сделал заказ на сайте, а менеджер про него не узнал.
А если процесс умер не успев ничего записать в базу, то оно тоже потеряется.
Иными словами процесс записи в БД и отправки в очередь предлагается сделать, как одну операцию и отправителю исходного сообщения, которое запустило всю операцию, отправлять HTTP 500 или Connection reset, если процесс умер или что-то подобное произошло. И пускай отправитель ещё раз кнопку тыкает или чего-то подобное делает. А второй раз вставку в БД нужно сделать идемпотентно (ну или вообще забыть про старую запись, считая её мусором и вставить новую копию, хотя этот вариант мне не очень нравится). Разумно, это мне в голову почему-то не пришло. Но всё равно неудобно, идемпотентность и база это гемор.
Исходная версия vbr, :
в сообщении незачем указывать никакие id, читатель сам их из базы узнает
id в сообщении служит неявным статусом. Если его там не будет, значит статус должен быть в БД. Ну и нагрузка на БД увеличивается: по id выбрать проще, чем даже по индексу (а если ещё БД дурковать с фуллсканом начнёт…). В целом понятно, помимо прочего читатель может, примеру, минуту ждать сообщения из очереди, а по прошествии минуты сделать селект на всякий случай, хуже не будет.
в чём тут конкретно проблема
Данные сохранились, но дальше обработка не пошла. Грубо говоря - покупатель сделал заказ на сайте, а менеджер про него не узнал.
А если процесс умер не успев ничего записать в базу, то оно тоже потеряется.
Иными словами процесс записи в БД и отправки в очередь предлагается сделать, как одну операцию и отправителю отправлять Connection reset, если процесс умер или что-то подобное произошло. И пускай отправитель ещё раз кнопку тыкает или чего-то подобное делает. А второй раз вставку в БД нужно сделать идемпотентно (ну или вообще забыть про старую запись, считая её мусором и вставить новую копию, хотя этот вариант мне не очень нравится). Разумно, это мне в голову почему-то не пришло. Но всё равно неудобно, идемпотентность и база это гемор.