Единая авторизация

Привет.
Такая ситуация, есть сеть сайтов досок объявлений:
ссылка
ссылка
ссылка
ссылка

У каждого сайта своя база данных. Если регистрироваться на одном сайте, на других аккаунты не создаются автоматом. У пользователя есть свой внутренний счет, с которого он может оплатить услуги, есть история операций.
Теперь появилась идея создать единый аккаунт. Как это лучше делать?
Я пока думаю о двух вариантах:
1. При регистрации на одном из сайтов, автоматом добавлять аккаунты и на других сайтах. Но это будут разные аккаунты, и если скажем пользователь пополнит счет на одном из сайтов он не сможет тратить средства на других сайтах. Можно конечно сделать каждый раз клоны операций со счетом, но не знаю на сколько хорошая эта затея.
2. У каждого сайта своя база. Создать еще одну, и там держать все что связано с пользователем. Тогда возникает проблема: надо будет работать с двумя базами одновременно. Более того, есть запросы в котором через JOIN связаны таблицы пользователя и другие таблицы системы. Надо будет переделать, но это в ущерб производительности.

Как лучше решить эту проблему, может у кого есть другие идеи?

УПД1: Все 4 сайта на один и тот же движок, база имеет одинаковую структуру.

Судя по всему все сайты на одном хосте.
Объединить базы в одну - добавить префиксы, по которым отличать таблицы одной страны от таблиц другой страны (если этого не сделано), таблицу пользователей оставить без префикса и обращаться к ней из всех скриптов всех стран.

Цитата ("frig"):

Судя по всему все сайты на одном хосте.

на данный момент да. Но на будущее планируется что каждый сайт будет на своем сервере. Так что это не выход.

Цитата ("WebDesignStudio"):

на будущее планируется что каждый сайт будет на своем сервере

Зачем?

Цитата ("frig"):

Зачем?

А вы как думаете? Сайты не зря создавались с отдельными БД.

WebDesignStudio, я могу только предполагать. У вас есть какие-то весомые причины растаскивать проект на разные хосты?

Цитата ("frig"):

WebDesignStudio, я могу только предполагать. У вас есть какие-то весомые причины растаскивать проект на разные хосты?

да, есть. Это решено.

WebDesignStudio, какие?
Очень может быть, что это просто изобретение самому себе проблем для их героического преодоления. Мне сложно представить в самом деле весомые плюсы, которые перечеркнут все минусы и будут дороже всех проблем, которые возникнут при разнесении. В данный момент вы столкнулись с первой.

frig, высокая посещаемость. Этого достаточно. Плюс сайты региональные, возможно при выборе сервера это тоже будет учитывается.

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

frig, и как создать одну базу и хранить ее на 4 разных серверов? Или я отстал от технологий?
Тут доска объявлений. Объемы баз будут не детские. Уже имеем приличные размеры, а на будущее будет еще больше. Нет никакого смысла хранить в одну базу объявления всех 4 стран и плодить огромную базу. И возможно стран будет больше.

Цитата ("WebDesignStudio"):

и как создать одну базу и хранить ее на 4 разных серверов?

Ну чтобы вам понадобилось 4 сервера под базы - надо сначала очень очень и очень постараться, а потом есть репликация. Или вы думаете facebook хранит всю базу на одном сервере? Или в одном экземпляре?

Цитата ("WebDesignStudio"):

Нет никакого смысла хранить в одну базу объявления всех 4 стран и плодить огромную базу.

Я вам выше написал какой в этом смысл. Начиная от первоначальной задачи по единой учетной записи и заканчивая балансировкой нагрузки.

Может попробовать облачный хостинг?

frig, если честно я не совсем понял о чем вы писали. Мы пока не равняемся на Фейсбук. Но смысла нет объединить базы. Страны разные, объявления тоже. Только из за единой авторизации на такое пойти, думаю не разумно.

Цитата ("Hungry_Hunter"):

Может попробовать облачный хостинг?

посмотрю что это такое. Но базы в любом случае хочется держать отдельно.

Объединение баз это крайняя мера.

Цитата ("WebDesignStudio"):

Но смысла нет объединить базы. Страны разные, объявления тоже. Только из за единой авторизации на такое пойти, думаю не разумно.

Нет смысла разделять базы. Разделение приведет к усложнению масштабирования и невозможности балансировки нагрузки. Разделять только для того чтобы разделять - не разумно. И уж тем более нет смысла городить огород до того момента когда в самом деле оказалось что один сервер не справляется с нагрузкой.

Может есть и другие идеи кроме объединения баз?

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

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

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

Может быть есть еще варианты, но у меня есть сомнения, что они не будут иметь недостатков связанных с безопасностью, сетевыми расходами, скоростью работы и отказоустойчивостью. ИМХО все это пустая трата времени на данном этапе.

Вариант - отдельный сервер для баланса по счету и авторизации пользователей.

WebDesignStudio, Если все что выше предложили не подходит - только через Loginza или аналогичные сервисы вход
ссылка

AlexsimA, вряд ли это тут поможет...