لماذا ما زال الـ edge يقدّم الملف القديم
حين يطلب زائر ملفًا، يتحقّق أقرب موقع edge مما إذا كان يحتفظ بنسخة صالحة. فإن كان كذلك أجاب فورًا دون سؤال خادمك — وهذا هو جوهر عمل الـ CDN، وهو سبب سرعة موقعك. أما مدة "الصلاحية" فتأتي من رؤوس التخزين المؤقت التي أرسلها خادمك الأصلي حين جلب الـ edge الملف أول مرة، وغالبًا Cache-Control: max-age.
لذا حين ترفع نسخة جديدة وتظل ترى القديمة، فلا شيء معطّل. لقد غيّرت الملف على الخادم الأصلي، لكن الـ edge ما زال داخل النافذة التي طلبت منه الاحتفاظ بالنسخة السابقة خلالها. أمامك ثلاثة مخارج: انتظار انتهاء الصلاحية، أو التفريغ الآن، أو النشر على رابط جديد فلا يبقى شيء قديم ليُقدَّم. وأيّها تختار هو موضوع بقية هذا الدليل.
دقيق أم بادئة أم متغيّرات — اختر أصغر مطرقة
يزيل التفريغ الدقيق رابطًا واحدًا محدّدًا. وهذا هو الخيار الافتراضي الصحيح: استبدلت /images/hero.jpg، فتفرّغ /images/hero.jpg. دقيق وفوري، ويبقى كل ما عداه ساخنًا.
ويزيل تفريغ البادئة كل ما تحت مسار — فـ /assets/ تمسح كل ملف تحتها. استخدمه بعد نشر أعاد كتابة مجلد كامل. إنه قوي، فصوّب بعناية: تفريغ /images/ لأن شعارًا واحدًا تغيّر يرمي آلاف الكائنات المخزَّنة المفيدة.
أما تفريغ المتغيّرات فيمسح كل نسخة مخزَّنة من المفتاح نفسه. فقد يحتفظ الـ edge بعدة نسخ لرابط واحد — مضغوطة وغير مضغوطة، أو متغيّرات أجهزة مختلفة — وإن استبدلت الملف الأساسي فأنت تريد اختفاءها جميعًا، لا تلك التي تصادف مطابقتها لمتصفحك أنت. وهذا هو الخيار الذي يفوت الناس حين "لا ينجح" التفريغ لدى بعض الزوّار بينما ينجح لديهم.
الخيارات الثلاثة نفسها من سطر الأوامر
# 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
متى تفرّغ كل شيء (وما تكلفة ذلك)
تفريغ ذاكرة الحساب كاملةً هو القرار الصحيح بعد تغيير يشمل الموقع كله: إعادة تصميم، أو تعديل قالب يمسّ كل صفحة، أو ترحيل نظام إدارة محتوى. إنه أمر واحد وصريح فيما يفعله — كل شيء يختفي.
لكن افهم التكلفة أولًا. فلبعض الوقت بعد تفريغ كامل، لا يحتفظ الـ edge بشيء، فتسافر الطلبات التي كانت تُجاب قرب المستخدم إلى خادمك الأصلي. وموقع يخدم عشرة طلبات في الثانية بارتياح خلف الذاكرة المؤقتة قد يواجه فجأة كل هذه الطلبات دفعةً واحدة. وعلى خادم أصلي صغير، هذا هو الفرق بين السرعة والتعثّر. ولأن الأداة فظّة عن قصد، يطلب منك سطر الأوامر تأكيدًا.
التأكيد الصريح مطلوب — وهذا مقصود
# clear the whole account cache
cdnctl purge all --account <uuid> --yes
# watch it complete
cdnctl purge all status --account <uuid>
التفريغ الذي لن تضطر لتشغيله أبدًا
أفضل استراتيجية إبطال هي ألّا تحتاج إليها. فإن كان اسم الملف يتغيّر كلما تغيّر محتواه — app.a1b2c3.js، style.9f8e7d.css — فإن كل نشر ينشر روابط جديدة. تبقى الروابط القديمة مخزَّنة، غير ضارّة وغير مشار إليها؛ أما الجديدة فلم تُخزَّن قط، فيحصل كل زائر على النسخة الجديدة فورًا. وكل أداة بناء حديثة تفعل هذا نيابةً عنك، ولهذا يمكن ضبط تخزين الأصول مؤقتًا لسنة كاملة بأمان.
يبقى الملفات التي لا يمكن أن تتغيّر أسماؤها: صفحات HTML، و/sitemap.xml، وrobots.txt، وتغذيات JSON. امنحها max-age قصيرًا لتتحدّث من تلقاء نفسها، وفرّغها صراحةً حين تحتاج أن يظهر التغيير فورًا. وعمليًا، تفرّغ الإعدادات السليمة حفنة مسارات بعد النشر، لا آلافًا.
لماذا يبدو أن التفريغ لم ينجح
تقريبًا كل بلاغ بأن "التفريغ لم يفعل شيئًا" هو واحد من أربعة أسباب، وليس أيٌّ منها خطأً في الـ edge.
متصفحك أنت خزّنه أيضًا. فـ Cache-Control ينطبق على المتصفح كذلك؛ الـ edge محدّث لكن حاسوبك ليس كذلك. تحقّق في نافذة خاصة أو باستخدام معامل استعلام يكسر الذاكرة المؤقتة قبل التصعيد.
فرّغت رابطًا غير الذي يُقدَّم فعلًا. فقد يكون /page و/page/ مفتاحي ذاكرة مؤقتة منفصلين، وكذلك نسختا http وhttps، أو رابط تُلحق به معاملات تتبّع. فرّغ الرابط الذي يطلبه مستخدموك فعلًا.
فرّغت متغيّرًا واحدًا. فالنسخ المضغوطة وغير المضغوطة من الملف نفسه مدخلات منفصلة — وإن رأى بعض الزوّار النسخة الجديدة ولم يرها آخرون، ففرّغ بنوع variants.
أو أن الخادم الأصلي قدّم الملف القديم من جديد. فالتفريغ يخبر الـ edge بالنسيان فقط؛ ثم يعيد الطلب التالي الجلب من خادمك. وإن كانت ذاكرة تطبيقك أو إضافتك المؤقتة ما زالت تحتفظ بالصفحة القديمة، فسيخزّن الـ edge بأمانة النسخة القديمة مرة أخرى. فرّغ ذاكرة التطبيق أولًا، ثم فرّغ الـ edge.
اجعله جزءًا من النشر، لا شيئًا تتذكّره
التفريغ يدويًا بعد كل إصدار خطوة سينساها أحدهم في النهاية، وغالبًا في الإصدار الذي كان مهمًا. ضعه في خط الأنابيب: بعد نجاح النشر، شغّل تفريغًا لحفنة المسارات التي لا تتغيّر أسماؤها. وعلى cdn.com.tr يمكنك فعل ذلك من اللوحة، أو عبر واجهة REST، أو بأداة cdnctl داخل مهمة CI — الأمر نفسه سواء عمل من طرفيتك أو من منفّذ. وقوائم المسارات المحفوظة (--save) تجعل هذا سطرًا واحدًا تحتفظ به بدل قائمة تعيد كتابتها.
الأسئلة الشائعة
كم يستغرق التفريغ حتى يسري؟
سريع — إذ يُسقط الـ edge المدخل المخزَّن، ويعيد الطلب التالي مباشرةً لذلك الرابط الجلب من خادمك الأصلي. ما ليس فوريًا هو ذاكرة متصفحك أنت، وهي نسخة منفصلة يحكمها رأس Cache-Control نفسه.
هل تفريغ الذاكرة المؤقتة بالكامل مضرّ؟
ليس مضرًّا، لكنه ليس مجانيًا: فحتى تمتلئ الذاكرة من جديد، تصل الطلبات إلى خادمك الأصلي بدل أن تُستوعب قرب المستخدم. إنه الأداة الصحيحة بعد تغيير يشمل الموقع كله، والأداة الخطأ لصورة واحدة عُدّلت.
ما الفرق بين التفريغ والتحديث القسري (hard refresh)؟
التحديث القسري (Ctrl+F5) يمسح نسخة متصفحك أنت فقط — فيصلح ما تراه ولا يصلح شيئًا لأي شخص آخر. أما التفريغ فيمسح النسخة المشتركة على الـ edge، وهي التي تُقدَّم لكل زائر.
هل يمكنني التفريغ تلقائيًا بعد النشر؟
نعم — وهذا هو الإعداد الموصى به. استدعِ واجهة التفريغ أو شغّل cdnctl كخطوة أخيرة في خط نشرك، مستهدفًا المسارات التي لا تتغيّر أسماء ملفاتها (صفحات HTML، خريطة الموقع، التغذيات).