Спільний кеш - найкраща практика інвалідизації

Мені хотілося б знати, що було б кращим підходом до визнання об'єктів кеша недійсним / оновленим.

Передумови

• Маючи віддалений сервер з запам’ятовуванням (служить кешем для декількох додатків)
• Усі сервери розміщуються в лазурі (регіони афінності, однакові центри обробки даних)
• Розмір об'єкта кешу коливається від 200 байт до 50 кілобайт

Підхід 1 (зберігати в кеші якнайшвидше)

1. Об'єкт A створюється -> зберігати в базі даних і зберігати в кеші
2. Об'єкт Запрошений клієнтом -> перевірити кеш на наявність, інакше витягнути з бази даних і зберегти в кеші
3. Об'єкт A оновлюється -> зберігати в базі даних, зберігати в кеші

Підхід 1 здається більш простим. Якщо щось створено, покладіть в кеш як можна швидше. Незалежно від когось це буде потрібно.

Підхід 2 (магазин лінивого кеша)

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

Підхід 2, здається, усвідомлює більше пам'яті. У такому підході в кеш-пам'ять переходять лише запитувані елементи.

Питання 1: Зважаючи на ефективність, який би був кращий підхід? Пам'ять, ні процесор поки не рахуються.

Питання 2: Чи є мої думки своєрідною передчасною оптимізацією?

Питання 3: Будь-які інші думки? Інші підходи?

1. Невимовно, хіба що сказати, що це залежить. Є багато факторів, які визначатимуть, який підхід буде найкращим у вашому випадку, наприклад: Чи нормально для створених об'єктів бути отриманими незабаром після їх створення? Яке відношення оновлень до доступу?
2. Re. вирішити, що вам потрібен кеш: Якщо ви оптимізуєте без даних, то так, це технічно передчасна оптимізація. Я кажу технічно, оскільки досвід / звичайна мудрість може сказати вам, що вам знадобиться якийсь кеш. Re. вирішити, як кеш найкраще працюватиме: так, це безумовно передчасна оптимізація.
3. • Оптимізація часто не полягає у пошуку найкращого / оптимального рішення. Він повинен бути таким:
     1. Знайдіть вузькі місця в системі.
     2. Знайдіть, де ви можете зробити найбільшу різницю за найменший обсяг роботи.
     3. Робіть найменший обсяг роботи!
     4. Це ще досить швидко? Якщо ні, перейдіть до №1.
     5. Готово!
   • Чесно кажучи, жоден із підходів, які ви описуєте, звучить не складно. Чому б не реалізувати обидва і не побачити, що працює найкраще?
   • Крок 3 у підході №2 можна змінити на "Об'єкт A оновлюється -> зберігати в базі даних, оновити запис у кеші".

memcached керує об'єктами з власною політикою, кешований об’єкт закінчується, якщо ніхто не звертається до нього або в пам'яті не вистачає пам'яті. Отже, ваш перший підхід не є гарною ідеєю, оскільки ваш об'єкт, який зберігається в пам’яті, буде недійсним через втрату пам’яті під час створення об’єктів.

Q1. Підхід 2 був би кращим з точки зору продуктивності, оскільки він не надсилає об'єкт до запам’ятовування, хоча покращення продуктивності дуже мало.

Q2. Важко сказати. Припустимо, ви знаєте вузьке місце і розробити підходи, це не було б передчасним.

Q3. Існують й інші підходи, такі як кеш-пам'ять лише в пам'яті.