S
Ну я спрашиваю как лучше организовать - свою идею я выше изложил - через мариядб, реплика и там мьютексы складывать. Но надо же еще как то определять что вторая сторона померла и теперь резерв становится главным
Size: a a a
2020 December 09
N
а что мешает прямо в keydb мьютексы складывать? Зачем марию сюда тащить?
N
Если уж и тащить что - то нечто вроде консула, там и хелсчеки и мьютексы и вообще полный набор дискаверинга.
S
Негарантированная доставка. Для данных это пойдет, а вот для работы самой системы уже врятли
N
Или они могут одновременно разгребать списки, но я так понимаю надо как то в рантайме чтобы они договаривались об этом, и мне кажется что это сложней
я бы посмотрел как работает LPOP в условиях мультимастера. Не исключено что он ртработает как надо и там вообще ничего не надо будет выдумывать
S
Мне уже советовали зукипер, но я пока с трудом представляю как их уложить в текущую архитектуру
N
Мне уже советовали зукипер, но я пока с трудом представляю как их уложить в текущую архитектуру
для начала просто регистрировать сервисы и опредлять по нему кто главный, за счет этого обеспечивать монопольный доступ для произвольного количества обработчиков. Ну или просто мьютексы на его основе лепить
S
я бы посмотрел как работает LPOP в условиях мультимастера. Не исключено что он ртработает как надо и там вообще ничего не надо будет выдумывать
Ну если они оба сделают LPOP с одним и тем же элементом в очереди, то ничего страшного не произойдет - второй просто сгенерирует ошибку при попытке передать дальше. Но если между LPOP отработается удаление элемента на втором сервере, то произойдет двойной вызов операторов коллцентра, а это уже плохо
S
А исходя из моего опыта то что можей пойти не так, точно пойдет по такому сценарию
S
для начала просто регистрировать сервисы и опредлять по нему кто главный, за счет этого обеспечивать монопольный доступ для произвольного количества обработчиков. Ну или просто мьютексы на его основе лепить
Это я и так знаю из теории. Я надеялся на более практические советы - кто как такую задачу решал
N
чаще всего такой демонец, который архитектурно может работать только в одном экземпляре, запускается в одном экземпляре и дело с концом. После первого инцедента пересматривается архитектура. Это чисто практика.
S
чаще всего такой демонец, который архитектурно может работать только в одном экземпляре, запускается в одном экземпляре и дело с концом. После первого инцедента пересматривается архитектура. Это чисто практика.
Ну у нас так сейчас и работает в другом месте. Там можно было архитектурно уйти от проблемы монопольного доступа. В данном же случае надо именно такое решение. И одна копия скрипта не вариант - потому что ручное переключение в случае аварий и тд, а я такое не люблю. Максимум автоматизации
N
самый чистый способ - делать lpop напрямую. И если мультимастер не может обеспечить атомарность этой операции - то нафиг такой мультимастер :)
S
Ну я поэтому и не рассматриваю особо варианта с тем что они параллельно работают с базой keydb. А вот горячий резерв все же нужен
N
смысла нет в горячем резерве. Если чекать записи из keydb в mariadb - там, кстати, тоже мультимастер? :)
- то проще их в марию сразу и класть
- то проще их в марию сразу и класть
S
Под мою задачу подходит keydb. Мария - нет
N
Переслано от ShadoWalkeR
Ну я спрашиваю как лучше организовать - свою идею я выше изложил - через мариядб, реплика и там мьютексы складывать. Но надо же еще как то определять что вторая сторона померла и теперь резерв становится главным
S
Имею в виду с теми данными которые в кейдб
S
Заменить на марию не получится
SA
Всем привет!
Подскажите, пожалуйста, как правильно организовать архитектуру пуш сервиса (high load)?
Подскажите, пожалуйста, как правильно организовать архитектуру пуш сервиса (high load)?