Представьте себе очередь в которой находятся все пользователи. Вы поочередно достаете из очереди пользователя, отправляете ему сособщение, и, если сообщение успешно отправлено, удаляете сообщение из очереди. В терминах AMQP это получение сообщения с подтверждением.
Применительно к вашей задачи: все пользователи, которым необходимо отправить сообщение по рассылке, находятся в некоторой таблице. Вы получете пользователя, отправляете сообщение, удаляете пользователя из этой таблицы. Если что-то пошло не так пользователь не удаляется. В итоге в данной таблице останутся только те пользователи, которым не было отправлено сообщение.
Да, одновременно в данной таблице может находиться большое число пользователей. Но даже количество в 50к не должно создать вам особых проблем, учитывая что ваш процесс не ограничен по времени.
О чем стоит крепко подумать, так это о логировании отправляемых сообщение, и ошибках возникших в процессе.
Но возникают ситуации которые необходимо обработать:
Если в ходе рассылки 100 запросов скрипт сломался, то после перезапуска сообщения будут разосланы пользователям повторно.
Если в ходе рассылки произошла ошибка, необходимо переотправить сообщение.
Клиентский идентификатор и временный токен необходимо получить 1 раз, когда зарегистрируешься. Далее проходите по ссылки и получаете ключ для расшифровки системного ключа. А он то, как я понял общий для всех.
Далее имея системный ключ и любую активационную ссылку можно получить любой пользовательский ключ.
После перехода по линку мы проверяем, что это действительно то устройство и наш пользователь, и присылаем ключ для дешифровки ключа и сохраняем его в браузер (Cookies или LocalStorage).
Если клиентский ключ шифруется серверным ключем, а после перехода по активационной ссылке клиент получает серверный ключ для расшифровки своего ключа, получается что зарегистрировавшись в вашей системе клиент получает ключ, которым зашифрованы все пользовательские ключи в активационных ссылках. Это означает, что любой клиент сможет расшифровать ссылку и получить пользовательский ключ любого клиента.
Вопрос лишь в том, как получить чужую активационную ссылку.
Какой смысл в подобном шифровании пользовательского ключа?
Зачем эти пляски с шифрованием, если вопрос сохранности данных упирается в получение доступа к почте пользователя или перехват активационной ссылки?
Благодарю за развернутый ответ! Буду пробовать! А как можно обойтись без флешки? Создать незашифрованный раздел на ssd, положить туда файлы, и указать этот раздел при конфигурации?
xfg: к сожалению вижу. Поэтому я описал рабочий вариант, не вдаваясь в бессмысленный спор. А автор сам сделает выводы - сейчас или позже. Я тут недавно прочитал вопрос человека, что-то вроде "как начать использовать гит в проекте". И в комменте тот автор писал что программисты не хотят гит, у них и по ftp все хорошо работает. Поэтому я не сильно удивляюсь этому решению. Радует другое - человек ищет решение. Не примет волевое решение изменить флоу сейчас - вернется к вопросу когда будет 6 разрабов, и терпеть эти костыли станет не вмоготу.
Иван Артамонов, master это продакшен ветка, туда попадают только оттестированные фичи. Для описанного вами кейса существуют релизные ветки. Работает это так. У вас в dev 3 фичи, из них одна рабочая. Из dev ветки создается release/1.0. Все новые фичи идет в дев ветву. Разрабы фиксят баги и сливают их в release/1.0. Когда все баги пофикшены, release/1.0 сливается в master и выкатывается на прод. Это стандартный Git Flow. Баги с прода создаются от мастер ветки и сливаются и в master, и в dev. Также нужно после каждого фикса в release/1.0, сливать его в дев. Можно настроить автомердж. Хотите выкатить новую версию - создаете release/1.1 из dev и все по новой
xfg на мой взгляд идея с папками просто жесть. Множество лишних копий, проблемы с линками. А как показывает практика, после мерджа в основную ветку что-то может поломаться. Получается тестерам придется тестить сначала на ветку разраба, потом общую ветку, и только потом выдавать в прод. Иван Артамонов Все намного проще: собираете дев версию на докере(в идеале) или на вагранте. Каждый разработчик получает локальную версию, которою пилит, ломает. И конечно то, что сделал разраб(свою задачу) он должен потестить сам. После чего все поделки через пулл-реквесты сливаются в дев ветку, которую уже тестят тестеры. Если что-то не работает, разрабы выпускаю фиксы. После чего на работоспособную версию ставится тег и она летит в прод. Это минимальны вариант, без всяких CI, CD, автотестирования, и автосборки
Посмотрите как происходит создание заказа в контроллере. Обычно данные прилетают методом POST, а не GET. Вам нужно чтобы данные приходили в контроллер в том же виде и тем же методом, что и при использовании оригинальной формы модуля checkout simple
Применительно к вашей задачи: все пользователи, которым необходимо отправить сообщение по рассылке, находятся в некоторой таблице. Вы получете пользователя, отправляете сообщение, удаляете пользователя из этой таблицы. Если что-то пошло не так пользователь не удаляется. В итоге в данной таблице останутся только те пользователи, которым не было отправлено сообщение.
Да, одновременно в данной таблице может находиться большое число пользователей. Но даже количество в 50к не должно создать вам особых проблем, учитывая что ваш процесс не ограничен по времени.
О чем стоит крепко подумать, так это о логировании отправляемых сообщение, и ошибках возникших в процессе.