Добавихме L1, L2 и L3 кешове за "по-добра производителност." Сега имаме 3 места, където данните могат да бъдат грешни вместо 1.

Нашата брилянтна архитектура:

  • L1: In-process кеш (Guava)
  • L2: Локален Redis
  • L3: Разпределен Redis клъстер
  • Източник на истина: PostgreSQL

Какво се обърка:

  • L3 кешът се инвалидира правилно
  • L2 кешът все още имаше стари данни (различен TTL)
  • L1 кешът на сървър A имаше стари данни
  • L1 кешът на сървър B имаше нови данни
  • Потребителите виждаха различни данни при всяко опресняване

Ад на дебъгването:

"Кой кеш слой има лошите данни?" ставаше 2-часово разследване всеки път.

Какво научихме:

  • Всеки кеш слой умножава сложността на инвалидиране
  • TTL-овете трябва да са координирани (вътрешен кеш < външен кеш)
  • Нужна е наблюдаемост във всеки слой
  • Понякога един кеш е достатъчен

Урок: Повече кеш слоеве ≠ по-добра производителност. Означава повече места за дебъгване когато нещата се объркат.

← Назад към Научени Уроци

Етикети: #Caching #Architecture #Performance #Debugging