Можно ли управлять пользователями / удостоверениями в хранилище данных, которое демонстрирует возможную согласованность? - PullRequest
5 голосов
/ 07 сентября 2011

Можно ли создавать / хранить учетные записи пользователей в хранилище данных, которое демонстрирует возможную согласованность?

Кажется невозможным управлять созданием учетных записей без кучи архитектурной сложности, чтобы избежать ситуаций, когда две учетные записи с одинаковым UID(например, адрес электронной почты)?

Используют ли пользователи конечных хранилищ согласованности отдельную согласованную БД в качестве хранилища идентификаторов, или есть решения / шаблоны, которые я должен изучить?

Спасибо взаранее,

Джейми

1 Ответ

1 голос
/ 07 сентября 2011

Это можно использовать для управления в конечном итоге непротиворечивом хранилище данных.Мы делаем это.Он работает при следующих допущениях:

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

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

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

...