сервисы регистрации и аутентификации

внутренние механизмы

не думал, почему они называются внутренними?

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

консистентность в сервисе регистрации?

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

Обычная база данных?

ну обычная вряд ли, на больших объёмах всё обмазано in-memory кэшами, но да, лучше реляционок для этого пока ничего не придумано

на больших объёмах

А такие ли большие объёмы? 7 800 000 000 людей на Земле * 100 КБ регистрационной записи = 744 ГБ. На один компьютер влезет.

А почему 100к, в просто 100 никак?

один компутер какой бы он не был не вытянет такую интенсивность ввода вывода через накопитель, сеть и процессор. поэтому такие вещи шардируют - вариантов множество - идея одна в распределении нагрузок на множество узлов. мне интересны реальные внедренные решения у гигантов рынка типа gmail (google), youtube (google) и аналогичных им по нагрузке. не то как это можно было бы сделать (я сам делаю подобные решения), а то как это сделано у них и сколько серверов в этом задействовано - этой информации не нахожу, но уверен она есть в открытом доступе

А почему 100к, в просто 100 никак?

С запасом. 100 байт? Не хватит для хранения логина, хеша пароля и адреса электронной почты.

Может, на логин-пароль 640 100Кб хватит, но типичный пользователь хочет ведь ещё и фоточки-видосики с последней пьянки залить в условный «вконтакт». А это ещё минимум 10 «гигов». Так что я бы брал 750Гб в квадрате. А ещё лучше в кубе.

это уже хранение данных - вообще другая задача

но типичный пользователь хочет ведь ещё и фоточки-видосики с последней пьянки залить в условный «вконтакт»

Это можно хранить отдельно.

X512, quester, я знаю. Просто типичный FB или Google исключительно «логины-пароли» не хранит, а предоставляет кучу других услуг впридачу. А ведь ещё существует проблема это всё связать, чтобы типичный Вася и почту заимел, и своё местечко на «Гуглдиске», и аккаунт где-то ещё.

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

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

интересны реальные внедренные решения у гигантов рынка типа gmail (google), youtube (google) и аналогичных им по нагрузке

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

я сам делаю подобные решения

А ведь ещё существует проблема это всё связать, чтобы типичный Вася и почту заимел, и своё местечко на «Гуглдиске», и аккаунт где-то ещё.

Элементарно: для каждого сервиса свои серверы и при первом обращении создаётся внутренняя запись для каждого сервиса. Главное чтобы был единый идентификатор пользователя.

раскидаешь на пальцах схему такого сервиса, Шерлок? при том, что пользователь имеет свойство выходить в сеть совсем не там, где он регистрировался, в одном приложении задействовано несколько сервисов, а скорость передачи сырых данных ограничена 299792458 м/c

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

раскидаешь на пальцах схему такого сервиса

Google: distributed database.

У нас под сервис аутентификации на (около 100 млн аккаунтов) выделено три сервера с приложением и два с БД (ну и реплика для снятия бэкапов). И это еще архитектура кривоватая, и аутентификатор заодно хранит историю переименований, банов, привязок внешних учеток и прочую дребедень.

В общем, задача реально не самая сложная.

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

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

Можно заподозрить, что зарегистрировался бот для чего-то нехорошего.

ох ты ничего себе, теперь всё ясно (нет)

distributed database — это не мебель из икеи, её надо собрать в работающую опердень. давай, Шерлок, нарисуй элементарную схему

да-да, еще походы в антифрод на каждую регистрацию, но это мелочь, этим в общей схеме можно пренебречь

Тут тоже несколько вариантов решения. Те, что используются у нас:

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

2. кольцевая репликация данных. Фактически, дельты изменения профиля пользователя циркулируют по сети, от региона изменения через все остальные регионы, пока не вернется на место, где изменение стриггерилось. Апдейт начинает ехать либо в момент завершения пользовательской сессии, либо по достижении лимита на размер дельты (N килобайт).

Алсо, речь не о том, как сделать аналог гдиска, а об аутентификационных и авторизационных данных (ну и уже о расширенном профиле).

работающую опердень

узнаю стиль. Минский раввинатик или кто-то из их жжшных френдов?

твои френды в овраге лошадь доедают. кончай гадать по айпишнику, речь не о том, а о том, что география возможного входа имеет значение для архитектуры сервиса аутентификации, то есть она очень даже «при чём», а то как этот вопрос решен у вас — не мне рассказывай, о ТСу

Можешь посмотреть на устройство https://www.keycloak.org Посмотри их гайд с обеспечение высокой доступности и как оно кластеризуется. Не то, чтобы совсем конский high load, но достаточно серьёзные нагрузки держит хоть и жрёт как не в себя.

Я не по айпишнику гадаю, а по характерным оборотам речи.

ну то попускайся — ни онлайн, ни оффлайн мы с тобой не брудершафтились.