بروتوكولHTTP بطبعه Stateless (نسّاي , عكس Stateful اللي يتذكر ) بمعنى لما ترسل Request للServer فهو يتنفذ باستقلالية بغض النظر عن اي Requests قبله و يقطع الاتصال بمجرد وصول الResponse و ينساك. وللتذكر يستخدم الCookies وهي قطعة بيانات صغيرة يضعها السيرفر في الBrowser عندك.
-يتبع
-يتبع
طبيعة الHTTP هذه افادت في الScalability صرنا بدل ما نحط Server واحد للWeb ممكن نحط 3 او 10 خوادم و قبلهم Load Balancer يوزع الRequests بينهم. لكن خذوا هذا السيناريو. لدي تطبيق مطاعم و في نفس اللحظة دخل 20 عميل على صفحة فرع مطعم معين بسبب إعلان ما.
- يتبع
- يتبع
في الBack-end بالتأكيد هناك 200 اوبجكت لنفس المطعم (نفس الID) و هناك 200 طلب بيانات ارسل لقواعد البيانات لتعبئتهم. مع انه هو فرع المطعم نفسه!!. طيب ليه 200 اوبجكت و 200 مرة اتصال بالداتابيز؟ المفروض مرة واحدة وبعدين يكيّش Caching ولا؟!!
- يتبع
- يتبع
صحيح. لو كان عندنا اكثر من Server في الBack-end فكل Server يحتاج يكيّش. و لو حصل تعديل على بيانات المطعم من احد السيرفرات بتكون بيانات الكاش غير صحيحة Invalid. هنا ظهرت اهمية وجود Central Cache زي Redis او Memcached كل السيرفرات تخزن و تقرا بيانات الكاش منه.
-يتبع
-يتبع
لو تم الطلب Order و كان هناك اكثر من Modules اخرى يحتاج الOrder انه يكلمها زي موديول السائقين او الدفع او الLog فممكن يكلمها مباشرة لكن الأفضل انه يرسل الطلب لEvent Hub مثل RabbitMQ ( الى من يهمه الامر) و الموديول المهتمه بهذا الEvent تشوفه و تعالجه بطريقتها.
- يتبع
- يتبع
تخيل معي الان ..لو كان الObject يكيّش بياناته في نفسه و كان له نسخة واحدة فقط على مستوى كل الCluster ولو مئات و كان ممكن توصله و تستدعيه من أي Server منهم مباشرة بغض النظر عن مكانه الحالي من خلال الID الخاص به فقط فهنا لن تحتاج Redis و لا RabbitMQ للاغراض اللي ذكرتها
- يتبع.
- يتبع.
الحل الثاني يعتبر Stateful و طبعاً لن يكون الاتصال HTTP بين الخوادم لكن سينقل النظام الى Level اخر من الاداء و الكفاءة و تخفيض الكلفة و الصيانة. هذه الطريقة هي طريقة الActor Model Programming و الى سلسلة قادمة اتحدث فيها عن اهم اللاعبين في هذا المجال و تطبيقاته الحالية.
-انتهى
-انتهى
جاري تحميل الاقتراحات...