ЕО
Если нет целеполагания, то ничего не имеет значения. Не бывает ничего идеального, инструменты нужно под задачи выбирать
map slice + mutex, sync.Map
На го редис юзать для кеша - моветон
Size: a a a
2020 July 23
J
Мимо Проходящий
сам придумал? как раз в го не самая лушая реализация мапы для кэша, от банального не thread safety, до нагрузки на GC
и когда у нас есть десяток решений со своими нюансами типа https://github.com/allegro/bigcache
может быть не такой уж и моветон заюзать уже масштабируемое решение redis?) особенно если инстансов больше одного
и когда у нас есть десяток решений со своими нюансами типа https://github.com/allegro/bigcache
может быть не такой уж и моветон заюзать уже масштабируемое решение redis?) особенно если инстансов больше одного
DM
сам придумал? как раз в го не самая лушая реализация мапы для кэша, от банального не thread safety, до нагрузки на GC
и когда у нас есть десяток решений со своими нюансами типа https://github.com/allegro/bigcache
может быть не такой уж и моветон заюзать уже масштабируемое решение redis?) особенно если инстансов больше одного
и когда у нас есть десяток решений со своими нюансами типа https://github.com/allegro/bigcache
может быть не такой уж и моветон заюзать уже масштабируемое решение redis?) особенно если инстансов больше одного
а где лучшая реализация мапы?
АП
сам придумал? как раз в го не самая лушая реализация мапы для кэша, от банального не thread safety, до нагрузки на GC
и когда у нас есть десяток решений со своими нюансами типа https://github.com/allegro/bigcache
может быть не такой уж и моветон заюзать уже масштабируемое решение redis?) особенно если инстансов больше одного
и когда у нас есть десяток решений со своими нюансами типа https://github.com/allegro/bigcache
может быть не такой уж и моветон заюзать уже масштабируемое решение redis?) особенно если инстансов больше одного
sync map же есть :D
АП
но меня сейчас проклянут
МП
сам придумал? как раз в го не самая лушая реализация мапы для кэша, от банального не thread safety, до нагрузки на GC
и когда у нас есть десяток решений со своими нюансами типа https://github.com/allegro/bigcache
может быть не такой уж и моветон заюзать уже масштабируемое решение redis?) особенно если инстансов больше одного
и когда у нас есть десяток решений со своими нюансами типа https://github.com/allegro/bigcache
может быть не такой уж и моветон заюзать уже масштабируемое решение redis?) особенно если инстансов больше одного
"Нагрузка на гц" - это выдумки, либо говнокод. Ни разу не сталкивался с кейсом чтобы гц был узким местом. Потокобезопасная мапа тоже есть, учите матчасть. Вот только она не нужна
AC
имхо — редис превосходное хранилище для мульти-процессовых/распределённых приложений по типа key-value.
Также, зашло использование редиска в качестве своебразного лока (redlock) ресурсов, опять-таки, в распределённых/мульти-процессовых прилогах.
Редис используют как брокер результата в отложенных задачах.
Те, кто ругают редис, за то что он не персистентный — ну так он не для этого нужен. Если вы пытаетесь забить гвоздь отвёрткой, это не значит что отвёртка плохая.
Также, зашло использование редиска в качестве своебразного лока (redlock) ресурсов, опять-таки, в распределённых/мульти-процессовых прилогах.
Редис используют как брокер результата в отложенных задачах.
Те, кто ругают редис, за то что он не персистентный — ну так он не для этого нужен. Если вы пытаетесь забить гвоздь отвёрткой, это не значит что отвёртка плохая.
МП
Эм, а вы знаете, что мап не шринкается?
И не обязана, да и не нужно. Память отдаётся блоками, и в управляемых средах в т. ч.
DP
коллеги
использование кеша тянет за собой проблему его инвалидации. которая, как известно, одна из самых сложных
поэтому, следует избегать кешей, где только возможно
и как только вы начинаете кешей избегать - оказывается, что они и не нужны
использование кеша тянет за собой проблему его инвалидации. которая, как известно, одна из самых сложных
поэтому, следует избегать кешей, где только возможно
и как только вы начинаете кешей избегать - оказывается, что они и не нужны
ЕО
коллеги
использование кеша тянет за собой проблему его инвалидации. которая, как известно, одна из самых сложных
поэтому, следует избегать кешей, где только возможно
и как только вы начинаете кешей избегать - оказывается, что они и не нужны
использование кеша тянет за собой проблему его инвалидации. которая, как известно, одна из самых сложных
поэтому, следует избегать кешей, где только возможно
и как только вы начинаете кешей избегать - оказывается, что они и не нужны
Всё зависит от ожидаемого уровня производительности и модели консистентности конкретных данных
АП
коллеги
использование кеша тянет за собой проблему его инвалидации. которая, как известно, одна из самых сложных
поэтому, следует избегать кешей, где только возможно
и как только вы начинаете кешей избегать - оказывается, что они и не нужны
использование кеша тянет за собой проблему его инвалидации. которая, как известно, одна из самых сложных
поэтому, следует избегать кешей, где только возможно
и как только вы начинаете кешей избегать - оказывается, что они и не нужны
а как же хайлоад? там же кеш априори должен быть ну по гайду если
d
а как же хайлоад? там же кеш априори должен быть ну по гайду если
щас вам скажут, что хайлоада не бывает
C
а как же хайлоад? там же кеш априори должен быть ну по гайду если
у хайлоада чаще проблема с записью, чем с чтением )
ЕО
Хайлоад тут не при чём, можно хайлоад без кеша построить. Важна не нагрузка, а ожидаемое время отклика
DP
а как же хайлоад? там же кеш априори должен быть ну по гайду если
хайлоад - это термин, который придумал олег бунин
C
Хайлоад тут не при чём, можно хайлоад без кеша построить. Важна не нагрузка, а ожидаемое время отклика
вот, да
C
хайлоад - это термин, который придумал олег бунин
ох уж эти маркетологи
МП
коллеги
использование кеша тянет за собой проблему его инвалидации. которая, как известно, одна из самых сложных
поэтому, следует избегать кешей, где только возможно
и как только вы начинаете кешей избегать - оказывается, что они и не нужны
использование кеша тянет за собой проблему его инвалидации. которая, как известно, одна из самых сложных
поэтому, следует избегать кешей, где только возможно
и как только вы начинаете кешей избегать - оказывается, что они и не нужны
У меня 100к юзеров, я при запуске сервиса беру их из бд в мапу и потом ищу юзеров по этой мапе. А иначе пришлось бы на каждый реквест аутентификации идти в бд.
АП
просто бд априори после определенной нагрузки начнет не справляться, по сравнению с "тупым" хранилищем key-value которое отдает тупо обьект целиком собранный