VOL24: Stop Using Sticky Sessions at Scale
VOL24: Stop Using Sticky Sessions at Scale
أهلًا وسهلا بكم في العدد الرابع والعشرين من النشرة الأسبوعية لاقرأ-تِك 🎉
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الرابع والعشرين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية, من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة, ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
Sticky Sessions vs. Distributed Session Storage
Docker Series Part 1: Architecture and Basic Commands
Best Practices for Handling NullPointerExceptions In Java
What is API
RESTful vs GraphQL
Sticky Sessions vs. Distributed Session Storage
الـ Sticky Session هو Terminology اشتهر خصوصًا في التطبيقات اللي بنحتاج فيها الـ Server يحافظ على الـ Session بينه وبين الـ Client ، فكل الـ User Request بتبدأ تروح لنفس الـ Server خلال مدة الـ Session بتاعته.
وده طبعًا لإن لو عندنا تطبيق معتمد على User Session ، ولو شغالين بـ Load Balancer ، فلو مش عندنا Sticky Session ، وعندنا موقع E-Commerce زي Amazon .. هيجي الـ User يفتح مش بعيد ميلاقيش أي حاجة كان حاطتها في الـ Shopping Cart وقت اما يجي يشتريهم.
فعشان كده ظهرت الـ Sticky Sessions واللي في الغالب بتكون ناحية الـ Load Balancer عشان يـ Maintain الـ User Session ويعرف يوجه الـ User Request لانهي Server خصوصا في عالم النظم الموزعة واللي بيكون فيه أكتر من Server بل ملايين السيرفرات.
أمثلة عملية على الـ Sticky Session
فيه بعض التطبيقات اللي بتكون من ضمن احتياجها ان الـ Server يفضل محافظ على الـ Session بينه وبين الـ User وأمثلة على ده زي :
الـ Shopping Cart : فزي ما شوفنا ووضحنا في الـ E-Commerce تفاصيل الـ Shopping Cart بتاعة الـ User ، ممكن تتخزن على الـ Server والـ Server ده ممكن يكون واحد من مليون .. فعشان نضمن ان كل ما الـ User خلال فترة الـ Session بتاعته هيعمل اي حاجة في التطبيق .. محتاجين كل الـ Requests الخاصة بيه تكون في الـ Server ده.
الـ File / Video Uploading : لو انت بترفع صورة أو ملف أو فيديو على Cloud والـ Cloud محتاج يقولك حالة الـ Processing عاملة ازاي , والـ Progress بتاعها ؟ فهو محتاج يحافظ على الـ Session بينك وبينه خلال الفترة دي عشان يقدر يجاوبك على الـ Progress بتاع الـ Processing اللي بيحصل ..
الـ File Processing : لو انت بتعمل أي عملية Processing على ملف أو صورة أو فيديو زي برامج تعديل الصور والفيديوهات .. فعشان تفضل شايف الـ Processing اللي بيتم ومتجيش تعمل حاجة تلاقي كل ده راح .. محتاجين نحافظ على الـ Session بينك وبين الـ Server Instance اللي بدأت معاه والا كل البيانات دي هتضيع مع أول ريفريش.
مميزات وعيوب الـ Sticky Session
فيه بعض المميزات اللي ما ينفعش نغفل عنها في الـ Sticky Sessions الا وهي :
الحفاظ على الـ Consistency واتساق البيانات خلال فترة الـ Session بتاعتك وبالتالي بنضمن ان البيانات متخزنة في الـ Server Instance اللي الـ Requests بتاعتك هتروح ليه.
مش محتاجين أي تكلفة إضافية للـ Session Storage , وده لإنها متخزنة في الـ Server Instance ذات نفسه.
الـ Performance اللي هنحصل عليه نتيجة ان كل الـ User Requests بتروح لنفس الـ Instance اللي راحت ليه قبل كده ومش متوزعة بين أكتر من Instance.
ولكن برضو ده ما يمنعش أن فيه عيوب قاتلة في الـ Sticky Sessions لا بد واننا نكون فاهمنها كويس :
من اسم الـ Terminology اللي هو Sticky Session , فللأسف هنبدأ نشوف أن الـ Load Balancer في كتير من الحالات الـ Sessions بيحصلها Sticking يعني بتلزق .. فبنشوف انه بيبدأ يودي الـ User Requests مثلا لـ Server Instance 1 وده لان مثلا فيه 10 كانوا الـ Session بتاعتهم رايحة هناك .. بينما الـ Server Instance 2 مبقاش فيه حد من الـ User محتاجين الـ Session بتاعتهم خلاص او انتهت. فهنلاقي ان هنا Server Instance 2 بقى Idle وبالتالي هنشوف مشاكل بتحصل في الـ Scalability
تاني مشكلة وهي خطيرة جدًا هي الـ Single Point of Failure ، ازاي الكلام ده ؟ ده لان بكل بساطة لو الـ Server Instance اللي كان شايل الـ Session بتاعتك حصله حاجة , وقتها كل الـ Session هتروح , وده لان غالبًا الـ Session بيتم تخزينها في الـ Memory بتاعة الـ Sever Instance اللي الـ Requests بتاعتك بتروح ليه. وبالشكل ده ممكن كتير من المستعملين يضايقوا.
Docker Series Part 1: Architecture and Basic Commands
لو بتدور على طريقة سهلة وفعّالة عشان تدير بيها التطبيقات بتاعتك، فمفيش شك إن Docker هيكون من أهم الأدوات اللي هتساعدك لتحقيق ده. Docker هو أداة قوية جدًا تقدر تعملها بيها حاويات Containers، ودي زي بيئة معزولة بتشغل فيها التطبيقات بتاعتك.
وفي السلسلة دي، هنغطي أهم المفاهيم والأدوات والـ Commands اللي ليها علاقة بـ Docker بشكل بسيط وسهل عشان تقدر تستفيد منها بسرعة وتطبّقها في شغلك.
Container vs VM
Containers abstract application layer, vm abstract os
كل containers بتشترك في نفس ال kernel بتاع ال os الأساسي ودا بيقلل من استهلاك ال Recourses والوقت اللازم لبدء التشغيل
اما ال vm بتكون os كامل ليها ال kernel بتاعتها وال Application الخاصه بيها فبتحتاج Recourses كتيره عشان تقدر تشغل كل دا وبتشكل عزل كامل بين ال vms وبعضها لانها بتكون os مستقل ودا اقوي من ناحيه ال security
Docker
الdocker هو عبارة عن software لتبسيط ال process في ال building و ال Running وال Managing لل Application عن طريق ال Container وبكل سهولة بيمكني اني انقل ال App بتاعي من مكان لمكان تاني
بيستخدم حاجه اسمها Namespace ودي بتمد ال Docker بال Workspace المنعزلة ال هيشتغل عليها وكل Namespace منعزل عن التاني
Docker Architecture
عندي 3 حاجات أساسية:
الClient ودا هو ال CLI ال هكتب فيه ال Commands بتاعتي
ال Docker Host ودا بيكون بداخله 3 أجزاء :
ال Docker Daemon: ودا ال بيبدا يستقبل ال Commands من ال Client ويبعتها لمكانها الصح (ال Daemon ال بيستخدمه ال Dcker اسمه dockerd )
ال Images: دي ال بيكون بداخلها ال files ال من خلالها بعمل Run لل Container بتاعي، وال Image ID بيتكون من حاجه اسمها Image Layers واي تغيير بيتم ف ال Image يعتبر layer منفصل عن باقي ال Layers
ال Container: بعد ما بعمل Run لل image بتبدا تعملي ال Container اوا انا بعد م احمل ال image اعمل Create لل Container من خلال ال image دي
ال Registry: دا ال Store ال بيكون بداخله كل ال Images ودا اسمه Docker Hub ومن خلاله بقدر اعمل Download لاي Image انا محتاجها
ال بيحصل بقا : مثلا كتبت ع ال client امر docker pull فال client هيبعتها لل daemon فهيترجم انه عاوز يعمل download لل image فهيبعت ال command لل registry فال registry يبدا يعمل download لل image ع ال host ف المكان ال بيكون فيه images
وعشان نعمل install docker : ممكن تدخل ع اللينك دا وع حسب ال OS تقدر تعمل Install Docker
الشراكات - Sponsorship
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship وتقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 🚀
لا تدع شيء يفوتك!
بفضل الله قمنا بإطلاق قناة اقرأ-تِك على التليجرام مجانًا للجميع 🚀
آملين بده اننا نفتح باب تاني لتحقيق رؤيتنا نحو إثراء المحتوى التقني باللغة العربية ، ومساعدة لكل متابعينا في انهم يوصلوا لجميع أخبار اقرأ-تِك من حيث المقالات ومحتوى ورقة وقلم والنشرة الأسبوعية وكل جديد بطريقة سريعة وسهلة
مستنينكوا تنورونا , وده رابط القناة 👇
Best Practices for Handling NullPointerExceptions In Java
واحدة من أشهر المشاكل اللي بتقابل الـ Java Developers هي الـ NullPointerExceptions ، واللي للأسف بيكون سببها واضح ، ولكن أثناء كتابة الـ Code معظمنا بيغفل عنها.
وللأسف النوع ده من المشاكل بيخلي التطبيق في الآخر يتعطل وممكن ده يؤدي بالطبع لمشاكل من ناحية الـ Customers وعشان كده ضروري جدًا نعرف ازاي نتعامل مع النوع ده من المشاكل بشكل فعال.
NullPointerException
الـ NullPointerException هي Class في الـ Java بتورث من الـ RuntimeException وده عبارة عن UnCheckedException وكنا اتكلمنا في في العدد السابق عن الـ Java Exceptions تقدروا تشوفوه من هنا.
الـ NullPointerException بيحصل لما نحاول اننا نـ Access Null Reference فمثلًا لو عندنا String الـ Default بتاع اي Reference لأي Variable في الـ Java بيكون Null.
فزي ماحنا شايفين هنا في الـ Code Snippet ده ، احنا هنا عملنا Variable اسمه name وبالتالي لما جينا نحاول نطبع الـ Length بتاع الـ Variable ده ، هيضرب في وشنا NullPointerException وده لان الـ Reference ده موجود بـ Null واحنا بنحاول نـ Access Null Reference ونقوله هاتلي الـ Length على حاجة مش موجودة.
وطبعا المشاكل ممكن تكون أكتر من كده لإن احيانا بيحصلنا ده في الـ Runtime ، فلو احنا معتمدين اننا بنكلم Service أو الـ Database ومعتمدين على بيانات مثلا جاية ، فلو ما اتعاملناش معاها بحذر ، وقتها برضو ممكن يكون فيه Fields بـ Null ولما نيجي نحاول نعمل عليها أي Operation هيضرب في وشنا NullPointerException.
عشان كده احنا محتاجين نعرف ازاي نتعامل بشكل كويس مع النوع ده من المشاكل.
Standard If-Else Condition
أبسط وأسهل طريقة نعملها عشان نتجنب مشكلة الـ NullPointerException هي الـ Simple If-Else Statement واللي من خلالها هنروح نشوف الـ Value بتاعة الـ Variable اللي عاوزين نعمل عليه Operation معينة بـ Null ولا لا وبالتالي نتجنب انه يحصل مشكلة لو كان بـ Null.
Equals Method
ممكن برضو كحل آخر واحنا بنقارن في الـ If-Else Statement اننا نلجأ لاستعمال الـ equals Method ودي اصلًا Method موجودة في كل الـ Objects وكل الـ Reference Types عندهم الـ Method دي.
ولكن نقطة هنا نخلي بالنا منها ان بالطبع لو نادينا الـ equals على Null Reference فاحنا كده ماستفدناش حاجة! ولكن الغرض من استعمالها هو اننا نستعملها على حاجة متأكدين انها مش بـ Null زي كده:
فاحنا هنا اعتمدنا على ان معانا String اسمه eqraatech نقدر نعتبره Constant ضامنين انه مش بـ Null وبنقارنه بحاجة ممكن تكون Null ولا لا ، هنا ده عادي , ولكن لو عكسنا وقتها هيضرب في وشنا NullPointerException.
String.valueOf() Method
من ضمن الحاجات الجميلة اللي ممكن نستعملها هي الـ valueOf() Method في الـ String وده لإن الـ Method دي من ورا الـ Implementation بتاعها بتـ Check for Nulls ولو لقت حاجة بـ Null بترجع String اسمه "null" ودي عظيمة جدًا.
فلو مثلا احنا بنكتب في ملف معين أو بنعمل Logs ومش عاوزين نقع في مشكلة الـ NullPointerException ممكن بكل بساطة نعمل الآتي:
هنلاقي ان الكلام هنا بدأ يطبع كـ "Null" بس ده String ومش هيضرب NullPointerException.
What is API
طبعًا مش هنقول إنها اختصار لـ “واجهة التطبيقات البرمجية” لأنك غالبًا هتنسي الاسم علطول, ولكن هنفهم دورها ايه و بنستخدمها ليه بمثال بسيط ودا عمرك ما هتنساه الـ APIs بتلعب دور الجرسون في المطعم, هي ببساطة طريقة محددة لطلب شيء من المطبخ “السيرفر في حالتنا”, الجرسون بياخد طلبك يوصله للشيف اللي هيقوم بتجهيزه وبعد ما يجهز الجرسون يجمعه و يقدمهولك.
طريقة عمل الـ API
بياخد ال Request من ال Client يوصله لل Server اللي بيجهز الطلب ويقوم ال API بإرجاعه ك Response.
ليه مبيطلبش من الـ Server Direct ؟
لأكثر من سبب:
السيرفر هيكون مشغول بتجهيز طلبك وطلب الزبائن التانين للمطعم فميقدرش يقوم بالمهمتين
الـ API هيوصل طلبك بالطريقة المناسبة اللي يفهمها السيرفر, ودي نقطة مهمة لأن الكمبيوترز مبتفهمش غير طريقة واحدة مٌبرمجة عليها أي تغيير في الطريقة دي هيقولك لا والله معرفش دا بيتعمل ازاي وينتج عنه Request Failure فالـ API بيخلي كل الناس تكلم السيرفر بطريقة رسمية ومٌوحدة- وبسيطة- يقدر السيرفر يتعامل معها.
RESTful vs GraphQL
غالبًا لو عملت APIs قبل كده هتكون استعملت REST وهيبقي عندك زميلك اللي عمال يقولك ما تيجي نشتغل بـ GraphQL زي الناس اللي هناك دي..فتعالى نعرف الفرق بين اثنين من أشهر أنواع الـ API Architectures الأول لازم نعرف أن الاتنين ليهم نفس أساس العمل وهو ان عندي Server ببعتله HTTP Request فيجاوب عليا بالمعلومات اللي طلبتها.
REST APIs
الـ REST بينظم ال API علي شكل Endpoints وبيقولك تقدر تناديها ب عمليات محددة أشهرهم الـ GET, POST, PUT, DELETE وهيرد عليك بـ Standard Response
GraphQL
بينما الـ GraphQL بيقولك هي Endpoint واحدة تقدر تكلمها وتوصف انت عاوز ايه بالظبط من خلال استعمال Query وهيرد عليك بـ Standard Responseطب ما والله نفس الشيء ايش استفدت؟ الـ GraphQL بيحل مشاكل ظهرت مع استخدامنا للـ REST في كل الأنظمة لسهولته والطبيعي انه مش حل واحد يناسب الكل
المشاكل اللي بيحلها الـ GraphQL
مشكلة الـ Over-Fetching and Under-Fetching
الـ REST بينظم الـ Resources بطريقة ثابتة تناسب العمليات اللى قولنا عليهم فلو انت علي موقع اقرأ تك وطلبت منه قائمة بأسماء الكتاب في المنصة علي الـ Endpoint: eqraatech/authors فهيرد عليك بكل المعلومات عنهم مع انك محتاج أساميهم بس ودا اسمه Over Fetching, مشكلته بقي انه بيستهلك الـ Network Bandwidth في نقل معلومات انت مش محتاجها أصلاً وبيبطأ ال Endpoint علي ما تجيب لك كل المعلومات دي
نسبح في بحر الـ Endpoints
كل Resource انت بتطلبه بـ REST ليه Endpoint أو عنوان مختلف, ففي المواقع المعقدة بينتهي بيك الأمر لآلاف من ال Endpoints.
مشاركة من أحمد عطية في مجتمع اقرأ-تِك 😂
AWS Be Like:
تقدروا دلوقتي تشتركوا في اقرأ-تِك بخصم الـ 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 😍
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
