VOL36: Deep Dive Into Caching Strategies
أهلًا وسهلا بكم في العدد السادس والثلاثين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد السادس والثلاثين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية, من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة, ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
Deep Dive Into Caching Strategies
How QR Codes Work
Process Management
Introduction Into Dependency Injection in .NET Core
Introduction Into Entity Framework Core
ستجدون أيضًا في هذه النشرة:
الشراكات - Sponsorship
قناة التليجرام مجانية للجميع حتى يصلك كل مقال جديد
كيفية كتابة مقالات معنا في اقرأ-تِك: والمقالات تكون متاحة ومجانية للجميع ومحفوظة باسم الكاتب بكل تأكيد
كيفية الاشتراك في اقرأ-تِك من خلال InstaPay و VodafoneCash
Deep Dive Into Caching Strategies
الـ caching يعتبر من التقنيات الأساسية اللي بتحسن أداء التطبيقات والأنظمة من خلال تخزين البيانات اللي بنحتاجها كتير في مكان قريب زي الـ Memory للوصول السريع ليها بدل ما نعمل عمليات مكلفة على الـ database أو الـ API.
لكن مش كل أنواع الـ caching مناسبة لكل موقف، عشان كدة مهم نفهم الأنواع المختلفة والسيناريوهات الأنسب لكل نوع.
كنا اتكلمنا في ورقة وقلم عن أنواع الـ Caching Strategies وعرفنا ان عندنا أكتر من نوع زي :
Cache Aside
Write Through
Write Back
Write Around
Read Through
Refresh Ahead
وجه الدور دلوقتي اننا نشوف مع بعض ونفهم الفروقات بين الانواع دي وايه السيناريو اللي ممكن يكون مناسب لكل نوع فيهم بأمثلة عملية.
Cache Aside (Lazy Loading)
إيه هو الـ Cache Aside
الـ Cache Aside بيشتغل بناءً على الطلب. وده اللي أغلبنا تقريبًا اتعامل معاه بشكل كبير في أي Caching Layer كان التطبيق بتاعنا محتاجها ، يعني ايه الكلام ده ؟
يعني لو التطبيق محتاج بيانات، بيحاول يجيبها من الـ cache الأول، ولو مش موجودة وبيحصل Cache Miss، بيروح للـ database أو الـ source الأساسي للبيانات، وبعد ما يجيبها يحطها في الـ cache للاستفادة بعدين وعشان كده سميناه Lazy Loading لإني بحمل البيانات أو بعملها Loading وقت الحاجة ليها عشان استفاد منها بعدين.
إمتى نستخدم الـ Cache Aside
لما يكون عندنا بيانات بتتغير بشكل دوري لكن مش كتير.
لو فيه احتمال إن البيانات اللي في الـ cache تبقى قديمة (يعني stale) فالـ Cache Aside هيساعد وقتها اننا نعمل Cache Invalidation ونجيب الأحدث.
لو مش عايزين نحمل الـ 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 تكون متحدثة في كل الأوقات.
لو مش هينفع إن البيانات تبقى قديمة وفيه 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 استغرقت وقت أطول من المتوقع، مما اثر على أداء التطبيق وبالتالي العملية اعتبرناها فشلت.
How QR Codes Work
ال QR Codes من الأشياء اللي بنشوفها بشكل شبه يومي في كل مكان
فورقة وقلم و تعالوا نفهم هما إيه ونعرف إزاي ال Quick-Response Codes بتتحول ل URLs و إزاي كمبرمج تقدر تعمل تطبيق بسيط بيعمل generation ل QR Codes.
قبل ما نبتدي خلينا نعرف إن الهدف الأساسي وراء اختراع ال QR Codes هو تمثيل قدر كبير من المعلومات في مكان صغير.
ال QR Codes تم اختراعها في مصنع سيارات في اليابان من ٣٠ سنة عشان يكتبوا أكبر قدر من المعلومات عن القطعة المصنعة عليها.
فكرة العمل؟
الفكرة كانت تطوير لفكرة الـ barcode اللي بقدر أمثل بيها أرقام المنتجات باستخدام شرائط طولية ولكن الخطوط الطولية بتديني combinations محدودة وبالتالي أقدر أعبر عن معلومات قليلة ولكن لو بدلنا الخطوط بمربعات صغيرة هيبقي عندي combinations أكثر وبالتالي أقدر أمثل بيها معلومات أكثر
خلينا نفكر في اللونين الأبيض والأسود للـ QR Code على أنهم صفر و واحد, نظام ثنائي عادي من اللي كلنا عارفينه, وكل 8 مربعات مع بعض هنعتبرهم وحدة واحدة (مش بيفكرك دا بال bytes?!) و بس كدا زي ما 011 بتمثل رقم 3 بال binary system فمربعين أسود وواحد أبيض هتمثل رقم 3 في رسمة ال qr code
ونفس فكرة تحويل ال binary ل hexadecimal and ASCII هنقدر نكتب معلومات تحتوي على حروف وأرقام.
ولأن ممكن تحويل الأبيض والأسود (أو أي لونين متباينين) بسهولة لصفر و واحد تفهمه الأجهزة بسهولة بتعتبر ال QR Codes حل ذكي وسريع لتمثيل عنواين المواقع و دا يعتبر استخدامها الأشهر حاليًا, ولكن يمكن استخدامها في تمثيل أي بيانات.
Process Management
في عالم أنظمة التشغيل، إدارة العمليات هي واحدة من الأساسيات اللي بتضمن تشغيل البرامج بشكل سليم واستخدام موارد النظام بكفاءة. العملية هي ببساطة برنامج بيشتغل، وإدارة العمليات دي مهمة جدًا عشان تضمن استقرار وأداء النظام.
إيه هي الـ Process؟
هي نسخة من البرنامج وهو بيشتغل. يعني لما تشغل برنامج، النظام بيحول البرنامج ده لـ Process وبيبدأ يتابع تشغيلها. والـ Process بتاخد مساحة في الذاكرة وبتستخدم موارد زي الـ CPU والـ Memory.
ادارة العمليات Process Management
نظام التشغيل بيتولى إدارة الـ Processes عشان يضمن إن كل Process بتاخد حقها في الموارد وما يحصلش تضارب بينها وبين بعضها. وده بيشمل حاجات متعددة زي:
جدولة العمليات (Process Scheduling):
النظام بيحدد أي Process تشتغل في أي وقت، وده بيتم عن طريق جدولة الـ Processes دي. وطبعا فيه خوارزميات مختلفة للجدولة زي الـ "Round Robin" و الـ "First Come First Serve".
إنشاء وحذف العمليات (Process Creation and Termination):
لما تشغل برنامج، النظام بيعمل Process جديدة. ولما البرنامج يخلص، النظام بيحذف الـ Process دي عشان يفضي الموارد لأي Processes تانية. فنظام التشغيل بيوفر لينا بعض الطرق والآليات لإننا ننشئ ونقفل Processes, فعندنا مثلا الـ fork() System Call بيتم استعمالها عشان نـ Create Process واللي بتكون نسخة طبق الأصل من الـ Parent Process , وعندنا الـ exit() System Call اللي بيتم استعماله عشان نـ Terminate Process.
الشراكات - Sponsorship
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship وتقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 🚀
لا تدع شيء يفوتك!
بفضل الله قمنا بإطلاق قناة اقرأ-تِك على التليجرام مجانًا للجميع 🚀
آملين بده اننا نفتح باب تاني لتحقيق رؤيتنا نحو إثراء المحتوى التقني باللغة العربية ، ومساعدة لكل متابعينا في انهم يوصلوا لجميع أخبار اقرأ-تِك من حيث المقالات ومحتوى ورقة وقلم والنشرة الأسبوعية وكل جديد بطريقة سريعة وسهلة
مستنينكوا تنورونا , وده رابط القناة 👇
Introduction Into Dependency Injection in .NET Core
في تطبيقات .NET الكبيرة والمعقدة، بنحتاج في كثير من الأحيان أن الـ (objects) تعتمد على بعضها البعض، مما يعقد عملية الصيانة والاختبار.
على سبيل المثال، إذا كان لديك (Service) تعتمد على (Interfaces) متعددة أو قاعدة بيانات، فمن الأفضل أن يتم حقن هذه الاعتمادات (dependencies) بدلاً من إنشاء الـ Objects داخل الكود بشكل مباشر.
الفكرة هي فصل مسؤولية إنشاء الـ Objects عن باقي التطبيق، مما يسهل تحديث أو استبدال أي جزء من التطبيق.
الفكرة الأساسية للـ Dependency Injection
الـ Dependency Injection تعتبر طريقة لفصل الـ Objects وتوفيرها بشكل مركزي ، الـ DI Container يقوم بإدارة الـ Objects وتوفيرها عند الحاجة. بدلًا من إنشاء الـ Objects داخل الكود، نقوم "حقن" (inject) الـ Objects المطلوبة عبر الطرق المختلفة لـ DI.
وهنالك أكثر من نوع لتحقيق الـ Dependency Injection :
Constructor Injection
Property Injection
Method Injection
الـ Constructor Injection
بنمرر الـ dependencies من خلال الـconstructor، وهي أكثر الطرق شيوعًا. دي الطريقة الأكثر استخدامًا لأنها تجعل من السهل تحديد جميع الـ dependencies عند إنشاء الـ Object.
مزاياها: تجعل الكود أكثر وضوحًا وسهولة في الفهم. كل شيء واضح في الـconstructor.
مثال بسيط عن الـ Constructor Injection
Introduction Into Entity Framework Core
الـ EF Core هو إطار عمل مفتوح المصدر بيساعدك تدير الاتصال بين تطبيقات .NET Core وقواعد البيانات باستخدام تقنيات ORM (Object-Relational Mapping). يعني بدل ما تكتب استعلامات SQL يدوية، تقدر تتعامل مع البيانات كـ Objects في الكود.
الـ EF Core هو النسخة المحسنة من Entity Framework وبيتيح لك التعامل مع البيانات باستخدام Object Oriented Programming Languages زي C# بدلاً من التعامل مع جداول وقواعد البيانات عبر SQL مباشرة. والـ EF Core بيترجم استعلامات LINQ إلى استعلامات SQL بشكل تلقائي، وده بيسهل عليك التعامل مع البيانات بشكل مرن.
ليه نستخدم EF Core؟
السهولة والمرونة: EF Core بيخليك تتعامل مع البيانات كـ (Objects) بدل ما تتعامل مع جداول SQL بشكل يدوي، وده بيسهل الكتابة والفهم.
التحديثات التلقائية (Migrations): EF Core بيتيح لك تحديث قاعدة البيانات بسهولة عن طريق Migrations، بحيث لو عدلت في الكود، تقدر تحدث قاعدة البيانات تلقائيًا بدون ما تكتب استعلامات يدويًا.
دعم لعدة قواعد بيانات: EF Core بيشتغل مع قواعد بيانات مختلفة زي SQL Server، PostgreSQL، SQLite، MySQL، فده بيسهل دمج التطبيق مع أي قاعدة بيانات بدون مشاكل.
أداء أفضل: استخدام LINQ لاستعلام البيانات بدل SQL بيحسن الأداء، خصوصًا لو استخدمت حاجات زي AsNoTracking لتحسين قراءة البيانات بسرعة أكبر.
كيفية استخدام EF Core
إعداد الـ DbContext: الـ DbContext هو الرابط بين الكود البرمجي وقاعدة البيانات. في الكود ده بنحدد الجداول اللي هنشتغل معاها باستخدام الـ <DbSet<T.
تقدروا دلوقتي تشتركوا في اقرأ-تِك بخصم الـ 20% وتنضموا لمجتمع مهتم بالقراءة في هندسة البرمجيات بـ 50 جنيه بس 🎉
وتستمتعوا بحرية كاملة في قراءة المقالات في مواضيع مختلفة بجودة عالية زي:
Data Structure & Algorithms , System Design , Distributed Systems , Micro-Services, Clean Code, Refactoring, Databases , Web Development, DevOps وغيرهم كتير باللغة العربية!
بالاضافة لمحتوى ورقة وقلم اللي بنشرح فيه مفاهيم برمجية بطريقة سهلة وباستعمال صور توضيحية 🚀
ولو فيه مشاكل في الدفع الأونلاين فمتاح دلوقتي الاشتراك من خلال InstaPay و VodafoneCash 💪
تقدروا تتواصلوا معانا من خلال الـ WhatsApp Business أو من خلال الرسايل على مواقع التواصل الاجتماعي أو من خلال البريد الالكتروني contact@eqraatech.com 😍
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
