Deep Dive Into Caching Strategies

المقدمة

الـ caching يعتبر من التقنيات الأساسية اللي بتحسن أداء التطبيقات والأنظمة من خلال تخزين البيانات اللي بنحتاجها كتير في مكان قريب زي الـ Memory للوصول السريع ليها بدل ما نعمل عمليات مكلفة على الـ database أو الـ API.

لكن مش كل أنواع الـ caching مناسبة لكل موقف، عشان كدة مهم نفهم الأنواع المختلفة والسيناريوهات الأنسب لكل نوع.

كنا اتكلمنا في ورقة وقلم عن أنواع الـ Caching Strategies وعرفنا ان عندنا أكتر من نوع زي :

• Cache Aside
• Write Through
• Write Back
• Write Around
• Read Through
• Refresh Ahead

Caching Strategies In a Nutshell

الـ Caching من المفاهيم المهمة جدًا اللي منقدرش نستغنى عنها في صناعة البرمجيات، وجوكر في مواقف كتير لتحسين الـ Performance. وفيه أكتر من تكنيك بيتم الـ Caching من خلاله وده بيعتمد بنسبة كبيرة على الـ Data Access Patterns، وكل تكنيك ليه الـ Trade-offs اللي لازم تكون مُلم بيها.

اقرأ-تكMahmoud Youssef

وجه الدور دلوقتي اننا نشوف مع بعض ونفهم الفروقات بين الانواع دي وايه السيناريو اللي ممكن يكون مناسب لكل نوع فيهم بأمثلة عملية.

Cache Aside (Lazy Loading)

إيه هو الـ Cache Aside

الـ Cache Aside بيشتغل بناءً على الطلب. وده اللي أغلبنا تقريبًا اتعامل معاه بشكل كبير في أي Caching Layer كان التطبيق بتاعنا محتاجها ، يعني ايه الكلام ده ؟

يعني لو التطبيق محتاج بيانات، بيحاول يجيبها من الـ cache الأول، ولو مش موجودة وبيحصل Cache Miss، بيروح للـ database أو الـ source الأساسي للبيانات، وبعد ما يجيبها يحطها في الـ cache للاستفادة بعدين وعشان كده سميناه Lazy Loading لإني بحمل البيانات أو بعملها Loading وقت الحاجة ليها عشان استفاد منها بعدين.

إمتى نستخدم الـ Cache Aside

• لما يكون عندنا Read-Heavy Applications وده لإن الـ Cache Aside هيساعدنا في اننا نـ Cache الـ Frequently Accessed Data ، في حين البيانات النادرة أو اللي مش بتنطلب بشكل كبير مش هتتحط في الـ Cache
• لما يكون عندنا البيانات مش بتتغير بشكل دوري وده لإنه مش بيعمل Update الا في حالة الـ Read والـ Cache Miss وطبعا لازم نكون مراعيين ان البيانات دي بتـ Tolerate Update Cache Delays.
• لو فيه احتمال إن البيانات اللي في الـ cache تبقى قديمة (يعني stale) فالـ Cache Aside هيساعد وقتها اننا نعمل Cache Invalidation ونجيب الأحدث لو بتنطلب بشكل دوري خصوصا مع تحديد TTL للـ Cache Entries.
• لو مش عايزين نحمل الـ cache ببيانات كتير مالهاش استخدام حقيقي وفعلي.

سيناريو ومثال عملي

1. لو عندنا تطبيق مثلًا بيجيب بيانات الكتّاب أو المستخدمين من الـ database، فأول ما التطبيق يحتاج بيانات الكتّاب دول، هيحاول يجيبها من الـ cache الأول. ولو موجودة فهيرجعها عادي علطول وده بنسميه Cache Hit ولو مش موجودة، هيروح للـ database، ويحط البيانات دي في الـ cache عشان الاستفادة منها في الطلبات اللي جاية.
2. لو عندنا API Endpoints عاوزين نحسن من أداءها باستعمال الـ Caching ، فعاوزين نـ Cache الـ Response عند الحاجة ليه ، ده برضو هيكون مثال كويس لحاجة زي كده خصوصا لو كانت البيانات دي بتتغير بشكل دوري ولكن مش كتير وبرضو فيه احتمالية ان البيانات دي تبقى Stale مع الوقت.

أمثلة من الحياة العملية

• تطبيق خاص بالتوصيل (زي Talabat):
  لما العميل يدور على مطعم معين، بنـ Check Cache الأول لو لقينا المطعم بنعرض بياناته (المنيو - التقييم - الموقع). ولو مش موجود، بنجيب الداتا من الـDatabase ونحطها في الكاش.
• تطبيق لمتابعة سوق الأسهم:
  لما المستخدم يطلب أسعار سهم معين، لو السعر موجود في الـ Cache، بنرجعه علطول. ولو لأ، بنجيب السعر الحالي من API خارجي ونخزنه في الـ Cache وهنا كان المصدر الاساسي للبيانات الـ API مش Database عندي مثلًا في الـ System.
• تطبيق لمكتبة إلكترونية:
  لما المستخدم يدور على كتاب برقم ISBN. فلو موجود في الـ Cache، بنعرض تفاصيله (العنوان، الكاتب، السعر). ولو مش موجود، بنجيب الداتا من الـ Database ونحطها في الكاش.

Write-Through Cache

إيه هو الـ Write-Through

في الـ Write-Through Caching، أي عملية كتابة أو تعديل على البيانات بتروح مباشرة للـ Cache والـ Database في نفس الوقت. يعني البيانات في الـ Cache دايماً متزامنة مع البيانات الفعلية.

إمتى نستخدم الـ Write-Through

• لما يكون من الضروري إن البيانات اللي في الـ Cache تكون متحدثة في كل الأوقات.
• لو مش هينفع إن البيانات تبقى قديمة وفيه Stale حتى لو لفترة قصيرة.

سيناريو ومثال عملي

تطبيق محاسبي أو e-commerce، واللي فيه الحسابات لازم تبقى دايماً متحدثة وبدقة، لأن أي اختلاف بين الـ Cache والـ Database ممكن يسبب مشاكل كبيرة خصوصًا لو فيه فلوس متضمنة في العملية.

أمثلة من الحياة العملية

في تطبيق لإدارة مخزون المنتجات

لما الموظف يضيف كمية جديدة من منتج معين، التعديل محتاجينه يحصل في الـ Cache وفي الـ Database في نفس اللحظة وده لإن المخزن لازم يكون عنده أرقام دقيقة عشان عمليات الشراء والاستعلامات السريعة.

في تطبيق لولاء العملاء (Loyalty Program)

لما العميل يجمع نقاط جديدة بعد عملية شراء، النقاط بتضاف في الـ Cache وفي الـ Database في نفس الوقت. وده لإن الـ Cache بيستخدم لحساب النقاط مباشرة في أي طلب مستقبلي، والـ Database بيضمن الحفظ الآمن والدائم.

في تطبيق للـ Live Streaming

لما المستخدم يشتري اشتراك جديد أو يجدد اشتراكه، التطبيق محتاج يحدث حالته (Active/Expired) في الـ Cache وفي الـ Database فورًا وده لإن الاشتراك بيحدد مباشرة إذا كان يقدر يشوف المحتوى أو لا، فمينفعش يكون فيه فرق بين الـ Cache والـ Database.

في تطبيق لمتجر إلكتروني للمنتجات النادرة

لما حد يشتري منتج نادر (Limited Stock)، الكمية تُحدث في الـ Cache والـ Database في نفس اللحظة وده لإن المنتجات النادرة بتخلص بسرعة، فلازم الـ Cache يفضل محدث عشان ينعكس على الطلبات الفورية.

في تطبيق لحجز التذاكر

لما المستخدم يحجز تذكرة لحفلة أو رحلة ، ممكن التطبيق بيكتب الحجز في الـ Cache والـ Database مع بعض عشان يضمن إن التذكرة تُحجز فورًا وما حدش يحجزها تاني وهنا ممكن نلجأ ليه كحل عشان نمنع الـ Double Booking.

تقدروا دلوقتي تشتركوا في النشرة الأسبوعية لاقرأ-تِك بشكل مجاني تمامًا عشان يجيلكوا كل جديد بشكل أسبوعي فيما يخص مواضيع متنوعة وبشروحات بسيطة وسهلة وبجودة عالية 🚀

النشرة هيكون ليها شكل جديد ومختلف عن شكلها القديم وهنحاول انها تكون مميزة ومختلفة وخليط بين المحتوى الأساسي اللي بينزل ومفاجآت تانية كتير 🎉

Eqraatech Newsletter | Eqraatech - اقرأ-تِك | Substack

محتوى تقني متميز في مختلف مجالات هندسة البرمجيات باللغة العربية عن طريق تبسيط المفاهيم البرمجية المعقدة بشكل سلس وباستخدام صور توضيحية مذهلة. Click to read Eqraatech Newsletter, a Substack publication with hundreds of subscribers.

SubstackEqraatech - اقرأ-تِك

بفضل الله قمنا بإطلاق قناة اقرأ-تِك على التليجرام مجانًا للجميع 🚀

آملين بده اننا نفتح باب تاني لتحقيق رؤيتنا نحو إثراء المحتوى التقني باللغة العربية ، ومساعدة لكل متابعينا في انهم يوصلوا لجميع أخبار اقرأ-تِك من حيث المقالات ومحتوى ورقة وقلم والنشرة الأسبوعية وكل جديد بطريقة سريعة وسهلة

مستنينكوا تنورونا , وده رابط القناة 👇

https://t.me/eqraatechcom

طب احنا بنقول ان في الـ Write Through بنكتب في الـ Cache الأول وبعدين في الـ Database عشان نضمن أن البيانات متزامنة مع بعضها ، طب ماذا لو حصل مشكلة أثناء عملية الكتابة في الـ Database ؟ ماذا لو فشلت عملية الكتابة في الـ Database ؟

تحديات ومشاكل الـ Write Through

لو حصلت مشكلة في الـ Database أثناء استخدام استراتيجية Write-Through، لازم النظام بتاعنا يكون مجهز للتعامل مع السيناريو ده بحيث يحافظ على استقرار النظام والبيانات.

السيناريوهات الممكنة:

1. الـ Database غير متاحة (Unavailable):
   فالتطبيق بيقدر يكتب في الـ Cache، ولكن محاولة الكتابة في الـDatabase بتفشل.
2. خطأ أثناء الكتابة (Write Failure):
   الـ Database متاحة، ولكن حصل مشكلة أثناء عملية الكتابة (زي Error في الاتصال أو تعارض في البيانات).
3. الـ Latency كان عالي جدًا:
   الكتابة في الـ Database استغرقت وقت أطول من المتوقع، مما اثر على أداء التطبيق وبالتالي العملية اعتبرناها فشلت.

أفضل الممارسات للتعامل مع مشاكل وتحديات الـ Write Through