Мы не много о разном говорим, источник данных один. А приложений которые предоставляет апи может быть много отдельных. Например сервера в разных стойках для резервации. 3 бд инстанса мастер слейв для чтения + слейв без лага для того чтобы в критичной ситуации стать мастером. Плюс три application сервера(контейнера) чтобы при падении хоста у вас ничего не упало. В таком случае кешировать в памяти приложения не получится. Нужен общедоступный кеш)

Когда последний раз имел дело с редисом лет 5 назад, он был дико падучим и рассыпчатым

Или кеш работает синхронно с базой, и запись идет с ее скоростью

и я бы хотел, чтобы была такая либа, чтобы

ребят, а как можно как-нибудь так сделать? var params = make(map[string]interface{}) params["abc"] = struct{ a int b int }потом взять и сделать так params[abs].a = 212есть, конечно, идеи сделать это всё через getParam / setParam(path ...string) но вдруг есть что-то более правильное

Кластер вот относительно недавно у них появился был не стабилен какое-то время. Сейчас более менее. По крайней мере 6(3 master 3 slave) инстансов на одном из микросервисов уже год работают без падений) А не кластерное решение давно вроде работает стабильно, это штука древняя как г мамонта) И нагрузки хорошие держит и масштабируется на раз два)

Масштабируется вертикально?) А что будет если одна из 6 нод ляжет?

В случае с кластером - ничего)

Чтобы построить кластер нужно минимум 6 нод?

3 мастера как я помню минимум) Но от такого толку нет. Хватит наводящих вопросов, давай колись где подколоть хочешь)

у тебя ошибка как минимум в вопросе. params.a у тебя nil (должно быть params.abc.a). Вообще да, лучше через функцию сделать

Да не, просто интересуюсь) слышал, что эта портянка ляжет, если хоть одна нода отвалится.

Да не, просто интересуюсь) слышал, что эта портянка ляжет, если хоть одна нода отвалится.

первые фотки с русского гоферкона https://www.facebook.com/GopherConRu/posts/176133373025765

Всем привет. А ещё конференции есть? )

вот тут что-то планируется

задумался =\ Есть некие объекты и у них есть различные профили (профиль авторизации, профиль настроек, и т.д.) Объекты хранятся в памяти. Сначала хотел также хранить профили в памяти и к каждому объекту цеплять _указатель_ на нужные профили: таким образом при каком-либо изменении профилей объекты трогать не нужно, всё "само обновится" А потом подумал, что программа будет постоянно и непрерывно дёргать и лочить мьютексы одних и тех же профилей (объектов очень много, с ними постоянно что-то делается, а инстансов профилей мало: при каждом действии с каждым из тысяч объектов будут по нескольку раз лочиться-анлочиться мьютексы его профилей) что правильнее в такой ситуации делать?

Использовать реляционную СУБД

Насколько правильно хранить объекты (персистентно хранящиеся в бд) и работать с ними - в памяти, в бд только записывая обновления? Суть: куча объектов (оборудования), постоянно опрашивающегося на предмет кучи параметров. Это уже куча постоянных одинаковых запросов (на один объект - от пары десятков до сотен дочерних объектов) - но это хрен с ним, достаточно безболезненно для бд. Еще это оборудование будет слать логи на сислог и снмп-трапы; какие-то события на оборудовании происходят постоянно, сейчас по нескольку сотен в секунду прилетает - и вот это уже похоже на бессмысленное дрочево БД: гораздо продуктивные было бы держать все в памяти Сейчас еще в голову пришел вариант - простая обёртка над бд, кеширующая в памяти на энное время именно результат запросов (с ключем = мд5 строки запроса, например) Кто как похожие кейсы решает?

Примерно тут

задумался =\ Есть некие объекты и у них есть различные профили (профиль авторизации, профиль настроек, и т.д.) Объекты хранятся в памяти. Сначала хотел также хранить профили в памяти и к каждому объекту цеплять _указатель_ на нужные профили: таким образом при каком-либо изменении профилей объекты трогать не нужно, всё "само обновится" А потом подумал, что программа будет постоянно и непрерывно дёргать и лочить мьютексы одних и тех же профилей (объектов очень много, с ними постоянно что-то делается, а инстансов профилей мало: при каждом действии с каждым из тысяч объектов будут по нескольку раз лочиться-анлочиться мьютексы его профилей) что правильнее в такой ситуации делать?

Имхо кэшами нужно обманываться только когда вы упретесь в производительность базы

Почти гарантированно упрусь сразу, как дам полную нагрузку: если в лоб - то тысячи запросов/сек будут

Слова и предположения — ничто, бенчмарки и метрики — всё

Могу только еще раз подтвердить слова Мерль - без бенчмарков нечего оптимизировать

Ну, хотелось сразу спроектировать с меньшей нагрузкой на бд) Проще ведь это сделать сразу и просто держать нужное в Памяти, чем потом где то сбоку синей изолентой кеш прикручивать)

СтОит сначала проверить, что может сделать сама бд для такого кэша. В mysql он точно есть. И проблема инвалидации там решена

и вообще у меня пг %)

а может вы код накидаете? 🙂

блин, я всего-то спросил "насколько плохо использовать и дёргать МНОГО мьютексов" :)

я конечно не большой спец по мьютексам, но с какого перепугу вложенный профиль будет вообще дергаться