Shared Cache - Лучшая практика недействительности


14

Я хотел бы знать, как лучше подходить для аннулирования / обновления объектов кэша.

Предпосылки

  • Наличие удаленного сервера memcached (служит кешем для нескольких приложений)
  • Все серверы размещены на Azure (аффинные регионы, одни и те же центры обработки данных).
  • Размер объекта кэша варьируется от 200 байт до 50 килобайт


Подход 1 (хранить в кеше как можно скорее)

  1. Объект A создан -> сохранить в базе данных и сохранить в кэше
  2. Объект A запрошенный клиентом -> проверить кеш на наличие, в противном случае получить из базы данных и сохранить в кеше
  3. Объект А обновляется -> хранить в базе данных, хранить в кэше

Подход 1 кажется более простым. Если что-то создано, поместите в кэш как можно скорее. Независимо от того, кому-то это понадобится.


Подход 2 (хранилище ленивых кешей)

  1. Объект А создан -> сохранить в базе данных
  2. Объект A запрошенный клиентом -> проверить кеш на наличие, в противном случае получить из базы данных и сохранить в кеше
  3. Объект А обновляется -> хранить в базе данных, удалять ключ в кеше

Подход 2, кажется, больше учитывает память. При таком подходе в кеш попадают только запрашиваемые элементы.


Вопрос 1: С точки зрения производительности, что будет лучшим подходом? Память ни CPU пока не в счет.

Вопрос 2: Являются ли мои мысли своего рода преждевременной оптимизацией?

Вопрос 3: Есть еще мысли? Другие подходы?

Ответы:


12
  1. Не несет ответственности, кроме как сказать, что это зависит. Существует множество факторов, которые определяют, какой подход будет наилучшим в вашем случае, например: нормально ли, что созданные объекты извлекаются вскоре после их создания? Каково соотношение обновлений к доступам?
  2. Число рейнольдса решив, что вам нужен кеш: если вы оптимизируете без данных, то да, это технически преждевременная оптимизация. Я говорю технически, поскольку опыт / общепринятая мудрость может сказать вам, что вам понадобится какой-то тайник. Число рейнольдса решить, как кеш будет работать лучше: да, это определенно преждевременная оптимизация.
    • Оптимизация часто не сводится к поиску лучшего / наиболее оптимального решения. Это должно идти следующим образом:
      1. Найдите узкие места в системе.
      2. Найдите, где вы можете добиться наибольшей разницы с наименьшим количеством работы.
      3. Делай наименьшее количество работы!
      4. Это достаточно быстро еще? Если нет, перейдите к # 1.
      5. Выполнено!
    • Честно говоря, ни один из описанных вами подходов не кажется сложным. Почему бы не реализовать оба и посмотреть, что работает лучше всего?
    • Шаг 3 в подходе № 2 можно изменить на «Объект A обновляется -> сохранить в базе данных, обновить запись в кэше».

Бакета, спасибо за ваш ответ. Я ценю это.
lurkerbelow

@ lurkerbelow Рад помочь.
vaughandroid

2

memcached управляет объектами с помощью собственной политики, срок действия кэшированного объекта которой истекает, если к нему никто не обращается, или в memcached не хватает памяти. Поэтому ваш первый подход не очень хорошая идея, так как ваш объект в memcached будет оставаться недействительным из-за нехватки памяти при создании объектов.

Q1. Подход 2 был бы лучше с точки зрения производительности, потому что он не отправляет объект в memcached, хотя улучшение производительности очень мало.

Q2. Сложно сказать. Предположим, вы знаете узкое место и наметите подходы, которые не будут преждевременными.

Q3. Есть другой подход, такой как кеш, только в memcached.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.