Я работаю над черновиком приложения, которое предлагает услугу на основе подписки для мобильных телефонов, есть требование, чтобы учетная запись использовалась только на одном устройстве, если он вошел в другое, то первый выйдет из системы. разработчик дал некоторые идеи о регулярном опросе, но мне нужен умный способ уменьшить пропускную способность, а не регулярный опрос БД для зарегистрированных пользователей.
Проблема состоит в том, чтобы поддерживать связь с пульсом и предупреждать пользователя, если кто-то еще вошел в систему, и экономить пропускную способность, поскольку будет более 10000 устройств, которые будут регулярно запрашивать.
Я пока не беспокоюсь о языке или коде, я сейчас ищу лучший способ / логику. спасибо за совет заранее с уважением, K
Вот один подход.
При аутентификации мобильный телефон получает случайный маркер безопасности, который хранится для пользователя в базе данных, но также сохраняется в кэше в памяти (совместно используемом всеми серверами), сопоставляя идентификатор пользователя с маркером.
Каждый раз, когда мобильный пользователь общается, он включает идентификатор пользователя и токен безопасности, который проверяется по кешу: если токен не соответствует токену в кеше, то проверяется база данных. Если токен не совпадает с токеном в базе данных, связь отклоняется с сообщением, указывающим, что пользователь не вошел в систему на этом устройстве или не вошел в систему в другом месте, с возможностью повторной аутентификации.
Если пользователь явно выходит из системы, токену безопасности можно присвоить специальное значение в базе данных, указывающее, что пользователь не вошел в систему, а запись удаляется из кеша.
Размер кэша в памяти имеет порядок (количество пользователей, вошедших в систему) * (идентификатор пользователя + длина токена безопасности + накладные расходы) * 2. Для 10 000 пользователей GUID, используемый для идентификатора пользователя и токена безопасности, дает примерно 10 000 * ( 16 + 16 + 8) * 2 = 800 Кбайт. Так что размер кеша не представляет проблем. Используйте hash-with-chaining, чтобы разрешить удаление хеш-записей, или просмотрите множество доступных хранилищ значений ключей с открытым исходным кодом.
Если таблица «сеансов», содержащая пользователя и токен сеанса, достаточно мала, база данных может хорошо выполнять работу по кэшированию самой таблицы, и в этом случае кеш сеансов и дополнительная логика могут не понадобиться.
Если у вас есть оценка частоты обмена данными между мобильным устройством и сервером, рассмотрите возможность проведения эксперимента, чтобы узнать, нужен ли кеш.