تتمثل المهمة الرئيسية لأنظمة WEB المحملة بشكل كبير في القدرة على معالجة عدد كبير من الطلبات. يمكن حل هذه المشكلة بطرق مختلفة. في هذه المقالة ، أقترح التفكير في طريقة غير عادية لتحسين طلبات الواجهة الخلفية من خلال تقنية نطاق المحتوى (النطاق). وهي تقليل عددهم دون فقدان جودة النظام من خلال التخزين المؤقت الفعال.
بادئ ذي بدء ، أقترح دراسة
مقالة حيث يتم تقديم مقدمة التكنولوجيا بمثال لـ S2S بشكل موجز ودقيق. علاوة على ذلك ، من المستحسن التعرف على مقالتي الأولى حول استخدام هذه التكنولوجيا لتحسين العمل مع بيانات السوق في مشروع تبادل العملات المشفرة.
في هذه المقالة ، أريد أن أوضح أنه يمكن استخدام هذه التقنية على نطاق أوسع من المقال الأول الذي تم عرضه. دعني أذكرك أن هناك معلومات تداول (
الشموع ) يتم الحصول عليها عن طريق طلبات النطاق للملفات الثابتة ، والتي يتم إعدادها مسبقًا بواسطة خدمة خاصة. الآن ، أريد النظر في طلبات الحصول على خلفية كاملة باستخدام نفس بيانات السوق كمثال ، وللشموع نفسها ، دون خسارة الأرباح الرئيسية.
إذن ما هو المخطط لتحقيقه:
- تحسين طلبات الواجهة الخلفية (تقليل عددها) ؛
- زيادة سرعة توصيل المحتوى للمستخدم النهائي ؛
- تحسين حركة المرور.
مرة أخرى ، أؤكد أن تقنية النطاق قياسية (
RFC 2616 ). وهو مدعوم أصلاً بواسطة المتصفحات وهم قادرون على تخزين أجزاء البيانات المستلمة مؤقتًا. لذلك ، يتم تنفيذ الطلب التالي من المتصفح ، إذا كان هناك ذاكرة تخزين مؤقت فعلية للجزء المطلوب ، على العميل دون إزعاج خوادمك.
إذا قمت بإضافة
CDN بين العميل والخوادم ، يمكنك الحصول على طبقة أخرى قوية من التخزين المؤقت. وفي الحالة الأولى ، سيحدث التخزين المؤقت لعميل نهائي محدد ، ثم يتم إقرانه مع شبكة CDN ، ستحصل على فرصة تخزين البيانات بالفعل لمجموعة من العملاء النهائيين.
وبالتالي ، من أجل تقديم طلب حقيقي إلى الخادم ، يحتاج الطلب إلى تجاوز مستويين من التخزين المؤقت ، كل منهما يقلل من حجم الطلبات إلى الخادم الوجهة. بالطبع ، "الشك" النهائي ، في مسار الطلب ، يمكن أن يكون الخادم الخاص بك مع ذاكرة التخزين المؤقت الخاصة به.
من ميزات استخدام تقنية النطاق ، يجب مراعاة أنها تعمل مع أجزاء من وحدات البايت. على سبيل المثال مع البيانات الثنائية. ويمكننا طلب فترات البايت بالضبط. يجب أن يستجيبوا ، على التوالي - مع كتلة ثنائية.
أعتقد أن المقدمة كافية. دعنا ننتقل إلى حالة خاصة ، وبالفعل على سبيل المثال ، سنكتشف كيف يمكننا استخدام كل هذه "السعادة" في مشكلة معينة - طلب الشموع لفترة معينة مع تعرض معين.
بالنسبة للمبتدئين ، مثل نحن بحاجة للعمل مع الهياكل الثنائية ، دعونا ترميز شمعة لدينا. لهذا نأخذ ، على سبيل المثال ، الهيكل التالي:
moment: int32 // min: float64 // max: float64 // open: float64 // close: float64 // volume: float64 // average: float64 //
وبالتالي ، سيشغل هيكلنا 52 بايت. نأخذه كمبلغ - الحد الأدنى للكتلة الثنائية.
بعد ذلك ، ننفذ وحدة تحكم تقبل طلبات GET وتقوم بتحليل رأس النطاق. في هذه الحالة ، سنقوم بترجمة الفاصل الزمني المطلوب إلى كمي عن طريق القسمة البسيطة دون الباقي ، أي على سبيل المثال ، طلب فاصل:
Range: 5200-52000يجب أن نفسر في البعد الكمي لدينا:
Range: 100-1000في الجوهر ، سيكون هذا هو الإزاحة والحد من استعلام قاعدة البيانات الخاصة بنا.
مع تعريف التعرض بسيط للغاية ، يمكننا وضعه في عنوان url. على سبيل المثال:
/api/v1/candles/7mعلى سبيل المثال سنطلب الشموع مع التعرض لمدة 7 دقائق. بطبيعة الحال ، نفترض أنه يمكن تغيير هذه المعلمة بناء على طلب الواجهة الأمامية.
الآن ، بعد معرفة التعرض المطلوب وعدد الشمعة الأولى وعدد الشمعة الأخيرة التي تطلبها الواجهة الأمامية ، يمكننا تنفيذ الاستعلام المقابل لقاعدة البيانات.
بشكل عام ، إنها تذكرنا بمشكلة ترقيم الصفحات الكلاسيكية.
بقيت أشياء صغيرة. يتم تحويل كل سطر من نتيجة الاستعلام إلى بنية ثنائية (نفس الكم) ويتم عرض الصفيف الثنائي الناتج كنتيجة الاستعلام ، ويتم إرجاع نطاق المحتوى إلى رأس الاستجابة:
Content-Range: [ ] / [[ ] * [ ]]توقف ولكن كيف يمكن للجبهة أن تطلب الفترة الزمنية المطلوبة ، وحتى في فترة البايت؟ كيف يعرف أرقام الشموع هناك؟ هنا أيضًا تم اختراع كل شيء. يدعم النطاق الإزاحة النسبية ، على سبيل المثال
Range: -52طلب 52 بايت من النهاية. على سبيل المثال الشمعة الأخيرة. الآن ، بمعرفة اللحظة الأخيرة من الشمعة الأخيرة ، مع العلم ، من الجواب ، الحجم الكلي لـ "الملف" ، يمكنك حساب إجمالي عدد الشموع ، ومن هنا حدد الفاصل الزمني للبايت لطلب التعرض للوقت المطلوب.
إذا أردت فجأة طرح سؤال - لماذا هذه الصعوبات؟ يرجى العودة إلى أهدافك. هذه التقنية "حجبت" الاستفسارات التحليلية لقاعدة البيانات إلى ملفات ثنائية لـ CDN والمتصفح. يسمح لك هذا بنقل معظم الطلبات المتكررة إلى CDN والعميل النهائي.
ربما يطرح سؤال آخر - لماذا لا تستخدم التخزين المؤقت البسيط لطلبات GET؟ جيد. دعنا نحصل على حق. إذا قمنا بتنفيذ مثل هذا الطلب في REST الكلاسيكي:
GET /api/v1/candles/7m?from=01-03-2018&to=31-03-2018سنحصل على ذاكرة تخزين مؤقت فريدة لهذا الطلب. بتنفيذ الاستعلام التالي:
GET /api/v1/candles/7m?from=15-03-2018&to=20-03-2018سنحصل على ذاكرة تخزين مؤقت فريدة أخرى .... على الرغم من أن الطلب الثاني يطلب البيانات الواردة في رد الأول.
لذلك ، في حالة التنفيذ (النطاق) المقترح أعلاه ، لن يشكل الطلب الثاني ذاكرة تخزين مؤقت منفصلة ، ولكنه سيستخدم البيانات التي تم تلقيها بالفعل من الطلب الأول. ولن تحصل على الخادم. وهذا ، حفظ حجم ذاكرة التخزين المؤقت وتقليل عدد المكالمات إلى الخادم.
هل هناك أي سلبيات لهذه التكنولوجيا؟ نعم إنها واضحة:
- هذه التقنية ليست مناسبة لتغيير البيانات بمرور الوقت ، مثل بناءً على التخزين المؤقت الكلي.
- يقوم CDN CloudFlare بتخزين الملفات بشكل كامل فقط. هذا يعني أنه إذا طلب العميل النهائي فاصل زمني ، على سبيل المثال ، من 1 إلى 100 بايت ، فسيطلب CloudFlare بالفعل الملف بأكمله من الخادم. على سبيل المثال في حالتنا ، سيتم تحميل جميع الشموع مع تعرض معين. سيضعها بنفسه وسيوزعها بالفعل بنفسه. يمكن اعتبار هذا زائد ، إن لم يكن للقيود المفروضة على المكان. وإذا كان بإمكانك تكوين إجابات "ثقيلة" ، والعديد من المعلمات ، فعندئذٍ ... بشكل عام ، من الواضح أن المكان سينتهي. ربما لم نتمكن من تكوينه بشكل صحيح. ولكن النتيجة حتى الآن على النحو التالي.
- مطلوب لإدارة المخابئ بحكمة. هناك آليات كافية لهذا ، لكنها تتطلب ضبط.
- يجب أن تكون الواجهة الأمامية قادرة على تحليل البيانات الثنائية ولديها مجموعة بيانات على متن السفينة للعمل مع طلبات النطاق.
سأقوم بصياغة جدوى تنفيذ هذه الاستراتيجية على النحو التالي - عندما تحتاج إليها ، سوف تفهم. إذا كانت هناك شكوك الآن ، فمن المفيد أن تعرف عنها ، ولكن لا تهتم.