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

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

Предпосылки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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