Комментарии 5
На хабре уже такие банальные вещи публикуются как "навыки от ведущих экспертов".
Это даже на тестовое задание на собеседовании не тянет ИМХО.
И вот это прямо классика накидать кода в котором редиска работает без аутентификации.
На улице точно 2024г?
Понятно, что редис тут только для примера, но всё-таки, было бы интересно посмотреть как бы решалась проблема инвалидации кеша, т.е. мы успели обновить данные в бд, но ещё не успели удалить/обновить их в кеше - в этот момент может прийти запрос и из кеша вернутся неактуальные данные
В случае с map rwmutex себя не оправдывает, обычный будет работать быстрее. RW хорош на длительных операциях чтения, к коим не относится доставание указателя из map. К тому же, обычный лок позволит атомарно затащить в map недостающее значение из бд. А так, да, шаблон хорош, можно подробнее посмотреть в книжке Шаблоны Корпоративных Приложений.
Не очень понятно почему в тегах указана архитектура. Было бы интересно увидеть как решается использования всего это дела в реальном проекте. Как например не забыть пропустить вызов add. А так статья выглядит как "Кеширование для самых маленьких"
// Get возвращает пользователя по ID, если он существует в картеfunc (im *IdentityMap) Get(id int) *User { im.RLock() defer im.RUnlock() return im.users[id]}
При каждом обращении к методу
Getсначала проверяется наличие объекта в карте, и если он есть, возвращаем его, не обращаясь к БД.
А если нет в "карте" то паника?
Должна же быть проверка на ошибку в Get. Потом если в кеше нет, обратится к БД. И там тоже обработать все возможные ошибки и т.п.
Паттерн Identity Map в Golang