الـ 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 اللي بدأت معاه والا كل البيانات دي هتضيع مع أول ريفريش.
Load Balancer with Sticky Session
مميزات وعيوب الـ 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 بتاعتك بتروح ليه. وبالشكل ده ممكن كتير من المستعملين يضايقوا.
الاتجاه لاستعمال الـ Distributed Session Storage
اشترك الآن بنشرة اقرأ‑تِك الأسبوعية
لا تدع أي شيء يفوتك. واحصل على أحدث المقالات المميزة مباشرة إلى بريدك الإلكتروني وبشكل مجاني!
