Вот почему брат первый89оригинальная статья

Два дня назад читатель прислал мне фотографию.

Я спросил: что случилось с почкой?

Так вот такой разговор:

Картинка, которую он прислал, является скриншотом рейтинга спортивной ступени WeChat:

На самом деле, после стольких событий это обычный вопрос на сцене интервью: как создать таблицу лидеров?

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

Конечно, если вы занимались ранжированием в реальном бизнесе, то этот вопрос прямо у вас в сердце, и смеяться вслух не стоит, интервьюер даст вам время подумать.

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

Затем немного организуйте язык и скажите это.

В этой статье я предложу вам проанализировать вопрос сцены «Список рейтингов» и то, как это сделать.

на основе базы данных

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

Потому что, когда я думаю о «таблице лидеров», я думаю о порядке.

Когда я думаю об упорядочении, я думаю о базе данных.

Когда я думаю о базах данных...

Брат, твой путь узок.

Хотя раньше я делал таблицу лидеров на основе MySQL, поскольку это был временный сервис для соревнований, Redis вообще не вводился. Я оценил время, необходимое для создания Redis, по сравнению со временем, которое потребовалось для разработки непосредственно с MySQL.

Поэтому я выбрал MySQL.

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

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

Затем интерфейс возвращает следующие данные на страницу внешнего интерфейса, и все эти данные находятся в одной таблице:

• Команды ранжируются по наивысшему результату в истории.
• Название команды
• Самый высокий балл в истории
• оценка последней фиксации
• Время последней фиксации

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

Видите ли, таблицы лидеров действительно можно создавать с помощью MySQL.

Вам не обязательно использовать Redis, запомните одно предложение:Дизайны, выходящие за рамки бизнес-сценариев, — все хулиганы.

Но это то же самое, что и «все является объектом», не говорите интервьюеру, это не должен быть ответ, который хочет услышать интервьюер.

Или это только часть ответа, который вы хотите услышать.

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

Даже если мы не используем сортировку MySQL, мы можем узнать данные и отсортировать их в памяти.

Однако, если это игровой рейтинг, с увеличением количества игроков и достижением уровня в десятки миллионов пользователей, это решение точно не сработает.

Конечно, может быть, вы можете дать мне решение для добавления индекса, если запрос медленный, и подбазы данных и подтаблицы, если объем данных велик.

Во всяком случае, приведенное выше предложение не является неправильным.

Но как только объем данных увеличивается, это решение на самом деле не является особенно хорошим решением.

Эту проблему нужно решать с корнем.

На основе Редис

Этот сценарий на самом деле проверяет ваше мастерство работы со структурой данных Redis с отсортированным набором.

Сортированный набор, как известно из названия, означает упорядоченный набор.

В Redis это выглядит так:

Предыдущий sport:ranking:20210227 является ключевым в Redis.

value является набором, и видно, что этот набор упорядочен. Каждый элемент в коллекции имеет оценку и сортируется в порядке убывания в соответствии с этой оценкой.

Стоит отметить, что счет/член на картинке написан мною не случайно, а определяется на официальном сайте следующим образом:

https://redis.io/commands/zadd#sorted-sets-101

А на официальном сайте написано: пары очков/участников.

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

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

Это легко понять, например, количество шагов в WeChat на день 20210227, я могу сделать 6666 шагов, и вы тоже можете сделать 6666 шагов.Это не конфликт:

Однако возникает вопрос: когда оценки членов одинаковы, как сортируются члены?

Взгляните на ответ с официального сайта:

Когда несколько элементов имеют одинаковую оценку, они сортируются лексикографически.

Ой, не знаю слова лексикографически.

Не паникуйте, вы знаете, почему брат также преподает английский на полставки:

Когда оценки одинаковы, они сортируются лексикографически., так что на приведенной выше схеме сойка стоит перед почему .

Далее взгляните на функции работы с отсортированными наборами, всего их 32:

Я не буду здесь учить API по одному, на официальном сайте это очень понятно написано, если вы не знакомы с командами, то можете зайти на официальный сайт и посмотреть их, там есть примеры кодов.

https://redis.io/commands/zadd#sorted-sets-101

Например, этот метод ZADD:

Для плавного продвижения обмена позже я расскажу только о нескольких операциях, которые необходимо использовать:

• Формат команды добавления участника: zadd key score member [score member ...]
• Увеличить счет участника Формат команды: приращение члена с помощью ключа цинка.
• Получить формат команды ранжирования участников: ключевой член zrank/zrevrank
• Возвращает участников в указанном диапазоне ранжирования. Формат команды: zrange/zrevrange key start end [withscores]

Посмотрите на первый: добавить члена.

Например, когда мы добавляем данные на схематическом представлении в упорядоченный набор, синтаксис выглядит следующим образом:

• zadd key score member [score member ...]

Это означает, что за один раз можно добавить одну или несколько пар элементов счета, например, следующие две команды:

• zadd sport:ranking:20210227 10026 why
• zadd sport:ranking:20210227 10158 mx 30169 les 48858 skr 66079 jay

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

Я использую инструмент визуализации RDM, который специализируется на работе с Redis, для просмотра вставленных данных, что почти совпадает с диаграммой, которую я нарисовал сам:

Затем посмотрите на второй: увеличьте счет члена

Данные спортивного рейтинга WeChat обновляются в режиме реального времени.

Текущее количество шагов с членом, почему 10268. Предположим, я выхожу на пробежку после обеда и пробегаю еще 5000 шагов.

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

• zincrby key increment member

Команда выполнения, соответствующая приведенному выше сценарию, выглядит следующим образом:

• zincrby sport:ranking:20210227 5000 why

После завершения выполнения будет возвращено количество шагов почему, и вы можете видеть, что оно изменилось с 10026 до 15026:

При этом из-за увеличения количества моих шагов, согласно обратному порядку начисления очков, это также привело к изменению сортировки:

Так что нам просто нужно обновить счет, а изменение рейтинга поможет сделать Redis.

Затем посмотрите на третью команду: получить рейтинг участников.

Синтаксис таков:

• Получить рейтинг участников: ключевой участник zrank
• Получить статус участника: ключевой член zrevrank

Во-первых, рейтинг рассчитывается от 0.

zrank возвращает рейтинг участников в соответствии с количеством баллов от низкого к высокому.

zrevrank возвращает рейтинг участников в соответствии с количеством баллов от высокого к низкому.

Например, чтобы сейчас получить ранг сойки, результат, возвращаемый zrank, равен 4.

• zrank sport:ranking:20210227 jay

При использовании zrevrank ранг Джея равен 0:

• zrevrank sport:ranking:20210227 jay

Следовательно, в этом требовании ранжирования количества шагов WeChat, чем больше шагов, тем выше рейтинг, мы должны использовать zrevrank.

Четвертая команда, которую нужно освоить: вернуть участников в указанный диапазон ранжирования.

• zrange/zrevrange key start end [withscores] Возвращает участников в указанном диапазоне ранжирования

Эта команда очень важна.

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

zrevrange должен возвращать элементы в указанном диапазоне ранжирования в соответствии с оценкой от высокого к низкому.

Здесь я только демонстрирую команду zrevrange.

Например, если я хочу получить трех лучших участников по шагам:

• zrevrange sport:ranking:20210227 0 2

Эта команда имеет необязательный параметр: withscores

Когда этот параметр включен, будет возвращена оценка соответствующего члена:

Думаете, это ли не сцена топ-N таблицы лидеров?

Предположим, я хочу сейчас получить рейтинг всех пользователей, как это написать?

следующее:

• zrevrange sport:ranking:20210227 0 -1

Это текущий рейтинг шагов WeChat, у jay больше всего шагов, а у mx меньше всего шагов.

Эй, что происходит, таблицы лидеров уже давно нет?

Подумайте об этом, после разговора о нескольких операциях API кажется, что функция реализована?

Да, это действительно так, даже нам нужны только эти два API для выполнения требований таблицы лидеров:

• zadd ключевой член счета [член счета ...] добавить члена
• zrange/zrevrange key start end [withscores] Возвращает участников в указанном диапазоне ранжирования

Ну а если понравилось, всем спасибо за один клик и три ссылки. Эта статья здесь...

Это невозможно.

Какая скучная статья про API.

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

Но фронт — это только предзнаменование, а дальше хорошая драма только началась.

Взгляните еще раз на списки лидеров

Есть проблема с приведенным выше рейтингом подсчета шагов WeChat, вы ее нашли?

Что касается приведенного выше сценария, то все видят такой порядок:

Реальная ситуация такова, что данные ранжирования данных, которые все видят, исходят от их друзей в WeChat, а друзья в WeChat разные, поэтому рейтинги, которые они видят, тоже разные.

Эту особенность мы не отражали.

Наш вышеприведенный сценарий больше похож на таблицу лидеров игры, и все видят одну и ту же таблицу лидеров сервера.

Так как же нам убедиться, что каждый из нас видит по-своему?

Подумайте об этом, как вы должны подойти к этой проблеме?

Если ключи отсортированных наборов различны, получаются разные наборы значений.

Наш текущий ключ — это sport:ranking:20210227, который содержит информацию только за определенный день.

Пока мы добавляем атрибуты пользователя к ключу, скажем, почему моя учетная запись WeChat.

Тогда ключ можно оформить как спорт:рейтинг:почему:20210227.

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

Соответствующие команды выглядят следующим образом:

• zadd sport:ranking:why:20210227 10026 why 10158 mx 30169 les 48858 skr 66079 jay
• zadd sport:Ranking:mx:20210227 7688 Zhao Si 9688 Liu Neng 10026 почему 10158 mx 54367 Big Feet

Что, почему, и mx видят рейтинг их друзей по шагам в WeChat в определенный день.

Пока ключ хорошо разработан, эта проблема будет решена.

Но если хорошенько подумать, так ли легко ее решить?

Этот вопрос, я, возможно, был ослеплен салом, когда писал первое издание, но я этого не осознавал.

Есть привкус «только из-за того, что я на этой горе», и я думаю о Redis.

Вы думаете, что если у каждого пользователя есть своя таблица лидеров в Redis, когда обновляется счет пользователя, необходимо обновить zset всех друзей Какая цена, верно?

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

Redis может это сделать, но это не лучшее решение.

Так каков план сделать это?

Позвольте мне дать вам идею:

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

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

Так что лучше отложить до стадии обращения пользователя.

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

Давайте подумаем о конкретном плане.

Кроме того, еще одно слово, разве WeChat не поддерживал модификацию учетной записи WeChat некоторое время назад, что вызвало много аплодисментов.

На самом деле, я серьезно задумался в то время, насколько сложно реализовать это требование технически.

Я не знаю, есть ли в этом исторический технический долг.

Но давайте просто скажем, что в текущем сценарии ключ содержит идентификатор WeChat. Обратите внимание, что это идентификатор WeChat, а не псевдоним WeChat.

Потому что в начале разработки на упаковке продукта было сказано: будьте уверены, учетная запись WeChat абсолютно уникальна в глобальном масштабе, и после ее определения ее нельзя будет изменить.

В результате, теперь он собирается измениться.

Продукт сказал: «Мне все равно, как этого добиться. Это требование очень популярно у пользователей, поэтому поторопитесь и выходите в интернет».

Вы говорите, насколько велико влияние этих подобных сценариев?

На самом деле влияние не особенно большое, только изменение поля.

Однако у WeChat 1,4 миллиарда пользователей.

Простое требование, после включения этого тома всего в одно предложение:

Количественные изменения ведут к качественным изменениям.

Ладно, ладно, подальше. Скажи это снова.

Когда я снова взглянул на рейтинги WeChat, я обнаружил, что просто дал кастрированную версию рейтингов.

Да, теперь мы можем понять, почему текущее количество шагов равно 1680, а текущее ранжирование — 814.

Например, приведенный выше пример все еще используется, предполагая, что я хочу получить рейтинг шагов WeChat моего друга Джея.

Сначала получите рейтинг Джея:

• zrevrank sport:ranking:why:20210227 jay

Ранг равен 0, и программа может добавить к нему единицу. Это номер один.

Тогда получите шаги Джея сегодня:

• zscore sport:ranking:why:20210227 jay

66079, количество шагов тоже есть.

Теперь мы знаем: почему друг Джей прошел сегодня 66079 шагов, заняв первое место среди друзей почему в WeChat.

Но если присмотреться, я тоже пропустил два поля:

• аватар
• Друзья лайкают

Как должны быть расположены два поля?

Конечно, вы можете поместить его в базу данных, но мы в основном говорим о решении Redis.

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

Вы сказали, какую структуру данных использует Redis для хранения?

Но разве вам не нужно использовать структуру Hash?

Структура хеша также включает в себя ключ и значение, так что же это такое?

Ключ — это ключ нашего заказанного набора, за которым следует никнейм друга, например:

Соответствующая команда выглядит следующим образом:

• hmset sport:ranking:why:20210227:jay nickName jay headPhoto xxx likeNum 520 walkNum 66079

После завершения выполнения в RDM это выглядит так:

Когда лайков в будущем будет больше, нужно вызвать команду update для обновления likeNum:

• hincrby sport:ranking:why:20210227:jay likeNum 500

После завершения выполнения количество лайков станет 1020:

Таким образом, мы можем получить все поля в таблице лидеров, и таблица лидеров WeChat готова.

Эм-м-м......

Как вы относитесь к преподаванию API?

Неплохо, возьми еще.

Как получить рейтинг за последние семь дней?

Ранее мы говорили о ежедневных таблицах лидеров.

Предположим, интервьюер просит нас предоставить список за последние семь дней, прошлую неделю, прошлый месяц, прошлый квартал, этот год и т. д. Что нам делать?

На самом деле, это все еще проверка вашего мастерства в API отсортированных наборов Redis.

Вот этот API:

• zinterstore/zunionstore назначение numkeys ключ [ключ ...] [вес вес [вес ...]] [суммарная сумма|минимум|максимум] Получить пересечение/объединение

Этот API выглядит немного сложным, не бойтесь, по порядку:

• Zinterstore/zunionstore на самом деле является пересечением/объединением
• назначение сохраняет результат пересечения/объединения в этот ключ
• numkeys Количество наборов, которые необходимо пересечь/объединить
• ключ [ключ ...] Набор, который конкретно участвует в пересечении/объединении
• weights weight [вес ...] Вес каждого набора, участвующего в расчете. При вычислении пересечения/объединения участники в каждом наборе будут умножать свои баллы на этот вес, который по умолчанию равен 1.
• совокупность sum|min|max представляет собой сумму (суммирование), min (минимальное значение) или max (максимальное значение) для одних и тех же элементов в каждом наборе, по умолчанию используется сумма.

Возьмем в качестве примера последние семь дней, давайте просто добавим некоторые данные, вы можете просто вставить их и воспроизвести:

• zadd sport:ranking:why:20210222 43243 why 2341 mx 8764 les 42321 skr
• zadd sport:ranking:why:20210223 57632 why 24354 mx 4231 les 43512 skr 5341 jay
• zadd sport:ranking:why:20210224 10026 why 12344 mx 54312 les 34531 skr 43512 jay
• zadd sport:ranking:why:20210225 54312 why 32451 mx 23412 les 21341 skr 56321 jay
• zadd sport:ranking:why:20210226 3212 why 63421 mx 53652 les 45621 skr 5723 jay
• zadd sport:ranking:why:20210227 5462 why 10158 mx 30169 les 48858 skr 66079 jay
• zadd sport:ranking:why:20210228 43553 why 4451 mx 7431 les 9563 skr 8232 jay

Вы можете видеть, что у нас есть данные за 7 дней:

И надо отметить, что у 20210222 нет данных о сойке в этот день.

Теперь мы запрашиваем список рейтинга за последние 7 дней, просто используйте следующую команду Команда немного сложна, но, глядя на формат команды, она все еще очень ясна:

• zunionstore sport:ranking:why:last_seven_day 7 sport:ranking:why:20210222 sport:ranking:why:20210223 sport:ranking:why:20210224 sport:ranking:why:20210225 sport:ranking:why:20210226 sport:ranking:why:20210227 sport:ranking:why:20210228 weights 1 1 1 1 1 1 1 aggregate sum

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

После завершения выполнения вы можете увидеть дополнительный ключ, который содержит сводку данных за последние 7 дней:

Объединение используется выше.Если наше требование состоит в том, чтобы отсортировать людей, которые загружали спортивные данные каждый день за последние 7 дней, мы будем использовать пересечение для расчета.

Команда такая же, как и выше, просто измените zunionstore на zinterstore.

Кроме того, для сравнения изменено и имя объединенной очереди, команда выглядит следующим образом:

• zinterstore sport:ranking:why:last_seven_day_zinterstore 7 sport:ranking:why:20210222 sport:ranking:why:20210223 sport:ranking:why:20210224 sport:ranking:why:20210225 sport:ranking:why:20210226 sport:ranking:why:20210227 sport:ranking:why:20210228 weights 1 1 1 1 1 1 1 aggregate sum

Из результатов выполнения видно, что поскольку одноклассник Джей не загрузил спортивные данные в день 20210222, он не присутствовал при выезде на перекресток:

Зная практику последних 7 дней, у нас есть данные за каждый день, разве это не распорядок дня за последнюю неделю, прошлый месяц, прошлый квартал и рейтинг этого года?

Эм-м-м......

Как вы относитесь к преподаванию API?

Все равно не годится, а потом менять на другой.

Пользовательский рейтинг на уровне миллиарда

Король Славы, настоящий пользователь миллиардного уровня. Например, я хотел посмотреть, насколько я занимаю место среди пользователей миллиардного уровня, поэтому я открыл игру и спустя более 20 минут (поиграл в игру) наконец-то нашел позицию в таблице лидеров.

В итоге нет в списке:

Я тысячелетний мастер, конечно, не в списке.

Даже если есть ранжирование, ранжирование исчисляется десятками миллионов, а 8-значное число не просто вставить на страницу.

Но если предположить, что текущий спрос состоит в том, чтобы запросить полный рейтинг сервера пользователя, как это проверить?

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

Что я думал?

Мне просто интересно, если в общих интервью встречаются десятки миллионов фрагментов данных, несколько файлов G, сотни миллионов данных и т. д., то первый план, который приходит на ум, — «разделяй и властвуй».

Потребности этого списка рейтинга пользователей на уровне миллиарда также должны использовать идею «разделяй и властвуй».

Всего у короля 8 рангов:

• 1. Упрямая бронза
• 2. Заказать серебро
• 3. Слава Золотая
• 4. Престиж Платинум
• 5. Вечный алмаз
• 6. Высшая звезда
• 7. Сильнейший король
• 8. Король славы

Таким образом, у нас может быть 8 ведер.

Это ведро может быть 8 разными ключами в Redis или даже ключом в каждом из 8 Redis, в зависимости от того, сколько вам даст интервьюер, вы можете построить его, если у вас есть больше денег.

Как показано ниже:

Объясните, почему на картинке выше 8588 баллов.

Сначала мы используем упорядоченную коллекцию Redis, затем мы должны дать каждому участнику оценку.

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

Например, почему текущий ранг брата — Синъяо, при условии, что расчетный балл равен 8588.

Итак, теперь легко вычислить, почему рейтинг брата на всем сервере:

При написании программы вы можете знать, что мой текущий ранг — Xingyao, а затем перейти непосредственно к корзине Xingyao и использовать zrevrank для вычисления ранга в текущей корзине, предполагая, что это n.

Затем он получается с помощью команды O (1) zcard, Предыдущие ведра, то есть заданные размеры двух ведер самого сильного короля и короля славы, равны y и x соответственно.

Тогда почему полный рейтинг сервера Brother равен n+y+x.

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

А теперь легко посчитать топ-100 полного сервера.

Просто бери передний ковш, то есть первые 100 в King of Glory, и готово.

Сделай это.

Подождите, это действительно сделано?

Идея правильная, но для 100 миллионов пользователей всего 8 ведер маловато, правда?

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

Например, Xingyao, есть Xingyao 5 до Xingyao 15 малого ранга, бронза 3 до бронзы 13 малого ранга.

Всего 27 стволов.

Впрочем, 27 стволов тоже меньше.

Тогда от Xingyao 2 до Xingyao 1 по-прежнему нужно пять звезд, а от Bronze 3 до Bronze 2 нужно 3 звезды.

Итак, 160 баррелей.

160 стволов все еще мало?

Лоб. . .

Переверните его снова, напрямую конвертируйте ранг плюс различные другие условия в очки, а затем разделите по очкам:

Таким образом, вы можете разделить столько абзацев, сколько хотите, и вы можете разделить его так точно, как хотите.

Идеально.

Подождите, это действительно идеально?

Вы можете видеть, что мой диапазон очков очень равномерно разделен.

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

Следовательно, игроки бронзового ранга должны быть намного выше, чем Король Славы.

Поэтому на практике размещение пользователей неравномерно.

что делать?

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

Ах, этот материал выходит за рамки.

Тогда попрощайтесь и приступайте к работе.

Соображения, выходящие за рамки технологий

Создание таблицы лидеров кажется очень простым делом.

Но это не так, особенно для рекомендованных рейтингов нужно избегать эффекта Матфея:

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

Авторы в нижней части списка не очень вовлечены.

Так возникает поляризация, и наступает эффект Матфея.

Как справиться с этой ситуацией?

Он включает в себя сложную формулу расчета, такую ​​как значение мощности майнинга сообщества Nuggets, которое используется для рекомендаций потока новостей и списка авторов:

https://juejin.cn/book/6844733795329900551/section/6844733795380232206

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

Последнее слово

Спасибо всем за чтение.

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

Эта статья участвует в «Весенней рекрутинговой кампании Nuggets 2021», нажмите, чтобы просмотретьподробности о мероприятии