Счётчики: INCR и атомарный рост

Семантика INCR умещается в три факта. Первый: команда увеличивает строковое значение ключа, понятое как целое число, на единицу и возвращает новое значение — вызывающий сразу видит результат и может использовать его как идентификатор, номер окна или условие. Второй: если ключа нет, он считается нулём, и первый INCR вернёт единицу — заводить ключ заранее не нужно, счётчик создаётся сам собой. Третий: атомарность гарантирована архитектурой Redis, который исполняет команды последовательно в одном потоке; две параллельные горутины, два инстанса сервиса и два разных клиента не могут получить один и тот же результат инкремента. В go-redis v9 команда называется Incr, принимает контекст и ключ и возвращает IntCmd — из него методом Result() достаётся int64. Близкие родственники закрывают остальные случаи: IncrBy прибавляет произвольное целое, DecrBy вычитает, IncrByFloat работает с дробями. Отдельно подчеркну тип: значение хранится строкой, но Redis сам парсит её как число — записи вроде 7 или 42 инкрементируются, а вот abc приведёт к ошибке, о ней ниже в врезке.

Атомарность — слово затёртое, поэтому расшифруем механику. Redis исполняет команды строго по одной: сетевой слой вычитывает запросы, ставит их в очередь, и каждый INCR от начала до конца — одна непрерываемая операция чтения-сложения-записи. Именно поэтому вариант «прочитал, прибавил, записал» на стороне Go проигрывает всегда: между тремя вашими шагами чужой INCR уже успел изменить значение, и вы записали поверх него устаревший результат. С INCR промежуточного состояния не существует ни для кого: десять инстансов сервиса, стреляющих по одному ключу, гарантированно получат итог ровно на десять больше. Для сравнения: в чистом Go ту же проблему пришлось бы решать sync.Mutex или атомарными типами — но они работают в пределах одного процесса, а счётчик просмотров живёт в памяти одного пода, когда сервис масштабируется. Распределённый счётчик из нескольких инстансов — это по определению общий внешний источник правды, и Redis здесь самая дешёвая реализация. Если тема синхронизации между процессами знакома по курсу go-advanced — горутины и гонки — здесь вы получаете тот же результат, не написав ни строчки синхронизации.

Суточные счётчики — самый частый запрос после простых просмотров: сколько прочли пост сегодня, сколько запросов за минуту, сколько попыток входа за час. Схема одинакова для всех: ключ содержит окно в своём имени или живёт коротким TTL. Вариант с датой в ключе — views:post:17:2024-05-01 — самозакрывающийся: новый день делает новый ключ, старые умирают по TTL с запасом в сутки-двое, а чистка не требует кода. Вариант с обычным ключом требует TTL, и вот здесь прячется типовая ошибка: вызывать Expire после каждого инкремента нельзя — каждое чтение продлевает срок, и при постоянном трафике ключ живёт вечно, а окно растягивается до бесконечности. Правильный приём: ставить TTL только на первом инкременте, когда INCR вернул единицу — это ровно момент рождения ключа. Альтернатива без условия: SET key 0 EX ttl NX — создать ключ с сроком, если его нет, и потом инкрементировать; NX гарантирует, что TTL не перезапишется. Обе схемы — фундамент лимитеров: в уроке про rate limiter они превратятся в ограничение частоты запросов, а детали работы сроков — в уроке про TTL.

Первый вопрос проектирования: самостоятельный ключ или поле внутри хэша. Одиночный счётчик с собственным жизненным циклом — строковый ключ: views:post:17 инкрементируется, истекает и удаляется независимо, имя само документирует содержимое. Группа счётчиков одного объекта — хэш с HIncrBy: у профиля с лайками, дизлайками и просмотрами общий TTL и общий ключ, и три поля дешевле трёх строк. Второй вопрос — переживание перезапуска: Redis хранит данные в памяти, а на диск сбрасывает снапшотами RDB или журналом AOF. При настройке по умолчанию последний интервал может не дожить до сброса, и счётчик откатится на десятки значений. Для просмотров это безразлично, для биллинга — недопустимо: там счётчик в Redis либо периодически сбрасывается в базу через периодический Get и UPDATE, либо дублируется транзакцией в PostgreSQL. Третий вопрос — история: счётчик с датой в ключе сам себе архив, и за неделю суточных окон уже можно строить графики без отдельного хранилища. Эти решения принимаются до кода — поменять форму ключа на живом трафике дороже, чем выбрать её заранее.