Caching: سینی کنار آشپزخانه — طراحی سیستم نرم‌افزاری

فرض کن در یک رستوران شلوغ کار می‌کنی. هر بار که مشتری آب معدنی یا دسر پرتکرار می‌خواهد، اگر بروی آشپزخانه، صف می‌بندد. پس یک سینی کنار صندوق می‌گذاری و همان چیزهای پرتکرار را آماده نگه می‌داری. مشتری سریع جواب می‌گیرد؛ آشپزخانه نفس می‌کشد. در سیستم به این سینی می‌گویند Cache.

شغل Cache این است که جوابِ گران را در جای ارزان و سریع نگه دارد. درست استفاده شود، بیشتر بار دیتابیس را جذب می‌کند. غلط استفاده شود، غذای کهنه می‌دهی و باگ‌های «گاهی می‌شود» می‌سازی — مشتری یکی قیمت دیروز را می‌بیند، یکی قیمت امروز را.

رستوران و سینی آماده کنار آشپزخانه — آشپزخانه عقب است؛ گارسون اول سینی کنار صندوق را نگاه می‌کند. اگر بود، همان را می‌دهد. اگر نبود، می‌رود آشپزخانه. همان شغل Cache و Miss.

جواب چطور به سینی می‌رسد؟

سه مدل رایج است. فرق‌شان این است کی می‌نویسی، کی می‌خوانی، و اگر سینی وسط کار افتاد چه می‌شود.

Cache-Aside

اپ اول Cache را می‌پرسد. Miss یعنی از DB بخوان و همان‌جا بگذار. وقتی داده عوض شد، کلید را حذف کن — Invalidation — تا خواندن بعدی تازه بسازد. پیش‌فرض عملی بیشتر سیستم‌ها.

Write-Through

هر نوشتن همزمان به Cache و DB می‌رود. سینی همیشه تازه است؛ نوشتن کندتر می‌شود. برای داده‌ای که باید همان لحظه درست باشد و باز هم خوانده شود.

Write-Back

اول فقط Cache، بعداً دسته‌ای به DB. سریع‌ترین نوشتن. اگر Redis وسط کار سقوط کند، آن دسته گم می‌شود. فقط وقتی از دست رفتن چند ثانیه قابل تحمل است.

DIAGRAMCache-Aside — رایج‌ترین الگو

App

→

Cache — Redis

→

DB — فقط در Miss

جا تمام شد، یا غذا کهنه شد

سینی بی‌نهایت نیست. باید بدانی چه چیزی را دور بریزی، و تا کی حق داری همان کپی را بدهی.

TTL

هر کلید یک تاریخ انقضا دارد. ساده‌ترین سلاح علیه کهنگی. کوتاه یعنی تازه‌تر و بار بیشتر روی DB. بلند یعنی ارزان‌تر و کهنه‌تر.

LRU

وقتی جا تمام شد، چیزی را بیرون بینداز که اخیراً کسی سراغش نرفته. پیش‌فرض بیشتر Cache ها.

LFU

چیزی را بیرون بینداز که کلاً کمتر خواسته شده. برای کالای همیشه‌پرتکرار بهتر از LRU است؛ پیاده‌سازی‌اش سنگین‌تر.

سه بلای مشهور و پادزهر

کشِ بد از کشِ نبودن خطرناک‌تر است. این سه تا را اسم بگذار تا وسط حادثه حدس نزنی.

Stampede: یک Hot Key منقضی می‌شود و هزاران درخواست همزمان به DB می‌ریزند. پادزهر: فقط یک درخواست بازسازی کند، بقیه صبر کنند یا مقدار کهنه بگیرند؛ TTL را با jitter — نویز تصادفی — بگذار تا همه با هم نمیرند.
Hot Key: یک پست وایرال، یک کلید. یک Node از Cache می‌سوزد. پادزهر: همان کلید را روی چند Node کپی کن، یا یک Cache محلی کوچک داخل هر Server بگذار.
ناسازگاری Cache و DB: ترتیب درست این است: اول DB را به‌روز کن، بعد کلید را حذف کن — نه اینکه خودت مقدار تازه را در Cache بنویسی. دو نویسنده همزمان مسابقه می‌گذارند. TTL تور ایمنی نهایی است.

به زبان ساده

Cache جواب گران را روی سینی کنار صندوق می‌گذارد تا هر بار تا آشپزخانه — دیتابیس — نروی.

مثال واقعی

صفحه محصول را ۶۰ ثانیه در Redis نگه می‌داری؛ وقتی قیمت عوض شد کلید را پاک می‌کنی تا خواندن بعدی تازه بسازد.