Я знаю что такое кластер, если мы говорим про приложение. Но мне кажется парни о другом, о распределенном хранилище.

автоматичное включение в класстер, всякие там выбор мастера

ну ты как минимум можешь разными путями строить кластер.

хазелькаст тебе дает дискавери для нод, а дальше на сколько я понял он просто отправляет команды на ноды

типа прищел запрос, отправили какой-нибудь ноде.

сначала netty

потом zeromq

ну ок ок, закидали

Раз уж про HZ говорите cc меня

@gamussa ну так вот, разве в хз есть замена функционала консула?

хазелькаст тебе дает дискавери для нод, а дальше на сколько я понял он просто отправляет команды на ноды

Дискавери, файловер, шардинг

И какой там консенсус и тип хранилища согласно cap теореме.

@HeapyHop ты когда-то работаешь вообще?)

@gamussa ну так вот, разве в хз есть замена функционала консула?

Нет, но в HZ можно делать дискавери через консул

@HeapyHop ты когда-то работаешь вообще?)

С утра поработал, можно и потрындеть)

И какой там консенсус и тип хранилища согласно cap теореме.

Даже не начинай про cap теорему

Нет, но в HZ можно делать дискавери через консул

ну там же несколько дискавери протоколов, юникаст, мультикаст

и тд

Даже не начинай про cap теорему

Ага, я помню) По сути у вас AP

Ага, я помню) По сути у вас AP

It сильно depends

Ну основной юзкейс

В зависимости какой api используешь

А что у вас для CP есть? Что используете?

Нет. У них свое. И по разговорам не оч хорошо работает

оно нормально работает, просто низкоуровневое относительно

При сплитбрейне можно настроить cp и ap

При сплитбрейне можно настроить cp и ap

а как к слову?

А что у вас для CP есть? Что используете?

есть quorum для IMap и icache.

Поверх чего кворум?

Поверх чего кворум?

Все свое

Всмысле) Какой алгоритм используете

Или у вас свои статьи есть на эту тему?

Всмысле) Какой алгоритм используете

Там простой алгоритм На основе кол-ва нод.

На практике чем проще тем лучше

Ну это значит что у вас нету CP

Мы же не бежим поверх wan

Ну это значит что у вас нету CP

Поставил диагноз По фотографии в паспорте

Потому что у вас нету хотя бы формального доказательства что ваш алгоритм работает)

Потому что у вас нету хотя бы формального доказательства что ваш алгоритм работает)

Ну ок, опять теоретики от CS будут мне рассказывать как продавать хазелкаст

Это ничего страшного

Не, продавать ты конечно можешь и без этого

я кароч пилю так, у меня CI билдит проект, распихивает сервисы по докер имейджам, пушит их на docker-hub на тест сервере, через docker pull %image name% и docker compose все поднимается. В итоге получается кластер из N количества микросервисов. Собственно все отлично. Теперь встал вопрос динамичности масштабирование кластера и его отказоустойчивости. т.е например имеем проект микросервистной архитектуры и N колличество физических серверов для размещения на них кластера, Кластер деплоится на сервера, с 1 экземпляром каждого микросервиса, и по мере роста нагрузки на кластер будут созданы копии нагруженных сервисов и переданы данных о них в route ballance. В случаее если нагрузка упала мы убиваем копию или несколько копий микросервиса, дабы освободить вычеслительные мощностя. Тот же подход и обратим в случее падения одного из физических серверов. А теперь ряд вопросов. Стоит ли вообще заморачиваться с таким discovery сервером? Если да, то как быть с доступом к едином БД. я не хочу открывать сессию с бд для кадой копии микросервиса, что бы потом на нагрузочном тестировании увидеть N+ сессий

я кароч пилю так, у меня CI билдит проект, распихивает сервисы по докер имейджам, пушит их на docker-hub на тест сервере, через docker pull %image name% и docker compose все поднимается. В итоге получается кластер из N количества микросервисов. Собственно все отлично. Теперь встал вопрос динамичности масштабирование кластера и его отказоустойчивости. т.е например имеем проект микросервистной архитектуры и N колличество физических серверов для размещения на них кластера, Кластер деплоится на сервера, с 1 экземпляром каждого микросервиса, и по мере роста нагрузки на кластер будут созданы копии нагруженных сервисов и переданы данных о них в route ballance. В случаее если нагрузка упала мы убиваем копию или несколько копий микросервиса, дабы освободить вычеслительные мощностя. Тот же подход и обратим в случее падения одного из физических серверов. А теперь ряд вопросов. Стоит ли вообще заморачиваться с таким discovery сервером? Если да, то как быть с доступом к едином БД. я не хочу открывать сессию с бд для кадой копии микросервиса, что бы потом на нагрузочном тестировании увидеть N+ сессий

БД в таких случаях тоже скейлят

Не, продавать ты конечно можешь и без этого

Ты меня добавишь в стикерпак?

О, и Гамов тут

БД в таких случаях тоже скейлят

смотрел как то лекцию от джоша лонга из pivotal он советует вообще использовать отдельную бд для каждого сервиса. но что то шляпа какая то

Ты меня добавишь в стикерпак?

Давай фотку - добавлю

Ты меня добавишь в стикерпак?

А ты почитай про рафт хотя-бы) http://raft.github.io/ Будешь хотя бы рассказывать чем ваш выбор лидера отличается от рафтового)

БД в таких случаях тоже скейлят

по работе с бд опыта маловато. Ты подразумеваешь, делать репликацию, и деркать инфу из слейвов и писать в мастер?

Давай фотку - добавлю

Давай вот эту https://www.dropbox.com/s/x9q514dkbhoajm2/SR1A9807.jpg?dl=0 На ????

А ты почитай про рафт хотя-бы) http://raft.github.io/ Будешь хотя бы рассказывать чем ваш выбор лидера отличается от рафтового)

Я знаю про рафт. Я как-нибудь в подкасте расскажу про всё это.

по работе с бд опыта маловато. Ты подразумеваешь, делать репликацию, и деркать инфу из слейвов и писать в мастер?

у тебя ноды сидят за балансировщиком, балансировщик принимает запросы и распределяет их между нодами?

да

аналогично делается с БД

Я знаю про рафт. Я как-нибудь в подкасте расскажу про всё это.

Сходи в девзен расскажи))

ERROR: S client not available

да

если операции чтения - то всё ок, если на запись, то начинается гимор, это отдельная наука как заскейлить БД

если операции чтения - то всё ок, если на запись, то начинается гимор, это отдельная наука как заскейлить БД

Спасибо за инфу, было бы неплохо если бы скинул пару ссылок на почитать

да

1) посмотри лекцию: https://www.youtube.com/watch?v=-W9F__D3oY4 2) если не хочешь становиться убер-экспертом в скейлинге БД - я бы советовал юзать готовые решения на AWS

Я знаю про рафт. Я как-нибудь в подкасте расскажу про всё это.

а можешь в каком-нибудь подкасте пропиарить этот чат????

Сходи в девзен расскажи))

У меня свое шоу!

а можешь в каком-нибудь подкасте пропиарить этот чат????

Обязательно

Уже пропиарил в твиторе backedsecret. Кстати, сходите туда. Я там на этой неделе http://backendsecret.ru

О, я тоже был в секрете, из-за него опять завел твиттер. Только тупил, потому что в свое время твиттер был намного понятнее)

Уже пропиарил в твиторе backedsecret. Кстати, сходите туда. Я там на этой неделе http://backendsecret.ru

спасибо, еще бы этот божественный твит найти)

https://twitter.com/backendsecret/status/807211857207508992

я надеюсь мой стикер теперь используется по назначению - как троллфейс?

почему черно-белый? что случилось?

ну в оригинале фотка может и цветная, но выложили чёрно-белую. фиг знает, может что с выдержкой фотограф намудрил

надо этот стикер-пак распечатать и на конференции в подарок выдавать участникам)

спикер-пак

надо этот стикер-пак распечатать и на конференции в подарок выдавать участникам)

наклеивать на участников

выражать эмоции стикерами

за каждым стикетом таки должна стоять эмоция. Грусть, злость, радость, троллфейс…

хреновый доклад -

сложна -

отлично, еще 3 частника

и в этом чате будет 800 членов!