Нет (это было бы совсем тупо с их стороны).
Только теперь никак не проконтролировать, учтен ли мой голос.
Я голосую — и ничего не происходит. Счетчик не прибавляется, т.к. там кеширование на минуту. Голос можно просто не учитывать, если за эту минуту был еще хоть один. Проголосовали шестеро — посчитали 1.
В 16:30, примерно. API отмены возвращает статус 200 и 0 байт. Отмены не происходит.
Счетчики теперь работают синхронно (верхний и нижний) и закешированы на минуту.
Сейчас совсем убрали возможность отзывать голоса. Вообще совсем убрали. Раньше можно было отзывать голос в течение двух часов. И была надпись: вы проголосовали так-то, время отзыва истекло.
«Голоса в час» прибавляются при голосовании и вычитаются при отзыве. Если голосовать, держать голос долго, потом отзывать и снова голосовать сразу же, то можно накрутить голоса в час:
Я выше выложил график голосования по их инициативе: habrahabr.ru/post/244753/#comment_8162011
Никакая рассылка не будет работать с такой точностью по времени. Про чиновников тоже были рассылки. Ничего подобного нет в графиках.
Тут сложно. Если самим проверять, то нужно знать алгоритм хеширования. Если знать алгоритм, можно их все перебрать и составить открытый список с фамилиями.
Ok, я понимаю, что архитектура всякая бывает. Но как объяснить совпадение этих интервалов с интервалами отмены голосования без decision_id? Не робот же их отменяет?
Не было сползания. Было резкое изменение, а сейчас снова стабильность.
«Тогда можно из скрипта убрать wait и считать, что он был в какой-то момент остановлен и перезапущен накрутчиком» — вот эта версия мне кажется правдоподобной.
Выполняться сервером РОИ, а не тестовым. Он же обычно чем-то там занимается 300 мс. Маловероятно, что все эти операции хорошо распараллелены и все поступившие запросы будут обработаны в одно и то же время. Напомню, их по 8 за раз бывает. И это несколько запросов к БД, многие из которых на запись.
> к фиксированному трёхминутному ожиданию добавляется сетевой лаг, который со временем аккумулируется
Нет, дело было не так. Не было постепенного сползания. Просто раньше это происходило, условно, в 57 минут 52 секунды, а сейчас — в 58 минут 45 секунд. Я не отследил точный момент, когда это произошло.
Да, но выполняться они будут не одновременно. Я ведь тоже могу запустить какое-то количество GET-запросов на сервер. И, по идее, они должны встать в очередь где-то между этими POST-запросами, даже если те стоят очень плотно.
Вот! Есть ли какие-то готовые наработки по этому вопросу? Я еще очень боюсь, что будет рынок угнанных аккаунтов Госуслуг, как он есть для соцсетей, например. Это тоже нужно как-то учитывать. Понятно, что любая государственная инициатива в вопросах IT катастрофически отстает от прогресса. Нужно самим что-то придумывать.
Третий фронтенд — да, можно придумать что-то суперсложное, чтобы объяснить интервалы. Кеш по диапазонам ip, кеш по знаку зодиака голосующего, склонность к голосованию исключительно в определенное время и в рабочие дни…
Только теперь никак не проконтролировать, учтен ли мой голос.
Я голосую — и ничего не происходит. Счетчик не прибавляется, т.к. там кеширование на минуту. Голос можно просто не учитывать, если за эту минуту был еще хоть один. Проголосовали шестеро — посчитали 1.
Счетчики теперь работают синхронно (верхний и нижний) и закешированы на минуту.
Никакая рассылка не будет работать с такой точностью по времени. Про чиновников тоже были рассылки. Ничего подобного нет в графиках.
Только этот не наш случай по многим причинам.
«Тогда можно из скрипта убрать wait и считать, что он был в какой-то момент остановлен и перезапущен накрутчиком» — вот эта версия мне кажется правдоподобной.
Нет, дело было не так. Не было постепенного сползания. Просто раньше это происходило, условно, в 57 минут 52 секунды, а сейчас — в 58 минут 45 секунд. Я не отследил точный момент, когда это произошло.