چگونه کش CDN را purge کنیم بدون خراب کردن سایت

چرا edge هنوز فایل قدیمی را سرو می‌کند

وقتی بازدیدکننده‌ای فایلی را درخواست می‌کند، نزدیک‌ترین مکان edge بررسی می‌کند که آیا نسخه‌ی معتبری از آن دارد یا نه. اگر داشته باشد، بدون پرسیدن از سرور شما بی‌درنگ پاسخ می‌دهد — کل فلسفه‌ی وجودی یک CDN همین است و به همین دلیل سایت شما سریع است. اینکه «معتبر» چقدر طول می‌کشد، از هدرهای کش تعیین می‌شود که مبدأ شما هنگام نخستین دریافت فایل توسط edge فرستاده است؛ اغلب Cache-Control: max-age.

پس وقتی نسخه‌ی تازه‌ای آپلود می‌کنید و هنوز نسخه‌ی قدیمی را می‌بینید، چیزی خراب نشده است. شما فایل را روی مبدأ عوض کرده‌اید، اما edge هنوز داخل همان بازه‌ای است که خودتان گفته بودید نسخه‌ی قبلی را نگه دارد. سه راه بیرون آمدن دارید: صبر کنید تا منقضی شود، همین حالا آن را purge کنید، یا زیر یک URL تازه منتشر کنید تا اصلاً چیز کهنه‌ای برای سرو کردن نباشد. اینکه کدام را باید انتخاب کنید، موضوع ادامه‌ی این راهنماست.

دقیق، prefix، variants — کوچک‌ترین چکش را بردارید

یک purge دقیق فقط یک URL مشخص را حذف می‌کند. این پیش‌فرض درست است: شما /images/hero.jpg را عوض کرده‌اید، پس همان /images/hero.jpg را purge می‌کنید. دقیق، آنی، و بقیه چیزها گرم می‌مانند.

یک purge از نوع prefix همه چیز را زیر یک مسیر حذف می‌کند — مثلاً /assets/ هر فایل زیر خودش را پاک می‌کند. بعد از انتشاری که یک دایرکتوری کامل را بازنویسی کرده از آن استفاده کنید. قدرتمند است، پس با دقت نشانه بگیرید: purge کردن /images/ به این دلیل که یک لوگو عوض شده، هزاران object کش‌شده‌ی مفید را دور می‌ریزد.

یک purge از نوع variants هر نسخه‌ی کش‌شده از همان کلید را پاک می‌کند. Edge ممکن است چند نسخه از یک URL نگه دارد — فشرده و فشرده‌نشده، یا variantهای دستگاه‌های مختلف — و اگر فایل زیرین را عوض کنید می‌خواهید همه‌ی آن‌ها بروند، نه فقط آنکه اتفاقاً با مرورگر خودتان مطابقت دارد. این همان گزینه‌ای است که مردم فراموشش می‌کنند وقتی purge برای بعضی بازدیدکنندگان «کار نکرد» اما برای خودشان کار کرد.

همان سه انتخاب، از خط فرمان

# one URL (the usual case)
cdnctl purge --account <uuid> --path /images/hero.jpg

# several at once
cdnctl purge --account <uuid> --paths "/css/app.css,/js/app.js"

# everything under a folder
cdnctl purge --account <uuid> --path /assets --type prefix

# every cached variant of one key
cdnctl purge --account <uuid> --path /index.html --type variants

# save this list to re-run after future deploys
cdnctl purge --account <uuid> --paths "/,/sitemap.xml" --save

چه زمانی همه چیز را purge کنیم (و چه هزینه‌ای دارد)

Purge کردن کل کش حساب، بعد از یک تغییر سراسری انتخاب درستی است: یک طراحی تازه، ویرایش قالبی که همه‌ی صفحات را لمس می‌کند، یا مهاجرت CMS. یک دستور است و درباره‌ی کاری که می‌کند صادق است — همه چیز می‌رود.

اما اول هزینه را بدانید. مدتی پس از یک purge کامل، edge چیزی در دست ندارد، پس درخواست‌هایی که پیش‌تر نزدیک کاربر پاسخ داده می‌شدند حالا تا مبدأ شما سفر می‌کنند. سایتی که پشت کش با آسودگی ده درخواست در ثانیه سرو می‌کند ممکن است ناگهان با همه‌ی آن‌ها یک‌جا روبه‌رو شود. روی یک مبدأ کوچک، این تفاوت میان سریع بودن و به‌زحمت افتادن است. چون این ابزار عمداً بی‌ظرافت است، خط فرمان از شما تأیید می‌خواهد.

تأیید صریح لازم است — و این عمدی است

# clear the whole account cache
cdnctl purge all --account <uuid> --yes

# watch it complete
cdnctl purge all status --account <uuid>

آن purgeای که هرگز لازم نیست اجرا کنید

بهترین راهبرد invalidation این است که به آن نیاز نداشته باشید. اگر نام یک فایل هر بار که محتوایش عوض می‌شود تغییر کند — app.a1b2c3.js، style.9f8e7d.css — آن‌وقت هر انتشار، URLهای تازه منتشر می‌کند. نسخه‌های قدیمی هنوز کش‌شده‌اند، بی‌آزار و بدون ارجاع؛ نسخه‌های تازه هرگز کش نشده‌اند، پس هر بازدیدکننده بی‌درنگ نسخه‌ی جدید را می‌گیرد. هر ابزار بیلد مدرنی این کار را برای شما انجام می‌دهد، و به همین دلیل است که کش assetها را می‌توان با خیال راحت روی یک سال گذاشت.

آنچه می‌ماند فایل‌هایی هستند که نامشان نمی‌تواند عوض شود: صفحات HTML شما، /sitemap.xml، robots.txt و فیدهای JSON. به آن‌ها یک max-age کوتاه بدهید تا خودشان تازه شوند، و هر وقت لازم بود تغییر بی‌درنگ دیده شود، صراحتاً purgeشان کنید. در عمل، یک راه‌اندازی سالم بعد از هر انتشار مشتی مسیر را purge می‌کند، نه هزاران مسیر را.

چرا به‌نظر می‌رسد purge کار نکرده است

تقریباً هر گزارش «purge هیچ کاری نکرد» یکی از چهار حالت است، و هیچ‌کدام به معنای اشتباه بودن edge نیست.

مرورگر خودتان هم آن را کش کرده است. Cache-Control برای مرورگر هم صدق می‌کند؛ edge تازه است اما لپ‌تاپ شما نه. پیش از بالا بردن ماجرا، در یک پنجره‌ی ناشناس یا با یک query string ضدکش بررسی کنید.

URL دیگری غیر از آنچه سرو می‌شود را purge کرده‌اید. /page و /page/ می‌توانند کلیدهای کش جداگانه باشند، همان‌طور که نسخه‌های http و https، یا URLی با پارامترهای ردیابی چسبیده به آن. همان URLی را purge کنید که کاربران‌تان واقعاً درخواست می‌کنند.

فقط یک variant را purge کرده‌اید. نسخه‌های فشرده و فشرده‌نشده‌ی یک فایل، ورودی‌های جداگانه‌اند — اگر بعضی بازدیدکنندگان نسخه‌ی تازه را می‌بینند و بعضی نه، با نوع variants purge کنید.

یا مبدأ دوباره همان فایل قدیمی را سرو کرده است. Purge فقط به edge می‌گوید فراموش کن؛ درخواست بعدی دوباره از سرور شما گرفته می‌شود. اگر کش خود اپلیکیشن یا افزونه‌ی شما هنوز صفحه‌ی قدیمی را نگه داشته باشد، edge وفادارانه همان نسخه‌ی کهنه را دوباره کش می‌کند. اول کش اپلیکیشن را پاک کنید، بعد edge را purge کنید.

بخشی از فرایند انتشار، نه چیزی که باید یادتان بماند

Purge دستی بعد از هر انتشار، مرحله‌ای است که بالاخره کسی فراموشش می‌کند، معمولاً در همان انتشاری که اهمیت داشت. آن را داخل خط لوله بگذارید: پس از موفقیت انتشار، برای همان مشت مسیری که نامشان هرگز عوض نمی‌شود یک purge اجرا کنید. روی cdn.com.tr می‌توانید این کار را از پنل، از طریق REST API، یا با cdnctl در یک job مربوط به CI انجام دهید — همان دستور، چه از ترمینال شما اجرا شود چه از یک runner. فهرست‌های مسیر ذخیره‌شده (--save) این را به یک تک‌خطی تبدیل می‌کنند که نگه می‌دارید، به‌جای فهرستی که هر بار دوباره تایپ می‌کنید.