Пользователь голосует за отзыв несколько раз: как защитить рейтинг от дублей

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

Повторите один и тот же запрос последовательно и параллельно под одной учетной записью. Проверьте, хранится ли отдельная запись голоса и существует ли уникальность по паре review_id plus voter_id. Не исправляйте только счетчик: сначала определите достоверный источник голосов, затем пересчитайте агрегат.

Что проверить в первую очередь

Начните с одного воспроизводимого сценария. Зафиксируйте точное время, идентификатор объекта, пользователя или операции, версию приложения и последнее известное рабочее состояние. Не меняйте несколько параметров одновременно: один контролируемый шаг должен подтверждать или исключать одну гипотезу. Перед работой с данными и конфигурацией подготовьте резервную копию и проверенный способ отката.

• Проверьте, принимает ли endpoint voter ID из клиента вместо доверенной сессии.
• Найдите таблицу голосов и уникальный составной индекс.
• Сравните число записей голосов с агрегированным likes_count у отзыва.
• Проверьте поведение двойного клика, повторной отправки и двух параллельных запросов.

Почему возникает проблема

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

• API безусловно увеличивает счетчик командой likes_count plus one.
• Проверка существования и вставка выполняются раздельно без транзакции и уникального индекса.
• Анонимный пользователь получает новый идентификатор после очистки cookie или смены устройства.
• Повтор сети после таймаута рассматривается как новый голос.
• Отмена голоса и смена оценки обновляют запись и агрегат в разном порядке.

Пошаговая диагностика

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

• Отправьте одинаковый запрос несколько раз и сравните ответы и строки в базе.
• Запустите два параллельных запроса, чтобы проверить race condition.
• Проверьте SQL schema, индексы и обработку duplicate key.
• Сравните авторизованный, анонимный и заблокированный аккаунт.
• Пересчитайте агрегаты по исходным записям на копии базы и оцените расхождение.

Как хранить голос и счетчик

Источником истины является уникальная запись выбора пользователя, а счетчик — производный агрегат для быстрого чтения. Команда установки состояния надежнее команды безусловного увеличения числа.

• Vote имеет уникальную пару review_id и доверенный voter_id.
• API принимает желаемое состояние helpful true or false и возвращает текущий результат.
• Вставка или обновление выполняется атомарно, а повтор команды не меняет итог.
• Агрегат обновляется в той же транзакции либо периодически сверяется с исходными голосами.

Как исправить проблему

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

• Добавьте составной уникальный индекс и серверное определение пользователя.
• Замените increment endpoint на идемпотентную установку или upsert голоса.
• Обработайте duplicate key как повтор успешной операции, а не как 500.
• Пересчитайте счетчики из таблицы голосов после удаления дублей на резервной копии.
• Ограничьте частоту запросов и добавьте сигналы аномальной активности без блокировки обычных пользователей.

Безопасный порядок внедрения

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

Как проверить результат

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

• Последовательные и параллельные повторы создают только одну запись голоса.
• Отмена и повторная установка корректно меняют итог на единицу.
• Счетчик совпадает с запросом count по исходным записям.
• Пользователь не может проголосовать от имени другого account ID.

Типичные ошибки при исправлении

• Прятать кнопку после клика только средствами JavaScript.
• Считать IP надежным уникальным идентификатором человека.
• Добавлять SELECT before INSERT без уникального ограничения.
• Удалять подозрительные счетчики вручную, не исправив модель хранения.

Как предотвратить повторение

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

• Закрепляйте бизнес-уникальность ограничениями базы, а не только кодом.
• Тестируйте повторные и параллельные запросы для всех счетчиков.
• Регулярно сверяйте агрегаты с исходными событиями.
• Мониторьте резкие серии голосов, новые устройства и несоответствие аудиту.

Что контролировать после выпуска

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

Что подготовить для технического разбора

• Описание ожидаемого и фактического поведения с точной последовательностью действий.
• Время проблемы, идентификатор тестового объекта и версии затронутых компонентов.
• Фрагменты журналов до и после ошибки без секретов и персональных данных.
• Перечень последних изменений и уже выполненных проверок.
• Безопасный доступ к тестовой среде либо способ воспроизвести сбой без влияния на клиентов.

Частые вопросы

Можно ли разрешить анонимные голоса?

Можно, но их уникальность слабее. Нужны ограниченный анонимный идентификатор, rate limit и понимание, что cookie или IP не гарантируют одного человека.

Нужно ли каждый раз считать голоса из таблицы?

Не обязательно. Можно хранить агрегат, если он обновляется атомарно и периодически сверяется с источником истины.

Когда нужна помощь специалиста

Если отзывы или рейтинги накручиваются повторными запросами, я могу проверить API и схему базы, внедрить идемпотентное голосование, исправить счетчики и добавить безопасный антифрод-контроль.