Правильный способ пакетной обработки

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

В момент отправки информационного бюллетеня/счета/сообщения в звонках создаются записи и помечаются как «В очереди». Затем запускается пакетный процесс и отправляет их по 25 за раз.

Каждый информационный бюллетень создается индивидуально и отправляется на стороннюю почтовую службу через http. На переднем конце у меня просто есть страница, которая обновляется каждые 500 миллисекунд.

Письма помечаются как отправленные только после их отправки.



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

Есть ли способ в MySql заблокировать записи на заданный интервал?

Есть ли лучший способ подойти к пакетной обработке?

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

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

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

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

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

https://dev.mysql.com/doc/refman/5.5/en/innodb-locking.html

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

@sarahk Я не эксперт (и ты это знаешь!), но я создал новую колонку (отправленный_электронный адрес) в моей БД, которая обновляется с 1 до 0 после отправки электронного письма. Очевидно, я добавил И send_email = '1' предложение в отправляющей части сценария.

При обновлении отправленные электронные письма не будут отправляться повторно.

Затем я просто запускаю запрос UPDATE SET, чтобы сбросить его обратно на 1 после отправки всех писем. Кроме того, я раньше отправлял пакеты, но совсем недавно я начал отправлять весь шабанг с задержкой в 2-3 секунды (usleep()) между каждым письмом.

Доставляемость довольно высокая.

Возможно, это не лучший вариант для всех, но для меня это ОГРОМНАЯ экономия времени.