Как реализовать пользователей сверху на Redis с помощью zsets

Загвоздка в том, как вы определяете «последний час». Гораздо проще сделать это с «часами», а не с «последними 60 минутами». Я объясню, как сделать часы, учитывая их простоту.

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

Когда пользователь закончил свою игру, вы делаете:

Идентификатор пользователя HINCR "таблица лидеров: номер часа"

Это даст вам очки, полученные или потерянные за этот час. Теперь, например, чтобы получить 10 лучших, вам нужно пройти маршрут HGETALL, чтобы вернуть все обратно и выполнить сортировку на стороне клиента.

Чтобы использовать аспект кэширования, вы можете затем сохранить полученные значения пользователей/точек «top X» в ключе (например, сохранить его как JSON), срок действия которого истекает каждые N минут. При этом процесс, отображающий рейтинг, будет извлекать этот ключ и отображать его, если он найден, в противном случае генерировать/сохранять/отображать результат. В качестве альтернативы или в дополнение к вышеперечисленному у вас может быть запланированное задание, которое вычисляет и сохраняет результаты для отображения каждую минуту.

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

Чтобы сделать это с скользящим окном, вы могли бы сделать что-то вроде поминутного хэша, как указано выше, вместо почасового (возможно, таблица лидеров: число минут), а на стороне расчета выяснить, на каком минутном номере вы находитесь прямо сейчас. и выполните HGETALL для предыдущих 60-минутных хэшей в конвейере. Конечно, установите для поминутных хэшей срок действия после 60, чтобы уменьшить использование.

Делая это таким образом, вы вычисляете ключи, а не запрашиваете их.

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

Хорошо, здесь я пытаюсь предоставить другое решение по сравнению с тем, которое предоставил Билл, с недостатками и преимуществами одновременно, чтобы предоставить альтернативу. С этим решением вы получаете:

1. Top N без сортировки на стороне клиента.
2. Роллинг окно.

Однако это немного дороже с точки зрения памяти и вычислений.

Вот как это работает:

1. У вас есть ключ topn, который заполняется ZINCRBY данными в реальном времени. Если мы представим, что будем делать это всегда, произойдет то, что у вас будет не скользящее окно, а «верхнее N за все время», поэтому нам нужно исправить это.
2. Вы также берете дополнительный отсортированный набор, по одному на каждую минуту последних ~ 2 часов (если у него более 1 часа, все должно быть в порядке). Таким образом, каждый раз, когда обновляется оценка пользователя, вы выполняете ZINCRBY для topn, а также для topn_<minute>.
3. У вас есть дополнительный процесс, который делает следующее: для каждой topn_<minute> записи, которая больше не находится в пределах текущих часов, он вычитает свои баллы из topn. Это должно быть возможно с помощью одного вызова ZUNIONSTORE, используя в качестве AGGREGATE "SUM". Важно удалить его (в транзакции) одновременно, поэтому мы уверены, что удалим его один раз.

Поскольку у нас есть только SUM, здесь есть хитрость. На самом деле на шаге "2" вы должны заполнить topn_<minute> инвертированными значениями. Положительный для отрицательных результатов, отрицательный для положительных результатов.

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