Синхронизиране на два и повече уебсайта.

stuklen

Well-Known Member
Търся идеи и стратегии за синхронизиране на два и повече уебсайта.

За пример ще дам три идентични електронни магазина. Основно в тях има продукти/опции/наличности.
Търся оптимален вариант при който добавяне на продукт, промяна в наличността и т.н. в един от магазините, да се отразява и в останалите.
Мислил съм за вариант в който един от сайтовете, да е основен и всички останали да се синхронизират по него.

Някой да е мислил по този въпрос?
 
Ако съдя по категорията в която се намира, въпроса е по скоро към програмисти, а не толкова към собственици на магазини, така ли е?
Синхронизирането няма да е особено трудно - просто използвай една и съща база данни.
Въпросът тук е:
1. На споделен хостинг ли си или собствен сървър?
2. Готови системи ли използваш за тези магазини или custom?
3. Всички продукти и наличности ли са еднакви и в трите магазина? Т.е. трите магазина клонинги ли са или всеки е различен?
 
Здравей, искаш да направиш така наречената мрежа от сайтове, най-добре да се ползва Rest APi което ще направи синхронизация на продуктите. Сигурно искаш и всички поръчки от тези магазини да влизат в един панел където е главният магазин или мислиш да обикаляш към всеки панел?

Другото което е че чрез Rest APi ще избегнеш примерно вкарване на дадена категория, да вземем един прост пример от моят опит.
Клиента има сайт със 10 категории тип eMag, иска обаче да направи мрежа от сайтове и всеки сайт да вземе една категория от този главен магазин, благодарение на Rest APi всичко работи коректно.

А за това което колегата каза че синхронизация няма да е трудна това няма как да се знае, всеки случая е различен, ако имаш повече изисквания ще ти е зор и ще имаш постоянно проблеми и загуба на данни. Трябва да се премисли всичко и да се направят доста тестове и според мен само чрез Rest APi, другото което ако ползваш една база данни е най-голямата глупост, как ще направиш разделение за реклама ако искаш да направиш добри тези сайтове ще ти трябва реклама, ще стане мазалак, другото което е че ако искаш да направиш преводи.....

Надявам се да съм помогнал.


Поздрави,
Станимир Любенов
 
С няколко уговорки.

Ако приема, че софтуера има следните характеристики:

  • всичко се хоства в един дейта център
  • използва mysql
  • няма разни шантави проверки, локинг или рейс къндишъни в работата с базата от типа на: направи запис, а след записа веднага провери дали записа е наличен за да не успеят всички сървъри да захапят промяната преди проверката
  • може да поддържа повече от един домейн
1. Слагаш базата върху общ mysql клъстър в master-master конфигурация.
2. Кофигурираш софтуера на всичките магазини да работи с тази база
 
Мислил съм го и съм го правил веднъж.
Нещо подобно на Уордпреско-вото описание - с MariaDB, active-active конфигурация (промените се копират във всички бази).

Първо трябва да имаш шел достъп, сървърчетата да са в прайвит нетуърк, и други алибали.
Нищо особено не е - има степ-бай-степ тюториали в интернета.
 
Станимир междудругото не е далече от истината как се прави the right WAY с API , но го е обяснил така че никой да не схване за какво иде реч и с някакъв супер измислен пример.

Другото което е че чрез Rest APi ще избегнеш примерно вкарване на дадена категория, да вземем един прост пример от моят опит.
Клиента има сайт със 10 категории тип eMag, иска обаче да направи мрежа от сайтове и всеки сайт да вземе една категория от този главен магазин, благодарение на Rest APi всичко работи коректно.
Кво каза? Какво значение има дали ще пращаш разни JSON-и по апито , или ще пращаш заявки към базата, и какво общо имат категориите? Ако си си описал нещата, как така ще вкараш категория където не и е мястото? WTF



Идеята му е явно да имат всички магазини рест архитектура, която да се чекват взаимно, което едно че е ,тъпо, другото, което е че се пише няколко пъти на няколко места едно и също.

Правилния начин е Service Pattern, или микросървиз, както искаш -> работата му е да проверява от children магазините към сървъра. После сетваш магазините да депендват на тоя сървиз. Как ще го синхронизираш е твоя работа, пък и зависи от ситуацията, може да искаш да става с CRON, а може да искаш да е при определени actions, а може пък да искаш магазините да не пазят при тях изобщо продукти, а всичко да се пази при sync сървъра. Ама трябва и да се попише код и да се бърника, примерно ако 3те магазина са на различна платформа... трябва да им учиш нещата, че да ги навържеш. Ако е нещо къстом, правиш си един сървиз, някакъв общ interface дето шерват всички магазини , това е важно, щото после като почнеш да добавяш други магазини, да знаеш кое как ще се случва и какви са ти методите.
Аз бих го направил с един сървър, при който пазя данни за продуктите, наличностите и т.н.. Тогава бих си написал нещата така, че ще добавям продукти само в този сървър, а той ще споделя разни endpoints към 'children' магазините. Лесно и scalable, и ако искам да имам 100 магазина, няма да се налага да пипам нищо по сървъра, ако съм си написал правилно нещата и интерфейса. Нали са няколко към 15-тина метода в най-лошия случай, дето се споделят.
Реално магазина няма да знае откъде идват данните така или иначе, ще има Repository, а магазина НЕ трябва да знае откъде и как идват данните, в момент в който искаш да разкачиш магазина, само пипаш по репозиторито, дето събира данните, дали от 'мастер' сървъра или от друго място, все тая.

Тъпия начин е да навържеш магазините директно към една база, ама какво става ако някой магазин няма разни пропъртита, или пък има различни такива, които ги няма в другите. Стават едни нагласяния, и не е скалируемо. Един интерфейс ти оправя нещата. А сървъра, който реално държи базата е must, за да имаш унифициран начин да махаш продукти за всички магазини, да редактираш и т.н.. Отделно, ако си впишеш нещата като хората, сървъра изобщо няма да депендва на магазините, и магазините няма изобщо да ги интересува откъде идват данните, точно както трябва да бъдат нещата. За пример , ако единия магазин проверява за продукт дали е наличен, не трябва да го интересува откъде идват данните, дали от сървър 1, или 2, дали от магазин 1, 2 и т.н... , бих си и направил така нещата, че всичко да идва от Repository, което е вързано за сървиза, така в един момент искам да разкача магазина от 'дебелия' сървър, и го разкачам без да пипам нищо по класовете и файловете от магазина, само ще си пипна Репозиторито и ще променя откъде фечвам инфо.
 
Последно редактирано:
Да, въпроса е към програмисти или софтуерни архитекти, за това съм сложил запитването в категория Web Development
Всеки уебсайт ще си има собствен панел.

Определено една база данни не е вариант. Поради ред причини. Като се започне от различие в магазините като структура език и т.н.
Цели се да работят на споделен хостинг. Т.е. без нужда от рут достъп до сървъра/ите. Синхронизацията, като цяло обмислям да се свежда до синхронизиране на продукти и количества. И аз така го мислих с API, но идеите които ми идват за процеса на комуникация не ми се струват оптимални.

Мисля си, да е нещо опростено и ефективно, както и отделните сайтове да са зависими един от друг и да не ги интересува, кой от къде и на къде отправя запитването. Ако имаше някакъв складов софтуер, щеше да е лесно, но тук приемаме, че няма такъв.

Сценария който съм измислил е следния с уговорката, че синхронизацията се отнася само за продукти и наличности:
Има един основен магазин, който ще го играе все едно складов софтуер. Там ще се въвеждат продукти/опции/наличности.
Другите сайтове ще са подчинени, те ще получават информация от основния за промени по артикула.
И тук стратегията се разделя на три.
Единия вариант е да се задейства синхронизацията при действие. Примерно при добавяне на артикул в основния или продажба в някой от сайтовете.
Втория вариант с крон задача на главния уебсайт, която на определено време да прави запитвания/обновявания.
Третия вариант смесица от предните два. При промени в главния сайта /при действие/, да се актуализират подчинение плюс крон, който отправя запитване през определено време за наличностите по подчинените сайтове.

Първия вариант ще работи онлайн т.е. ще имам мигновена синхронизация, но тук всеки от сайтовете трябва да съобщава на всички останали или подчинените да съобщават на главния и той на останалите. Т.е. всеки трябва да знае за другия, което не мисля, че е добре или трябва, да се задейства някаква верижна синхронизация.

Втори вариант е добър, тук само главния уебсайт ще знае кои са подчинените и той ще прави запитванията към останалите, но тук се получава период в който данните няма да са актуални.

И към момента третия вариант ми изглежда най-подходящ, но пак си има някакви недостатъци.

Трябва ми такава стратегия, при която така да се получат нещата, че да не се налагат допълнителни бази данни, дублиране на информация, зависимост между сайтовете, сложен механизъм на синхронизация.
 
Последно редактирано:
Тъпия начин е да навържеш магазините директно към една база, ама какво става ако някой магазин няма разни пропъртита, или пък има различни такива, които ги няма в другите. Стават едни нагласяния, и не е скалируемо.

Ще ти дам пример с работеща инфраструктора с 30+ дейтабейс шарда и около 2ТБ база (60-70GB на шард) и защо не е "тъпо". Ако е нужно скалиране се добавя нов шард - когато записите в текущите станат прекалено много. Има тригер изчислен според момент, в който перформънса пада. Дори не са в мастър-мастър конфигурация, а мастър-слейв. Всеки шард има по един мастър с 2 или повече слейва. Четенето и писането са разделени, тъй като профила на софтуера е с повече четене. Става автоматично, он деманд през Kubernetes.

Проблем с пропъртитата не виждам, това е чисто програмистки казус.

Решения има много. Човека трябва да проучи и да избере кое е най-подходящото за него. ;)
 
Определено някакъв по-прост вариант се търси. Говорим за мрежа от не толкова големи сайтове на споделен хостинг и без допълнителни изисквания. Мастър-слейв ми се струва най-удачния вариант към момента.
 
Привет, колеги, нямам много време да пиша тук защото работя доста, ако трябва да правя мрежа от 20 онлайн магазина от всички мнения бих взел на @Уърдпреско , честно казано реално бих ползвал konghq, никога не бих ползвал само един сървър защото съм виждал какво става при ползването на един сървър. Виждал съм как се мятат 10 TB за доставчици и проверки от физични магазини един сървър е лоша идея, а това което @ReminD, имаш базови познания за малки проекти, при големи няма как да стане тази логика, преди да ме нападаш си спомни за твоят проекта който ми показа. :) Да кажем че и не правиш разлика межу LIKE и FULL TEXT. Не знам от къде идва всичката тази омраза, но трябва да спреш и да насочиш силата си някъде другаде, към мен няма смисъл. Нямам нищо лично към теб или sky, но виждам че ти и sky явно сте ми фенове и всеки мой коментар получава негативен коментар от Вас, влагате енергия в нещо безсмислено.


Сега към автора за по-прост вариант, изкарай всичко през едни адреси от главният магазин под формата на чист feed data. Намери модул за импорт на данни за дадената система която ще ползваш, правиш мапинг на колоните. Вкарваш данните и ползваш един cron job през 6 часа да прави проверка.


Поздрави,
Станимир
 
Цъ няма да стане така. Нещо се губи обратната връзка така.
Търся идеи за конкретен сценарий, а не "хващаш едни данни и мяташ". То това е ясно. За 6ч могат да се променят много неща.
Да припомня отново в моя случай търся решение, което да работи добре на споделен хостинг.
 
Къв сценаий търсиш като не си казал тия магазини на какво ще ги вдигаш?
Ако ще са нови магазини - една база и да дърпат продуктите от нея. Всичко останало си е локално за всеки магазин.
 

Горе