LINUX.ORG.RU
Форум — Development  

Регистрация

 


0

1

Положим мы создаем gmail.com или еще более массовый сервис. При регистрации нужно проверять логин на уникальность, на то что он не существует в системе. Получается что сервер проверки становиться узким местом, ведь он единолично должен проверять уникальность не допуская появления не уникального логина. Может быть у кого-то есть идеи как это узкое место можно расширить?

★★
← Почему не срабатывает static_cast в main.cpp, а в других местах срабатывает?
Найти подстроку в строке →
Ответ на: комментарий от quester

auth-сервер отдельно, app-сервер отдельно. Для проверки валидности запроса клиента app-сервер не обращается к auth-серверу.

vvn_black ★★★★★
()
Ответ на: комментарий от quester

Если речь идет только про регистрацию, то да, мой ответ мимо.

vvn_black ★★★★★
()

ведь он единолично должен проверять уникальность

Ну поднимите их еще сто рядом. С сервисом уровня gmail или еще более массовым вы скорее в базу упретесь, и тут уже так просто проблему не решить.

micronekodesu ★★★
()

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

micronekodesu ★★★
()
Ответ на: комментарий от micronekodesu

поле логина в базе объявить уникальным и серверу вообще ничего проверять не потребуется

я про то и говорю - в результате упираемся в ОДИН сервер базы данных

quester ★★
() автор топика
Ответ на: комментарий от tailgunner

Тупо расшардить. Один сервер проверяет все идентификаторы «a*», другой - «b*» и т.д.

Не лучший вариант, ну да в 26 раз нагрузка снизиться в идеале (поскольку распределение будет не нормальное)

quester ★★
() автор топика

Делаешь N серверов, запрос на авторизацию с логином «foo@bar.wtf» отправляешь на сервер с индексом hash(«foo@bar.wtf») % N

anonymous
()
Ответ на: комментарий от quester

на более частые буквы больше серверов, на редкие меньше

Harald ★★★★★
()
Ответ на: комментарий от quester

Тупо расшардить. Один сервер проверяет все идентификаторы «a*», другой - «b*» и т.д.

Не лучший вариант

Вообще-то, из предложенных - лучший. И, я подозреваю, единственный.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Делаешь N серверов, запрос на авторизацию с логином «foo@bar.wtf» отправляешь на сервер с индексом hash(«foo@bar.wtf») % N

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

quester ★★
() автор топика
Ответ на: комментарий от quester

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

anonymous
()

Ну а, мастер-слейв может же быть несколько мастеров, вот на одном из них проверять уникальность внутри транзакции и резервировать (неактивен) введенный логин. Да и то, даже если мастер один — обычно чтений много, а вставка-апдейт реже, может и один справиться.

И самое главное:

Как можно делать хайлоад и спрашивать такие базовые вещи? Так ты же некомпетентен и всеравно сделаешь говно. Может нанять тех, кто уже имеет в этом опыт? Или, если нанимать не надо, то, значит делишь ты шкуру не убитого медведя в очередной попытке взлететь с стартапом — преждевременная оптимизация же. Сделай по говняцки, а там видно будет, надо оно или нет.

deep-purple ★★★★★
()
Ответ на: комментарий от quester

Обычно берут N достаточное большое (назовём его «виртуальный индекс сервера»), при этом фактическое количество серверов M будет сильно меньше (назовём его «физический индекс сервера»).

Один физический сервер обслуживает несколько виртуальных.

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

anonymous
()
Ответ на: комментарий от quester

Не лучший вариант, ну да в 26 раз нагрузка снизиться в идеале (поскольку распределение будет не нормальное)

Про хэши слышал?

router ★★★★★
()
Ответ на: комментарий от router

«Первый символ от строки» это тоже хешфункция просто не очень эффективная :-)

anonymous
()
Ответ на: комментарий от drsm

Bloom Filter спереди поставь.

Об этом то-же думал, вот только проверять ты его где будешь? Опять приходим к единой точке

quester ★★
() автор топика
Ответ на: комментарий от anonymous

угу, это называется виртуальные шарды

quester ★★
() автор топика
Ответ на: комментарий от deep-purple

может и один справиться

а может и не справиться. речь про это.

Как можно делать хайлоад и спрашивать такие базовые вещи?

я просто рассуждаю и перепроверяю себя. давай расскажи мне о архитектуре приложения Periscope

quester ★★
() автор топика
Последнее исправление: quester (всего исправлений: 1)
Ответ на: комментарий от quester

Зачем я буду тебе что-то рассказывать?

Ты или делаешь какой-то продукт или не делаешь.

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

А может ты и есть тот «спец» которого наняли? Хрен тебя знает.

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

как сказал кто-то из древних не нужно считать окружающих глупее себя

у тебя вообще ничего нет

завидую вашей уверенности

quester ★★
() автор топика
Ответ на: комментарий от quester

в данном случае воще можно писать uidы в блокчейн, используешь какую-нибудь KDV )))

drsm ★★
()
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.
← Почему не срабатывает static_cast в main.cpp, а в других местах срабатывает?
Development
Найти подстроку в строке →