-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Синхронизация
- Автор темы yintar
- Дата начала
workOnFood
Новичок
Если сайты на одном движке то можно использовать одну базу товаров для обоих сайтов. Если на разных, то можно дописать отправку данных с одного сайта на другой при добавлении товара, либо адаптировать запросы к бд и иже с ними, для того чтобы опять таки использовать одну базу.
yintar
Новичок
workOnFood.спасибо за ответ,но сайты находятся на разных хостингах.как быть в этом случае?
artoodetoo
великий и ужасный
Это не имеет значения. Если вы сможете управиться с разными базами на одном хосте, вы сможете повторить это на разных хостах только надо будет использовать туннель.
Только у меня есть смутное подозрение, что вас бы устроило два разных доменных имени одного и того же хоста
Это снимает все проблемы.
Только у меня есть смутное подозрение, что вас бы устроило два разных доменных имени одного и того же хоста
Это снимает все проблемы.
workOnFood
Новичок
Не слушай их. Никакого доступа к БД не нужно.
На втором сайте должен быть сервис, который будет добавлять товары. Первый сайт будет его вызывать. Вполне достаточно обычного типа-REST где по post данным будешь записывать новый товар в базу.
Главное удостовериться, что использовать его будет только первый сайт. По IP там.. или что-нибудь еще.
И еще, второй сайт должен высылать в ответ отчет об успешной записи этого товара({"ok":1 хотя бы
). Тогда первый сайт будет знать что все прошло отлично. Если не получилось - надо как-то с этим справляться. Это не такая уж и простая задача если требование о синхронизации очень важное с точки зрения бизнеса.
На втором сайте должен быть сервис, который будет добавлять товары. Первый сайт будет его вызывать. Вполне достаточно обычного типа-REST где по post данным будешь записывать новый товар в базу.
Главное удостовериться, что использовать его будет только первый сайт. По IP там.. или что-нибудь еще.
И еще, второй сайт должен высылать в ответ отчет об успешной записи этого товара({"ok":1 хотя бы
). Тогда первый сайт будет знать что все прошло отлично. Если не получилось - надо как-то с этим справляться. Это не такая уж и простая задача если требование о синхронизации очень важное с точки зрения бизнеса.yintar
Новичок
workOnFood ,Вы сказали удаленный доступ к бд, а как можно этот самый доступ реализовать и подойдет ли такой алгоритм:
1. Сайт1 добавляет/изменяет/удаляет товар.
2. В процессе выполнения п1 сайт1 стучится на какой-то скрипт сайта2
3. Достучавшись до скрипта, сайт1 сообщает сайту2 какие изменения у него произошли
4. Сайт2 получив новость выполняет то же самое у себя
1. Сайт1 добавляет/изменяет/удаляет товар.
2. В процессе выполнения п1 сайт1 стучится на какой-то скрипт сайта2
3. Достучавшись до скрипта, сайт1 сообщает сайту2 какие изменения у него произошли
4. Сайт2 получив новость выполняет то же самое у себя
yintar
Новичок
Не слушай их. Никакого доступа к БД не нужно.
На втором сайте должен быть сервис, который будет добавлять товары. Первый сайт будет его вызывать. Вполне достаточно обычного типа-REST где по post данным будешь записывать новый товар в базу.
Главное удостовериться, что использовать его будет только первый сайт. По IP там.. или что-нибудь еще.
И еще, второй сайт должен высылать в ответ отчет об успешной записи этого товара({"ok":1 хотя бы
Adelf примерно так:?
1. Сайт1 добавляет/изменяет/удаляет товар.
2. В процессе выполнения п1 сайт1 стучится на какой-то скрипт сайта2
3. Достучавшись до скрипта, сайт1 сообщает сайту2 какие изменения у него произошли
4. Сайт2 получив новость выполняет то же самое у себя
правильно?
workOnFood
Новичок
@yintar, Удаленный доступ, если брать MySql нужно разрешить в настройках бд, указать ip с которого следует принимать запросы и затем просто подключаться с удаленного серва. В кратце так, в гугле можно найти более подробные инструкции. Описанный вами алгоритм вполне рабочий. Мне только не понятно зачем нужен весь этот лишний менеджмент данными, когда можно сделать проще и лаконичнее.
@workOnFood, сейчас дам read-only за крайне плохие советы.
Не должен сайт1 лезть в базу сайта2. Это вообще не его дело разбираться как там устроены таблицы у другого сайта. Да и несекьюрно это. Вощем столько минусов, что стыдно такое предлагать.
Не должен сайт1 лезть в базу сайта2. Это вообще не его дело разбираться как там устроены таблицы у другого сайта. Да и несекьюрно это. Вощем столько минусов, что стыдно такое предлагать.
у сайта2 будет например http://site2.ru/api/goods/add - с помощью POST туда надо будет передать все данные. помочь может curl.
http://myrusakov.ru/php-curl-post.html - вот тебе простой пример нагуглил. Пробуй. Мучайся. Без этого никак.
http://myrusakov.ru/php-curl-post.html - вот тебе простой пример нагуглил. Пробуй. Мучайся. Без этого никак.
workOnFood
Новичок
@Adelf, Не надо ридонли, я же не со зла, возможно я просто дурак. Хотелось бы понять в чем я не прав если это так 1) если можно ссылочку на какую-то инфу, почему это не секьюрно 2) Если движки сайтов идентичны то сайты уже прекрасно знают что там в таблицах у каждого из них. Минус в скорости запроса очевиден засчет соединения с сервом если он физически далеко находится, это да.
@workOnFood, самая главная причина чем мне это не нравится это то, что тут с отношениях сайт1 - типа главный, как master в отношениях master-slave Поэтому не должен он сильно страдать и мучаться чтобы передать данные второму сайту. Вызвать сервис - вполне достаточно. А уже второй сайт должен все как следует реализовать - он слуга
Немного несерьезно отвечаю, но это мои первые мысли.
Второе - инкапсуляция. Никто не должен лезть внутрь другого сайта. есть общепринятый механизм - API. Надо делать и использовать.
P.S. Про ридонли шутка конечн. Но с долей правды ;-)
Поэтому не должен он сильно страдать и мучаться чтобы передать данные второму сайту. Вызвать сервис - вполне достаточно. А уже второй сайт должен все как следует реализовать - он слуга Немного несерьезно отвечаю, но это мои первые мысли.
Второе - инкапсуляция. Никто не должен лезть внутрь другого сайта. есть общепринятый механизм - API. Надо делать и использовать.
P.S. Про ридонли шутка конечн. Но с долей правды ;-)
workOnFood
Новичок
Ок)) Я понял. Мастер-слейв кончено не красиво, согласен. Просто говоря об общей базе я куда-то далеко улетел мыслями, в сторону большого количества сайтов пользующихся одной и той же инфой, вспомнились видосы крупных компаний, где они рассказывают про использование отдельного сервера для базы данных. Хотя там скорее всего тоже есть какая-то обертка а не тупо удаленное подключение... Вобщем, я вроде как понимаю почему предложенный мной подход не так хорош как он мне показался с первого взгляда. Каждый раз при показе юзеру страницы с категорией товаров например слать удаленный запрос вероятно не лучшая идея. А вот насчет секьюрности интересно) Не разу не наталкивался на информацию по этому вопросу. Понятно, что взломать можно что угодно, но если вы делаете упор на несекьюрность то там наверное все совсем уж плохо.
ksnk
прохожий
@yintar, Сайты равноправные? В смысле - товары могут неожиданно "появляться" на обоих сайтах независимо?
Если так - то и систему "синхронизации" нужно будет ставить на оба сайта. Хотя лучше административно назначить один сайт "главным" и выравнивать базу товаров по нему.
Схематично, синхронизация может выглядеть примерно так:
Каждая карточка товара должна иметь время последней модификации
Запрос на сайт, выдает все товары, измененные после указанной даты.
http://site.me/admin/get_all_items?after=2015/08/08 , ну или
http://site.me/admin/get_all_items?after=1441467897, если timestamp
Выдает, для примера, в xml формате. Его преимуществом, imho, перед json будет то, что его проще человеком просмотреть, в броузере, для проверки. Хотя, конечно, на любителя...
Получив ответ от сервера, нужно обновить все свои товары с более старым временем обновления.
Запускать синхронизацию по крону, при успешном выполнении скрипта - передвигать время следующей синхронизации.
Если так - то и систему "синхронизации" нужно будет ставить на оба сайта. Хотя лучше административно назначить один сайт "главным" и выравнивать базу товаров по нему.
Схематично, синхронизация может выглядеть примерно так:
Каждая карточка товара должна иметь время последней модификации
Запрос на сайт, выдает все товары, измененные после указанной даты.
http://site.me/admin/get_all_items?after=2015/08/08 , ну или
http://site.me/admin/get_all_items?after=1441467897, если timestamp
Выдает, для примера, в xml формате. Его преимуществом, imho, перед json будет то, что его проще человеком просмотреть, в броузере, для проверки. Хотя, конечно, на любителя...
Получив ответ от сервера, нужно обновить все свои товары с более старым временем обновления.
Запускать синхронизацию по крону, при успешном выполнении скрипта - передвигать время следующей синхронизации.
начни с того что id которые генерятся на различных сайтах не пересекаются
далее нужна табличка изменений типа лог, где хранится таблица id и тип изменения (insert/update/delete).
дальнейшее хоть json хоть webservice хоть обычный post/get
ну и вопрос целосности данных тоже актуален (транзакция)
далее нужна табличка изменений типа лог, где хранится таблица id и тип изменения (insert/update/delete).
дальнейшее хоть json хоть webservice хоть обычный post/get
ну и вопрос целосности данных тоже актуален (транзакция)
@Adelf, ты прям как Фанат
гладко было на бумаге, но есть одна серьезная проблема: для человека, который спрашивает как стучаться скриптом, реализовать твой алгоритм в ближайшие пару месяцев невозможно.
Ты пишешь, что соединяться с удаленной базой - ужос-ужос. Может быть.
Как насчет проблем с поддержкой нестандартного кривого протокола, отсутствием обработки ошибок и проблем со связью, невозможностью отдебажить и поддерживать?
Как насчет настройки авторизации для этого API?
Давайте не тешить человека пустыми надеждами. Прямое соединение с удаленным сервером БД может быть практически единственным доступным решением.
гладко было на бумаге, но есть одна серьезная проблема: для человека, который спрашивает как стучаться скриптом, реализовать твой алгоритм в ближайшие пару месяцев невозможно.
Ты пишешь, что соединяться с удаленной базой - ужос-ужос. Может быть.
Как насчет проблем с поддержкой нестандартного кривого протокола, отсутствием обработки ошибок и проблем со связью, невозможностью отдебажить и поддерживать?
Как насчет настройки авторизации для этого API?
Давайте не тешить человека пустыми надеждами. Прямое соединение с удаленным сервером БД может быть практически единственным доступным решением.
Последнее редактирование: