الـ caching يعتبر من التقنيات الأساسية اللي بتحسن أداء التطبيقات والأنظمة من خلال تخزين البيانات اللي بنحتاجها كتير في مكان قريب زي الـ Memory للوصول السريع ليها بدل ما نعمل عمليات مكلفة على الـ database أو الـ API.
لكن مش كل أنواع الـ caching مناسبة لكل موقف ، عشان كدة مهم نفهم الأنواع المختلفة والسيناريوهات الأنسب لكل نوع.
كنا اتكلمنا في ورقة وقلم عن أنواع الـ Caching Strategies وعرفنا ان عندنا أكتر من نوع زي :
وجه الدور دلوقتي اننا نشوف مع بعض ونفهم الفروقات بين الانواع دي وايه السيناريو اللي ممكن يكون مناسب لكل نوع فيهم بأمثلة عملية.
Cache Aside (Lazy Loading)
إيه هو الـ Cache Aside
الـ Cache Aside بيشتغل بناءً على الطلب. وده اللي أغلبنا تقريبًا اتعامل معاه بشكل كبير في أي Caching Layer كان التطبيق بتاعنا محتاجها ، يعني ايه الكلام ده ؟
يعني لو التطبيق محتاج بيانات، بيحاول يجيبها من الـ cache الأول، ولو مش موجودة وبيحصل Cache Miss، بيروح للـ database أو الـ source الأساسي للبيانات، وبعد ما يجيبها يحطها في الـ cache للاستفادة بعدين وعشان كده سميناه Lazy Loading لإني بحمل البيانات أو بعملها Loading وقت الحاجة ليها عشان استفاد منها بعدين.
Cache Aside (Lazy 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 ببيانات كتير مالهاش استخدام حقيقي وفعلي.
سيناريو ومثال عملي
لو عندنا تطبيق مثلًا بيجيب بيانات الكتّاب أو المستخدمين من الـ database، فأول ما التطبيق يحتاج بيانات الكتّاب دول، هيحاول يجيبها من الـ cache الأول. ولو موجودة فهيرجعها عادي علطول وده بنسميه Cache Hit ولو مش موجودة، هيروح للـ database، ويحط البيانات دي في الـ cache عشان الاستفادة منها في الطلبات اللي جاية.
لو عندنا 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
إمتى نستخدم الـ 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.
طب احنا بنقول ان في الـ Write Through بنكتب في الـ Cache الأول وبعدين في الـ Database عشان نضمن أن البيانات متزامنة مع بعضها ، طب ماذا لو حصل مشكلة أثناء عملية الكتابة في الـ Database ؟ ماذا لو فشلت عملية الكتابة في الـ Database ؟
تحديات ومشاكل الـ Write Through
لو حصلت مشكلة في الـ Database أثناء استخدام استراتيجية Write-Through، لازم النظام بتاعنا يكون مجهز للتعامل مع السيناريو ده بحيث يحافظ على استقرار النظام والبيانات.
السيناريوهات الممكنة:
الـ Database غير متاحة (Unavailable): فالتطبيق بيقدر يكتب في الـ Cache، ولكن محاولة الكتابة في الـDatabase بتفشل.
خطأ أثناء الكتابة (Write Failure): الـ Database متاحة، ولكن حصل مشكلة أثناء عملية الكتابة (زي Error في الاتصال أو تعارض في البيانات).
الـ Latency كان عالي جدًا: الكتابة في الـ Database استغرقت وقت أطول من المتوقع، مما اثر على أداء التطبيق وبالتالي العملية اعتبرناها فشلت.
أفضل الممارسات للتعامل مع مشاكل وتحديات الـ Write Through
اشترك الآن بنشرة اقرأ‑تِك الأسبوعية
لا تدع أي شيء يفوتك. واحصل على أحدث المقالات المميزة مباشرة إلى بريدك الإلكتروني وبشكل مجاني!
