Как реализовать счетчик «сейчас этот товар просматривают еще N человек»?

Question

[Odrin]

Как бы вы реализовали такой счетчик? Как построить масштабируемое решение? Как пример - booking.com, счетчик кол-ва пользователей, просматривающий объект размещения.

Answer 1

[Илья]

На странице делать периодическую отправку состояния "объект просматривают". Складываете состояние в Redis HashSet со структурой:
название хэша = id объекта
ключ = id пользователя
значение = timestamp
Выбираете таймаут, например 5 секунд и считаете все записи старше 5 секунд невалидными.
Для построения счетчика берете количество валидных элементов в хэше для конкретного объекта.
Чтобы хэш не разрастался нужно удалять простроченные элементы т.к. Redis не умеет инвалидировать элементы хэшсета. Это можно делать периодически либо написать скрипт на lua который будет делать вставку нового элемента и одновременно удалять просроченные.

Answer 2

[Константин Нагибович]

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

Comments

[Шохрух Шаймардонов]

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

[Adamos]

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

[Шохрух Шаймардонов]

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

[Adamos]

Шохрух Шаймардонов, реальные данные никому не нужны в виде "сейчас просматривают".

[Odrin]

Adamos, Константин Нагибович с рандомным счетчиком все понятно. Но во-первых, это легко расчехляется и доверие пользователей сразу падает. Во-вторых, вопрос был именно про техническую сторону вопроса и чисто теоретичекий, и ответ "маркетинговая уловка" не совсем вписывается в формат Хабра, не находите?

[Odrin]

Шохрух Шаймардонов, решение с сокетами плохо масштабируется, а так да, как вариант.

[Adamos]

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

Answer 3

[Александр Кубинцев]

Если решать проблему технически, то сперва надо определиться с частотой обновления или точностью. Что значит пользователь сейчас смотрит эту страницу? Активная вкладка браузера? А если он отвёл взгляд? )) И нужно ли действительно иметь такую высокую точность, какую бизнес-задачу это решает?
На вскидку есть 3 способа:
1) "дедовский": строить логи nginx таким образом, чтобы их удобно было парсить и брать число запросов на нужные страницы в интервал сканирования
2) собирать статистику на уровне роутера приложения в redis (как предложили недавно выше)
3) самый точный, но слишком накладный, это вебсокеты открывать на странице и считывать откуда они.

Answer 4

[Mike_Kiyan]

Юзать библиотеку SignalR, количество активных пользователей хранить в Redis Server