Должен ли я использовать Global ID или найти другое решение для моей системы уведомлений?

Question

Итак, я почти закончил свою систему уведомлений, и непосредственно перед тем, как я собираюсь внедрить reCAPTCHA, я проверяю, что произойдет, если я буду спамить уведомления.

Чтобы дать вам представление о моей системе уведомлений. Я определяю новейший контент по его отметке времени. Я извлекаю строки из базы данных ORDER BY timestamp. Значение метки времени представляет собой целое число, отформатированное в Unix Time . Когда отображаются уведомления, они являются гиперссылками, которые следуют за этим форматом URL -

http://test.com/article/id

Где id - это идентификатор таблицы, каждый раз, когда отправляется новая статья, идентификатор увеличивается. После спама я заметил, что URL-адреса спам-уведомлений расположены в обратном порядке. После дальнейшего изучения я обнаружил, что, если я спам достаточно быстро, переменная отметки времени не является достаточно точной, и записывает несколько представлений с одной и той же отметкой времени.

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

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

Я предложил 3 возможных решения. Мой вопрос, который был бы наиболее эффективным

1. Создайте глобальный идентификатор для всех 4 типов контента, который увеличивается каждый раз, когда создается комментарий, статья или обновление.
2. Используйте более точную функцию времени PHP, такую ​​как microtime
3. Добавить некую вторичную переменную ранжирования

Answer 1

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

Итак, моя первая мысль - использовать глобальную таблицу идентификаторов.Вы можете использовать общую таблицу content с автоинкрементным первичным ключом, в который используется внешний ключ всех других таблиц, и использовать его для упорядочения.

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

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