أثناء إعادة هيكلة تبادل العملات الرقمية ، تقرر مراجعة مفهوم العمل مع تاريخ السوق. في الحالة الكلاسيكية ، يتم توزيع تاريخ السوق بطريقتين:
1. واجهة REST.
2. اشتراك البث WEBSocket.
غالبًا ما يتم استخدام طريقة REST للحصول على البيانات التاريخية ، بينما يرسل WEBSocket معلومات مباشرة عبر الإنترنت. في بعض الحالات ، لا يتم استخدام WEBSocket على الإطلاق ، ويتم إجراء التحديثات عن طريق الطلبات المنتظمة عبر REST.
ويبدو أن الجميع سعداء. ولكن ، عند الفحص الدقيق ، يصبح الحجم الهائل لمثل هذا المفهوم واضحًا. تقع معظمها على REST. لضمان عمل واجهة REST ، يجب علينا إنشاء خلفية تلبي متطلبات الأنظمة المحملة بشكل كبير. وبطبيعة الحال ، يمكنك هنا اختيار خيارات الحلول المختلفة من PHP إلى Golang العصرية الآن.
مطلوب أيضًا إنشاء بنية تحتية يسهل الوصول إليها ، وتنفيذ تفاهات مثل CI / CD للخدمات ، وتزويد كل هذا بالأخصائيين المناسبين للتطوير والصيانة ، وما إلى ذلك ، إلخ.
في نفس الوقت ، هو تاريخ السوق التاريخي الذي يشغل الجزء الأكبر من مساحة القرص. وعادة ما يتم تخزينها في قاعدة البيانات. من ناحية ، يسمح لنا هذا بحل مشكلة التكتل ، ولكن في الأحجام الحرجة ، يصبح عبئًا لا يطاق ويشكل مهام غير تافهة لفريق DevOps والمطورين.
بشكل عام ... البساطة والاتساق الواضح لهذا المفهوم قد تحطم إلى حياة قاسية.
بشكل منفصل ، تحتاج إلى ملاحظة خصوصية تاريخ السوق. يتراكم دائما (ينمو). على سبيل المثال في لغة مبرمج قاعدة البيانات ، نقوم دائمًا بإدراج ثم تحديد. لكن غير قابل للقسمة. على سبيل المثال وظائف قاعدة بيانات رائعة للتنظيم والتحسين ، إلخ. تصبح البيانات المخزنة دون المطالبة بها.
خاصية أخرى مهمة في تاريخ السوق هي هيكلها المحدد بوضوح. على سبيل المثال ، تحتوي الشمعة في المخطط على ثمانية معلمات فقط:
1. لحظة الزمان ؛
2. المعرض.
3. السعر الأقصى.
4. الحد الأدنى للسعر.
5. سعر الافتتاح.
6. سعر الإغلاق.
7. الحجم ؛
8. متوسط السعر.
ويمكن قول الشيء نفسه عن الصفقات.
استنادًا إلى هذه المتطلبات الأساسية ، وأيضًا مسلحين بالخبرة ، توصلت بسرعة إلى استنتاج مفاده أنه من الأصح اعتبار تاريخ السوق كتيار منظم.
على سبيل المثال ، يمكن اعتبار تيار مع الشموع كمجموعة من الهياكل الثنائية:
moment: int32
exposition: int32
min: float64
max: float64
open: float64
close: float64
volume: float64
average: float64الإجمالي: 56 بايت.
على سبيل المثال ، سيتم وصف مثل هذه الشمعة في JSON على النحو التالي:
{ "date":1501004700, "high":0.08053391, "low":0.08020004, "open":0.08030001, "close":0.0803542, "volume":48.62169347, "weightedAverage":0.08038445 }
الإجمالي: 167 بايت.
الربح في الحجم واضح. وهذه حركة مرور أقل ، وسرعة تسليم أعلى للعميل.
وهنا ، بالطبع ، يتبادر إلى الذهن BSON. لكنها لا تحل مشكلة الحاجة إلى الواجهة الخلفية ، وبصفة عامة لا تحل المشكلة بشكل أساسي. بالإضافة إلى ذلك ، لا يدعمه المستعرضات.
نظرت في الاتجاه الآخر. الشبكة لديها الكثير من الموارد التي تعمل مع الخيوط. هذه هي موارد الصوت والفيديو. يظهرون كل تلك العلامات الضرورية:
- العمل بكميات كبيرة من البيانات ؛
- التعامل بشكل مثالي مع الأحمال العالية ؛
- إنهم قادرون على تقديم المحتوى عبر الإنترنت ، ولكن في نفس الوقت يجعلون من الممكن الوصول إلى البيانات التاريخية.
لقد تعمقت قليلاً في الفيديو المتدفق ، مما سمح لي بحل جميع المشاكل المذكورة أعلاه بشكل جذري حسب تاريخ السوق. كل السحر ، كما اتضح ، مخفي في تقنية
Content-Range المدعومة من خارج الصندوق ، على سبيل المثال ، Nginx. يسمح لك بالوصول إلى أي منطقة من الموارد الثابتة (ملف على الخادم) دون استخدام الواجهة الخلفية. بشكل عام ، يحدث هذا على النحو التالي: تشير إلى عنوان URL الذي يشير إلى التعرض الذي تريد إرجاعه في الرأس. على سبيل المثال: النطاق: 100-200. لن أتطرق إلى التعقيدات ، يمكنك العثور على جميع الفروق الدقيقة في التكنولوجيا في المقالات المتخصصة. أعتقد أن الجوهر واضح.
في الواقع ، الآن ، على الجانب الأمامي ، يمكنك تنظيم مناشدة للجزء الضروري من الملف ، على سبيل المثال ، يحتوي على الشموع. وبما أنه من المعروف بالضبط عدد البايتات التي تأخذها شمعة واحدة (56 بايت) ، يمكننا بسهولة تحديد الإزاحة التي نحتاجها. صحيح أننا ما زلنا بحاجة إلى معرفة النقطة الزمنية التي يبدأ منها الجدول الزمني. ويمكن حل ذلك بسهولة عن طريق إضافة رأس إلى الملف ، حجمه ثابت أيضًا.
على سبيل المثال بادئ ذي بدء ، تصل الجبهة إلى الملف من الموضع صفر ، وتتلقى
يتجه. في نفس الوقت ، سيعيد nginx حجم الملف. سيحدد هذا العدد الإجمالي للشموع في الملف ووقت البدء.
الآن ، مع معرفة نقطة البداية ، بعد الحصول على فكرة واضحة عن عدد الشموع ، يمكننا الحصول على أي منها لأي فترة زمنية من الأمام ، دون استخدام خلفية.
آه ، نعم ... لحظة أخرى ... لدينا معلمة مثل تعرض الشمعة. الحل هنا بسيط أيضًا - فنحن نحتفظ بعدة ملفات في آن واحد للتعريضات المختلفة. كمكافأة صغيرة إضافية ، يتم تقليل حجم هيكل الشمعة بمقدار 4 بايت أخرى.
بشكل عام ، كان الحل مثيرًا للاهتمام بما يكفي للتنفيذ ، ولكن اتضح بعد ذلك ، ولا أشعر بالخجل من القول - أرباح رائعة جدًا. والحقيقة هي أن المتصفحات يمكنها تخزين البيانات التي يتم تلقيها بطريقة النطاق في ذاكرة التخزين المؤقت. على سبيل المثال عند الطلب الأمامي التالي للخادم ، إذا تم استلام هذا القسم من الملف بواسطة المستعرض في وقت سابق ، فلن يصل إلى الخادم الخاص بك ، ولكنه سيأخذه من ذاكرة التخزين المؤقت.
ولكن حتى هذا ليس كل شيء. باستخدام CDN ، يمكن أيضًا تكوين التخزين المؤقت بوسائله. على سبيل المثال باختصار ، يمكنك الحصول على نظام قادر على إعطاء كميات كبيرة من تاريخ السوق مع تقليل الحمل على البنية التحتية والخوادم.
وغني عن القول ، لم يعد هناك أي شك في دقة الفكرة؟ الآن هناك أشياء صغيرة حقيقية ... تحتاج إلى إنشاء هذه الملفات نفسها.
كما ذكر أعلاه ، عادة ، تعمل البورصة بوسيلتين لتسليم تاريخ السوق: REST و WEBSocket. هذا الأخير يبث على الإنترنت في تاريخ السوق الحالي. هذه عادة خدمة منفصلة. كما أظهرت الممارسة ، فإن إنهاء هذه الخدمة بحيث تلحق البيانات بالملفات الضرورية ليس بالأمر الصعب ويتم حله حرفياً مع بضع ساعات من عمل المطور. يمكننا القول أنه يسجل في نفس وقت النشرة الإخبارية.
تعد مسألة تسليم الملفات إلى العقد مشكلة مزامنة نظام ملفات كلاسيكية. فريق DevOps يحلها بسهولة وبشكل طبيعي. على سبيل المثال باستخدام rsync.
الآن ، يمكننا القول بأمان - BINGO!
ربما سيطرح السؤال - لماذا تفعل جميع تبادلات التشفير بشكل مختلف؟ ليس لدي إجابة موثوقة على هذا السؤال. لكن هناك أفكار:
- تم إنشاء التبادلات من قبل مطوري التشفير المتعاطفين. ربما لم يكن لديهم فكرة عن عمل التبادلات الكلاسيكية ، ولم يأخذوا في الاعتبار خبراتهم واستخدموا الحلول المتاحة بسهولة للحصول على نتائج سريعة. وهذه حلول نموذجية: نفس REST ومرافقة JSON ؛
- كما يقولون في الناس - هل يعمل؟ لا تلمس. - لأن وقد تم بالفعل إنشاء الاتجاهات التكنولوجية من قبل البورصات الرئيسية ، وقد اقترضتها البورصات الناشئة حديثًا.
إذا كان الموضوع مثيرًا للاهتمام للمجتمع ، فسأواصل المقالات حول الحلول غير القياسية الأخرى التي تم تنفيذها في مشروعنا. كيف يعمل هذا في الممارسة العملية ، يمكنك أن ترى على موقع التبادل (انظر ملفي الشخصي). أقترح بشكل خاص الانتباه إلى عمل الرسم البياني ، الذي يوضح بوضوح جميع أرباح هذه التكنولوجيا.