Как лучше работать с пользовательскими лайками?

Question

[swop]

Сейчас работаю над проектом который предполагает высокую нагрузку.


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


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


При использовании кэширования эта актуальность индикаторов теряется. Возник вопрос, каким способом поддерживать эту актуальность, используя кэширование?


В голову приходят такие варианты:


1) Делать ajax запрос после загрузки страницы и расставлять лайки js-ом.

2) После логина пользователя, хранить все его лайки в куках и так же расставлять их потом js-ом (избавляемся от ajax запросов)


Спасибо за ответы!

Answer 1

[Денис Егоров]

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

SELECT ... FROM votes WHERE user_id=<id> AND object_id IN(...)

Один запрос на все лайки одного типа. N запросов, если на странице N типов объектов.

Можно попробовать хранить (или дублировать) голоса в NoSQL, например в Redis с ключами типа «post_{post_id}_{user_id}» и вытаскивать их одним запросом mget… Но вы сначала запуститесь, и поймите что именно получение голосов у вас является узким местом, а потом городите такие штуки.

Comments

[swop]

Да, именно так и делаются сейчас запросы на лайки. Один запрос на все лайки одного типа.
Мне просто известна нагрузка текущего сайта, это 1600 запросов в минуту — пиковая нагрузка. Поэтому думаю что использование кэширования на стороне nginx не избежать, и вот затык как раз на расстановке индикаторов лайков оказался.

[Денис Егоров]

1600 — это уже нормально для оптимизации лайков, согласен :)
1. Наверняка из 1600 только процентов 15 авторизованные, можно кешировать нгинксом только анонимусов. Для зарегистрированных всё равно не накешируешься, если только блоками.
2. Кешированием на клиенте ИМХО отпадает сразу из-за невозможности инвалидации. Проголосуете в одном браузере, а на другом получите ошибку повторного голосования.

[swop]

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

[Assorium]

У гигантов огромный кластер из Memcached подобного интерфейса. (очень огромный).

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

[swop]

Это справедливо для статичных страниц, на одной и той же странице могут быть разные элементы. Например 5 фидов: Новости, События,… Они обновляются, новый появляются, старые уходят, не привяжешь их к одной странице.

[Assorium]

Справедливо. Но тут может спасти такое решение как MemcacheDB. Все дублировать в нее и из нее грабать.

Answer 2

[Alexandr Rabotyahoff]

все лайки текущей страницы можно вытянуть одним запросом.
SELECT ... FROM votes WHERE user_id=<id> AND uri IN(...)
где uri — универсальный идентификатор объекта. Например
фото 1 — photo://1
юзер 1 — user://1
и т.д.

В итоге не нужно разбиение на типы. Кроме того uri-подход во многих местах оказывается удобным. Например можно вести статистику вне зависимости от типа объекта.