أرتيم دينيسوف ( , )
Badoo هو أكبر موقع للمواعدة في العالم. لدينا حاليًا حوالي 330 مليون مستخدم مسجل حول العالم. ولكن ما هو أكثر أهمية في سياق حديثنا اليوم هو أننا نقوم بتخزين حوالي 3 بيتابايت من صور المستخدم. يقوم مستخدمونا كل يوم بتحميل حوالي 3,5 مليون صورة جديدة، ويصل حجم القراءة إلى حوالي 80 ألف طلب في الثانية. هذا كثير جدًا بالنسبة لواجهتنا الخلفية، وفي بعض الأحيان توجد صعوبات في ذلك.
سأتحدث عن تصميم هذا النظام الذي يقوم بتخزين وإرسال الصور بشكل عام، وسأنظر إليه من وجهة نظر المطور. سيكون هناك عرض استعادي موجز حول كيفية تطوره، حيث سأحدد المعالم الرئيسية، لكنني سأتحدث فقط بمزيد من التفصيل حول الحلول التي نستخدمها حاليًا.
الآن دعونا نبدأ.
كما قلت، سيكون هذا بأثر رجعي، ولكي نبدأ في مكان ما، دعونا نأخذ المثال الأكثر شيوعا.
لدينا مهمة مشتركة، نحن بحاجة إلى قبول وتخزين وإرسال صور المستخدم. في هذا النموذج، المهمة عامة، يمكننا استخدام أي شيء:
- التخزين السحابي الحديث,
- الحل المعبأ، والذي يوجد منه أيضًا الكثير الآن؛
- يمكننا إعداد العديد من الأجهزة في مركز البيانات الخاص بنا ووضع محركات أقراص ثابتة كبيرة عليها وتخزين الصور هناك.
تاريخيًا، يعيش Badoo - بين الحين والآخر (في الوقت الذي كان فيه في بداياته) - على خوادمه الخاصة، داخل مراكز البيانات الخاصة بنا. ولذلك، كان هذا الخيار الأمثل بالنسبة لنا.
لقد أخذنا عدة آلات، وأطلقنا عليها اسم "الصور"، وحصلنا على مجموعة تقوم بتخزين الصور. ولكن يبدو أن هناك شيئا مفقودا. لكي ينجح كل هذا، نحتاج إلى تحديد الجهاز الذي سنقوم بتخزين الصور عليه بطريقة أو بأخرى. وهنا أيضا ليست هناك حاجة لفتح أمريكا.
نضيف بعض الحقول إلى مساحة التخزين الخاصة بنا والتي تحتوي على معلومات حول المستخدمين. سيكون هذا هو مفتاح المشاركة. في حالتنا، أطلقنا عليه اسم place_id، ويشير معرف المكان هذا إلى المكان الذي يتم فيه تخزين صور المستخدم. نحن نصنع الخرائط.
في المرحلة الأولى، يمكن القيام بذلك يدويًا - نقول أن صورة هذا المستخدم بمثل هذا المكان ستهبط على مثل هذا الخادم. بفضل هذه الخريطة، نعرف دائمًا متى يقوم المستخدم بتحميل صورة، ومكان حفظها، ونعرف من أين نعطيها.
هذا مخطط تافه تمامًا، لكن له مزايا كبيرة جدًا. الأول هو أن الأمر بسيط، كما قلت، والثاني هو أنه من خلال هذا النهج يمكننا بسهولة التوسع أفقيًا عن طريق تسليم سيارات جديدة وإضافتها إلى الخريطة. لا تحتاج إلى القيام بأي شيء آخر.
هكذا كان الأمر بالنسبة لنا لبعض الوقت.
كان هذا حوالي عام 2009. سلموا سيارات وسلموا...
وفي مرحلة ما بدأنا نلاحظ أن هذا المخطط له عيوب معينة. ما هي العيوب؟
أولا وقبل كل شيء، هناك قدرة محدودة. لا يمكننا حشر العديد من محركات الأقراص الثابتة في خادم فعلي واحد كما نرغب. وقد أصبحت هذه مشكلة معينة بمرور الوقت ومع نمو مجموعة البيانات.
والثانية. يعد هذا تكوينًا غير نمطي للآلات، نظرًا لصعوبة إعادة استخدام هذه الآلات في بعض المجموعات الأخرى؛ فهي محددة تمامًا، أي أنها محددة تمامًا. يجب أن تكون ضعيفة الأداء، ولكن في نفس الوقت مع قرص صلب كبير.
كان هذا كل شيء في عام 2009، ولكن من حيث المبدأ، لا تزال هذه المتطلبات ذات صلة اليوم. لدينا بأثر رجعي، لذلك في عام 2009 كان كل شيء سيئا تماما مع هذا.
والنقطة الأخيرة هي السعر.
كان السعر باهظًا جدًا في ذلك الوقت، وكنا بحاجة للبحث عن بعض البدائل. أولئك. كنا بحاجة إلى استغلال المساحة الموجودة في مراكز البيانات والخوادم الفعلية التي يوجد عليها كل هذا بشكل أفضل. وبدأ مهندسو النظام لدينا دراسة كبيرة قاموا فيها بمراجعة مجموعة من الخيارات المختلفة. لقد نظروا أيضًا في أنظمة الملفات المجمعة مثل PolyCeph وLuster. كانت هناك مشاكل في الأداء وعملية صعبة للغاية. رفضوا. لقد حاولنا تركيب مجموعة البيانات بأكملها عبر NFS على كل سيارة من أجل توسيع نطاقها بطريقة أو بأخرى. سارت القراءة أيضًا بشكل سيئ، لقد جربنا حلولًا مختلفة من بائعين مختلفين.
وفي النهاية، استقرينا على استخدام ما يسمى بشبكة منطقة التخزين.
هذه عبارة عن وحدات SHD كبيرة الحجم مصممة خصيصًا لتخزين كميات كبيرة من البيانات. وهي عبارة عن أرفف تحتوي على أقراص يتم تركيبها على أجهزة الإخراج الضوئي النهائية. الذي - التي. لدينا مجموعة من الآلات، صغيرة جدًا، وهذه SHDs، التي تتسم بالشفافية بالنسبة لمنطق الإرسال الخاص بنا، أي. ليتمكن nginx أو أي شخص آخر من تلبية طلبات هذه الصور.
وكان لهذا القرار مزايا واضحة. هذا هو التنمية البشرية المستدامة. الغرض منه هو تخزين الصور. وهذا يعتبر أرخص من مجرد تجهيز الآلات بمحركات الأقراص الصلبة.
زائد الثاني.
وهذا يعني أن القدرة أصبحت أكبر بكثير، أي. يمكننا استيعاب مساحة تخزين أكبر بكثير في حجم أصغر بكثير.
ولكن كانت هناك أيضًا عيوب ظهرت بسرعة كبيرة. مع زيادة عدد المستخدمين والتحميل على هذا النظام، بدأت مشاكل الأداء في الظهور. والمشكلة هنا واضحة تماما - أي SHD، مصمم لتخزين العديد من الصور في حجم صغير، كقاعدة عامة، يعاني من القراءة المكثفة. وهذا ينطبق بالفعل على أي تخزين سحابي أو أي شيء آخر. الآن ليس لدينا مساحة تخزين مثالية تكون قابلة للتطوير بشكل لا نهائي، ويمكنك وضع أي شيء فيها، وسوف تتحمل القراءات بشكل جيد للغاية. وخاصة القراءات العارضة
كما هو الحال مع صورنا، لأن الصور يتم طلبها بشكل غير متناسق، وهذا سيؤثر بشكل كبير على أدائها.
حتى وفقًا للأرقام الحالية، إذا حصلنا على ما يزيد عن 500 دورة في الثانية للصور الموجودة على جهاز متصل به وحدة التخزين، فستبدأ المشكلات بالفعل. وكان الأمر سيئًا بما فيه الكفاية بالنسبة لنا، لأن عدد المستخدمين في تزايد، وستزداد الأمور سوءًا. هذا يحتاج إلى الأمثل بطريقة أو بأخرى.
من أجل التحسين، قررنا في ذلك الوقت، من الواضح، أن ننظر إلى ملف تعريف التحميل - ما يحدث بشكل عام، وما الذي يجب تحسينه.
وهنا كل شيء يلعب في أيدينا.
سبق أن قلت في الشريحة الأولى: لدينا 80 ألف طلب قراءة في الثانية مع 3,5 مليون تحميل فقط في اليوم. أي أن هذا فرق بمقدار ثلاثة أوامر. من الواضح أن القراءة تحتاج إلى التحسين ومن الواضح عمليًا كيفية تحسينها.
هناك نقطة صغيرة أخرى. تفاصيل الخدمة هي أن الشخص يقوم بالتسجيل، وتحميل الصورة، ثم يبدأ في النظر بنشاط إلى الأشخاص الآخرين، مثلهم، ويظهر بنشاط لأشخاص آخرين. ثم يجد رفيقًا أو لا يجد رفيقًا، يعتمد الأمر على كيفية ظهوره، ويتوقف عن استخدام الخدمة لفترة من الوقت. في هذه اللحظة، عندما يستخدمها، تكون صوره ساخنة جدًا - فهي مطلوبة، ويشاهدها الكثير من الأشخاص. بمجرد أن يتوقف عن القيام بذلك، سرعان ما يتوقف عن التعرض لأشخاص آخرين كما كان من قبل، ولا يتم طلب صوره أبدًا تقريبًا.
أولئك. لدينا مجموعة بيانات ساخنة صغيرة جدًا. لكن في نفس الوقت هناك الكثير من الطلبات عليه. والحل الواضح تمامًا هنا هو إضافة ذاكرة تخزين مؤقت.
سوف تحل ذاكرة التخزين المؤقت مع LRU جميع مشاكلنا. ماذا نفعل؟
نضيف مجموعة أخرى صغيرة نسبيًا أمام مجموعتنا الكبيرة المزودة بالتخزين، والتي تسمى مخابئ الصور. هذا في الأساس مجرد وكيل للتخزين المؤقت.
كيف يعمل من الداخل؟ هنا مستخدمنا، وهنا التخزين. كل شيء هو نفسه كما كان من قبل. ماذا نضيف بينهما؟
إنه مجرد جهاز مزود بقرص محلي فعلي، وهو سريع. وهذا مع SSD، على سبيل المثال. ويتم تخزين نوع من ذاكرة التخزين المؤقت المحلية على هذا القرص.
كيف تبدو؟ يرسل المستخدم طلبًا للحصول على صورة. يبحث NGINX عنه أولاً في ذاكرة التخزين المؤقت المحلية. إذا لم يكن الأمر كذلك، فما عليك سوى تمرير proxy_pass إلى وحدة التخزين الخاصة بنا، وتنزيل الصورة من هناك وإعطائها للمستخدم.
لكن هذا عادي للغاية وليس من الواضح ما يحدث في الداخل. يعمل شيء من هذا القبيل.
يتم تقسيم ذاكرة التخزين المؤقت منطقيًا إلى ثلاث طبقات. عندما أقول "ثلاث طبقات"، فهذا لا يعني أن هناك نوعًا من النظام المعقد. لا، هذه مجرد ثلاثة أدلة مشروطة في نظام الملفات:
- هذا هو المخزن المؤقت حيث يتم نقل الصور التي تم تنزيلها للتو من الوكيل.
- هذه ذاكرة تخزين مؤقت ساخنة تقوم بتخزين الصور المطلوبة حاليًا.
- وذاكرة التخزين المؤقت الباردة، حيث يتم إخراج الصور تدريجيًا من ذاكرة التخزين المؤقت الساخنة عندما تصل إليها طلبات أقل.
لكي ينجح هذا، نحتاج إلى إدارة ذاكرة التخزين المؤقت هذه بطريقة أو بأخرى، ونحتاج إلى إعادة ترتيب الصور الموجودة فيها، وما إلى ذلك. وهذه أيضًا عملية بدائية للغاية.
يكتب Nginx ببساطة إلى RAMDisk Access.log لكل طلب، حيث يشير إلى المسار إلى الصورة التي تم تقديمها حاليًا (المسار النسبي بالطبع)، والقسم الذي تم تقديمه فيه. أولئك. قد تقول "الصورة 1" ثم إما مخزن مؤقت، أو ذاكرة تخزين مؤقت سريعة، أو ذاكرة تخزين مؤقت باردة، أو وكيل.
اعتمادا على هذا، نحن بحاجة إلى أن نقرر بطريقة أو بأخرى ما يجب القيام به مع الصورة.
لدينا برنامج خفي صغير يعمل على كل جهاز يقرأ هذا السجل باستمرار ويخزن إحصائيات حول استخدام صور معينة في ذاكرته.
إنه يجمع ببساطة هناك ويحتفظ بالعدادات ويقوم بما يلي بشكل دوري. يقوم بنقل الصور المطلوبة بشكل نشط، والتي يوجد بها العديد من الطلبات، إلى ذاكرة التخزين المؤقت الساخنة، أينما كانت.
الصور التي يتم طلبها نادرًا والتي أصبحت مطلوبة بشكل أقل يتم دفعها تدريجيًا من ذاكرة التخزين المؤقت الساخنة إلى ذاكرة التخزين المؤقت الباردة.
وعندما تنفد المساحة في ذاكرة التخزين المؤقت، نبدأ ببساطة في حذف كل شيء من ذاكرة التخزين المؤقت الباردة بشكل عشوائي. وبالمناسبة، هذا يعمل بشكل جيد.
لكي يتم حفظ الصورة فورًا عند توكيلها إلى المخزن المؤقت، نستخدم التوجيه proxy_store ويكون المخزن المؤقت أيضًا RAMDisk، أي. بالنسبة للمستخدم فهو يعمل بسرعة كبيرة. يتعلق هذا بالأجزاء الداخلية لخادم التخزين المؤقت نفسه.
السؤال المتبقي هو كيفية توزيع الطلبات عبر هذه الخوادم.
لنفترض أن هناك مجموعة مكونة من عشرين جهاز تخزين وثلاثة خوادم للتخزين المؤقت (هكذا حدث ذلك).
نحن بحاجة إلى تحديد الطلبات التي تتعلق بالصور ومكان إرسالها بطريقة أو بأخرى.
الخيار الأكثر شيوعًا هو Round Robin. أو تفعل ذلك عن طريق الصدفة؟
من الواضح أن هذا له عدد من العيوب لأننا سنستخدم ذاكرة التخزين المؤقت بشكل غير فعال للغاية في مثل هذه الحالة. ستصل الطلبات إلى بعض الأجهزة العشوائية: هنا تم تخزينها مؤقتًا، ولكن في الجهاز التالي لم تعد موجودة. وإذا نجح كل هذا، فسيكون الأمر سيئًا للغاية. حتى مع وجود عدد قليل من الأجهزة في الكتلة.
نحتاج إلى أن نحدد بطريقة لا لبس فيها الخادم الذي سيرسل أي طلب.
هناك طريقة عادية. نحن نأخذ التجزئة من عنوان URL أو التجزئة من مفتاح التجزئة الخاص بنا، الموجود في عنوان URL، ونقسمه على عدد الخوادم. سيعمل؟ سوف.
أولئك. لدينا طلب بنسبة 2%، على سبيل المثال، بالنسبة لبعض "example_url" سيصل دائمًا إلى الخادم مع الفهرس "XNUMX"، وسيتم التخلص باستمرار من ذاكرة التخزين المؤقت بأفضل طريقة ممكنة.
ولكن هناك مشكلة في إعادة التوزيع في مثل هذا المخطط. إعادة المشاركة - أعني تغيير عدد الخوادم.
لنفترض أن مجموعة التخزين المؤقت الخاصة بنا لم تعد قادرة على التعامل مع الأمر وقررنا إضافة جهاز آخر.
دعونا نضيف.
الآن كل شيء قابل للقسمة ليس على ثلاثة، بل على أربعة. وبالتالي، فإن جميع المفاتيح التي اعتدنا أن نمتلكها تقريبًا، وجميع عناوين URL تقريبًا موجودة الآن على خوادم أخرى. تم إبطال ذاكرة التخزين المؤقت بأكملها للحظة واحدة. سقطت جميع الطلبات على مجموعة التخزين الخاصة بنا، وأصبحت على ما يرام، وفشلت الخدمة، وأصبح المستخدمون غير راضين. لا أريد أن أفعل ذلك.
هذا الخيار لا يناسبنا أيضًا.
الذي - التي. ماذا علينا ان نفعل؟ يجب أن نستفيد بطريقة أو بأخرى من ذاكرة التخزين المؤقت بشكل فعال، ونرسل نفس الطلب على نفس الخادم مرارًا وتكرارًا، ولكن يجب أن نكون مقاومين لإعادة التوزيع. وهناك مثل هذا الحل، وهو ليس بهذا التعقيد. يطلق عليه التجزئة المتسقة.
كيف تبدو هذه؟
نأخذ بعض الوظائف من مفتاح المشاركة وننشر جميع قيمها على الدائرة. أولئك. عند النقطة 0، تتقارب قيمها الدنيا والقصوى. بعد ذلك، نضع جميع خوادمنا في نفس الدائرة بهذه الطريقة تقريبًا:
يتم تعريف كل خادم بنقطة واحدة، وبالتالي يتم خدمة القطاع الذي يسير في اتجاه عقارب الساعة بواسطة هذا المضيف. عندما تأتي الطلبات إلينا، نرى على الفور أنه، على سبيل المثال، الطلب أ - لديه تجزئة هناك - ويتم تقديمه بواسطة الخادم 2. الطلب ب - عن طريق الخادم 3. وهكذا.
ماذا يحدث في هذه الحالة أثناء إعادة النشر؟
نحن لا نبطل ذاكرة التخزين المؤقت بأكملها، كما كان من قبل، ولا نغير جميع المفاتيح، لكننا نغير كل قطاع على مسافة قصيرة بحيث يتناسب خادمنا السادس، الذي نريد إضافته، مع المساحة الحرة، و نضيفه هناك.
وبطبيعة الحال، في مثل هذه الحالة، يتم إخراج المفاتيح أيضًا. لكنهم يخرجون أضعف بكثير من ذي قبل. ونحن نرى أن أول مفتاحين لدينا ظلوا على خوادمهم، وتغير خادم التخزين المؤقت فقط للمفتاح الأخير. يعمل هذا بكفاءة تامة، وإذا قمت بإضافة مضيفين جدد بشكل تدريجي، فلن تكون هناك مشكلة كبيرة هنا. يمكنك إضافة وإضافة القليل في كل مرة، والانتظار حتى تمتلئ ذاكرة التخزين المؤقت مرة أخرى، وكل شيء يعمل بشكل جيد.
يبقى السؤال الوحيد مع الرفض. لنفترض أن نوعًا ما من السيارات معطل.
ولن نرغب حقًا في إعادة إنشاء هذه الخريطة في هذه اللحظة، أو إبطال جزء من ذاكرة التخزين المؤقت، وما إلى ذلك، على سبيل المثال، إذا تم إعادة تشغيل الجهاز، ونحتاج إلى تلبية الطلبات بطريقة أو بأخرى. نحن ببساطة نحتفظ بنسخة احتياطية واحدة من الصور في كل موقع، والتي تعمل كبديل لأي جهاز معطل حاليًا. وإذا أصبح أحد خوادمنا غير متاح فجأة، فإن حركة المرور تذهب إلى هناك. بطبيعة الحال، ليس لدينا أي ذاكرة تخزين مؤقت هناك، أي. الجو بارد، ولكن على الأقل تتم معالجة طلبات المستخدم. إذا كانت هذه فترة زمنية قصيرة، فإننا نختبرها بهدوء تام. هناك المزيد من الحمل على التخزين. إذا كانت هذه الفترة طويلة، فيمكننا بالفعل اتخاذ قرار - لإزالة هذا الخادم من الخريطة أم لا، أو ربما استبداله بآخر.
هذا فيما يتعلق بنظام التخزين المؤقت. دعونا ننظر إلى النتائج.
يبدو أنه لا يوجد شيء معقد هنا. لكن هذه الطريقة لإدارة ذاكرة التخزين المؤقت أعطتنا معدل خدعة يبلغ حوالي 98٪. أولئك. من بين 80 ألف طلب في الثانية، يصل 1600 طلب فقط إلى التخزين، وهذا حمل طبيعي تمامًا، فهم يتحملونه بهدوء، لدينا دائمًا احتياطي.
لقد وضعنا هذه الخوادم في ثلاث من مراكزنا النامية، وحصلنا على ثلاث نقاط تواجد - براغ وميامي وهونج كونج.
الذي - التي. فهي تقع محليًا بشكل أو بآخر في كل سوق من الأسواق المستهدفة لدينا.
وكمكافأة رائعة، حصلنا على وكيل التخزين المؤقت هذا، والذي تكون وحدة المعالجة المركزية فيه خاملة بالفعل، لأنه ليست هناك حاجة إليه لخدمة المحتوى. وهناك، باستخدام NGINX+ Lua، قمنا بتنفيذ الكثير من المنطق النفعي.
على سبيل المثال، يمكننا تجربة webp أو jpeg التقدمي (هذه تنسيقات حديثة فعالة)، ومعرفة مدى تأثيرها على حركة المرور، واتخاذ بعض القرارات، وتمكينها لبعض البلدان، وما إلى ذلك؛ قم بتغيير الحجم الديناميكي أو قص الصور بسرعة.
تعد هذه حالة استخدام جيدة، على سبيل المثال، عندما يكون لديك تطبيق جوال يعرض الصور، ولا يريد تطبيق الهاتف المحمول إهدار وحدة المعالجة المركزية الخاصة بالعميل عند طلب صورة كبيرة ثم تغيير حجمها إلى حجم معين من أجل دفعها إلى الداخل المنظر. يمكننا ببساطة تحديد بعض المعلمات ديناميكيًا في عنوان URL الشرطي لـ UPort، وستعمل ذاكرة التخزين المؤقت للصور على تغيير حجم الصورة نفسها. كقاعدة عامة، سيحدد الحجم الموجود فعليًا على القرص، وهو أقرب ما يمكن إلى الحجم المطلوب، ثم يبيعه بإحداثيات محددة.
بالمناسبة، لقد قمنا بتوفير تسجيلات فيديو للسنوات الخمس الماضية لمؤتمر مطوري الأنظمة عالية التحميل . شاهد وتعلم وشارك واشترك .
يمكننا أيضًا إضافة الكثير من منطق المنتج هناك. على سبيل المثال، يمكننا إضافة علامات مائية مختلفة باستخدام معلمات URL، ويمكننا تعتيم الصور أو تعتيمها أو تقسيمها إلى وحدات بكسل. يحدث هذا عندما نريد إظهار صورة لشخص ما، ولكننا لا نريد إظهار وجهه، وهذا يعمل بشكل جيد، ويتم تنفيذ كل شيء هنا.
ماذا حصلنا؟ لقد حصلنا على ثلاث نقاط تواجد، ومعدل خدعة جيد، وفي الوقت نفسه ليس لدينا وحدة معالجة مركزية خاملة على هذه الأجهزة. لقد أصبح الآن، بالطبع، أكثر أهمية من ذي قبل. نحن بحاجة إلى أن نمنح أنفسنا سيارات أقوى، لكن الأمر يستحق ذلك.
وهذا يتعلق بعودة الصور. كل شيء هنا واضح وواضح تمامًا. أعتقد أنني لم أكتشف أمريكا، فكل CDN تقريبًا يعمل بهذه الطريقة.
وعلى الأرجح، قد يكون لدى المستمع المتطور سؤال: لماذا لا نغير كل شيء إلى CDN؟ سيكون الأمر مشابهًا تقريبًا، حيث يمكن لجميع شبكات CDN الحديثة القيام بذلك. وهناك عدد من الأسباب.
الأول هو الصور الفوتوغرافية.
هذه هي إحدى النقاط الرئيسية في بنيتنا التحتية، ونحن بحاجة إلى أكبر قدر ممكن من السيطرة عليها. إذا كان هذا حلاً من نوع ما من مورد خارجي، ولم يكن لديك أي سلطة عليه، فسيكون من الصعب جدًا عليك التعايش معه عندما يكون لديك مجموعة بيانات كبيرة، وعندما يكون لديك تدفق كبير جدًا من طلبات المستخدمين.
اسمحوا لي أن أقدم لكم مثالا. الآن، بفضل بنيتنا التحتية، يمكننا، على سبيل المثال، في حالة حدوث بعض المشكلات أو الضربات تحت الأرض، الذهاب إلى الآلة والعبث هناك، نسبيًا. يمكننا إضافة مجموعة من بعض المقاييس التي نحتاجها فقط، ويمكننا التجربة بطريقة ما، ومعرفة مدى تأثير ذلك على الرسوم البيانية، وما إلى ذلك. يتم الآن جمع الكثير من الإحصائيات حول مجموعة التخزين المؤقت هذه. ونحن ننظر إليها بشكل دوري ونقضي وقتًا طويلاً في استكشاف بعض الحالات الشاذة. إذا كان الأمر من جانب CDN، فسيكون من الصعب السيطرة عليه. أو على سبيل المثال، في حالة وقوع حادث ما، نعرف ما حدث، ونعرف كيف نتعايش معه وكيف نتغلب عليه. هذا هو الاستنتاج الأول.
الاستنتاج الثاني أيضًا تاريخي إلى حد ما، لأن النظام كان يتطور لفترة طويلة، وكان هناك العديد من متطلبات العمل المختلفة في مراحل مختلفة، ولا تتناسب دائمًا مع مفهوم CDN.
والنقطة التي تلي من النقطة السابقة هي
وذلك لأنه في ذاكرة التخزين المؤقت للصور لدينا الكثير من المنطق المحدد، والذي لا يمكن إضافته دائمًا عند الطلب. من غير المحتمل أن يضيف أي CDN بعض الأشياء المخصصة لك بناءً على طلبك. على سبيل المثال، تشفير عناوين URL إذا كنت لا تريد أن يتمكن العميل من تغيير شيء ما. هل تريد تغيير عنوان URL الموجود على الخادم وتشفيره، ثم إرسال بعض المعلمات الديناميكية هنا.
ما الاستنتاج الذي يوحي به هذا؟ في حالتنا، CDN ليس بديلاً جيدًا جدًا.
وفي حالتك، إذا كان لديك بعض متطلبات العمل المحددة، فيمكنك بسهولة تنفيذ ما أظهرته لك بنفسك. وهذا سيعمل بشكل مثالي مع ملف تعريف تحميل مماثل.
ولكن إذا كان لديك نوع من الحل العام، والمهمة ليست محددة للغاية، فيمكنك أن تأخذ CDN بأمان تام. أو إذا كان الوقت والموارد أكثر أهمية بالنسبة لك من السيطرة.
وتحتوي شبكات CDN الحديثة تقريبًا على كل ما أخبرتك عنه الآن. باستثناء زائد أو ناقص بعض الميزات.
هذا يتعلق بالتخلي عن الصور.
دعونا الآن نتقدم قليلًا في معرضنا الاستعادي ونتحدث عن التخزين.
كان عام 2013 يمر.
تمت إضافة خوادم التخزين المؤقت، واختفت مشاكل الأداء. كل شيء على ما يرام. مجموعة البيانات آخذة في النمو. اعتبارًا من عام 2013، كان لدينا حوالي 80 خادمًا متصلاً بالتخزين، وحوالي 40 خادمًا للتخزين المؤقت في كل وحدة تحكم DC. هذا هو 560 تيرابايت من البيانات في كل وحدة تحكم مركزية، أي XNUMX تيرابايت من البيانات. حوالي بيتابايت في المجموع.
ومع نمو مجموعة البيانات، بدأت تكاليف التشغيل في الارتفاع بشكل ملحوظ. ماذا يعني هذا؟
في هذا المخطط المرسوم - مع شبكة SAN، مع الأجهزة وذاكرة التخزين المؤقت المتصلة بها - هناك الكثير من نقاط الفشل. إذا كنا قد تعاملنا بالفعل مع فشل خوادم التخزين المؤقت من قبل، فكل شيء كان متوقعًا ومفهومًا إلى حد ما، ولكن من ناحية التخزين كان كل شيء أسوأ بكثير.
أولاً، شبكة منطقة التخزين (SAN) نفسها، والتي يمكن أن تفشل.
ثانيًا، يتم توصيله عبر البصريات بالآلات النهائية. قد تكون هناك مشاكل مع البطاقات الضوئية وشمعات الإشعال.
بالطبع، ليس هناك الكثير منهم كما هو الحال مع SAN نفسها، ولكن، مع ذلك، هذه هي أيضا نقاط الفشل.
التالي هو الجهاز نفسه المتصل بالتخزين. ويمكن أن تفشل أيضا.
في المجموع، لدينا ثلاث نقاط من الفشل.
علاوة على ذلك، بالإضافة إلى نقاط الفشل، هناك صيانة مكثفة للمخزن نفسه.
يعد هذا نظامًا معقدًا متعدد المكونات، وقد يواجه مهندسو الأنظمة صعوبة في العمل معه.
والنقطة الأخيرة والأكثر أهمية. إذا حدث فشل في أي من هذه النقاط الثلاث، فلدينا فرصة غير معدومة لفقد بيانات المستخدم لأن نظام الملفات قد يتعطل.
لنفترض أن نظام الملفات لدينا معطل. أولاً، يستغرق تعافيه وقتًا طويلاً - قد يستغرق الأمر أسبوعًا مع كمية كبيرة من البيانات. وثانيًا، في النهاية سننتهي على الأرجح بمجموعة من الملفات غير المفهومة التي يجب دمجها بطريقة ما في صور المستخدم. ونحن نخاطر بفقدان البيانات. الخطر مرتفع جدًا. وكلما حدثت مثل هذه المواقف في كثير من الأحيان، وكلما زادت المشاكل في هذه السلسلة بأكملها، كلما زاد هذا الخطر.
كان لا بد من القيام بشيء حيال ذلك. وقررنا أننا نحتاج فقط إلى نسخ البيانات احتياطيًا. وهذا في الواقع حل واضح وجيد. ماذا فعلنا؟
هذا ما كان يبدو عليه خادمنا عندما كان متصلاً بالتخزين من قبل. هذا قسم رئيسي واحد، وهو مجرد جهاز كتلة يمثل في الواقع حاملًا للتخزين عن بعد عبر البصريات.
لقد أضفنا للتو قسمًا ثانيًا.
لقد وضعنا وحدة تخزين ثانية بجانبه (لحسن الحظ، فهي ليست باهظة الثمن من حيث المال)، وأطلقنا عليها اسم قسم النسخ الاحتياطي. وهو متصل أيضًا عبر البصريات ويقع على نفس الجهاز. لكننا بحاجة إلى مزامنة البيانات بينهما بطريقة أو بأخرى.
هنا نقوم ببساطة بإنشاء قائمة انتظار غير متزامنة في مكان قريب.
انها ليست مشغولة جدا. نحن نعلم أنه ليس لدينا سجلات كافية. قائمة الانتظار هي مجرد جدول في MySQL تُكتب فيه سطور مثل "تحتاج إلى عمل نسخة احتياطية لهذه الصورة". مع أي تغيير أو تحميل، نقوم بالنسخ من القسم الرئيسي إلى النسخ الاحتياطي باستخدام عامل غير متزامن أو مجرد نوع من العاملين في الخلفية.
وبالتالي لدينا دائمًا قسمان متسقان. حتى لو فشل جزء واحد من هذا النظام، يمكننا دائمًا تغيير القسم الرئيسي بنسخة احتياطية، وسيستمر كل شيء في العمل.
ولكن بسبب هذا، يزداد حمل القراءة بشكل كبير، لأن... بالإضافة إلى العملاء الذين قرأوا من القسم الرئيسي، لأنهم ينظرون أولاً إلى الصورة هناك (وهي أحدث هناك)، ثم يبحثون عنها في النسخة الاحتياطية، إذا لم يعثروا عليها (لكن NGINX يفعل ذلك فقط)، نظامنا هو أيضًا نسخة احتياطية إضافية تُقرأ الآن من القسم الرئيسي. لا يعني ذلك أن هذا كان عنق الزجاجة، لكنني لم أرغب في زيادة الحمل، بشكل أساسي، بهذه الطريقة.
وأضفنا قرصًا ثالثًا، وهو SSD صغير، وأطلقنا عليه اسم المخزن المؤقت.
كيف يعمل الآن.
يقوم المستخدم بتحميل صورة إلى المخزن المؤقت، ثم يتم طرح حدث في قائمة الانتظار للإشارة إلى أنه يجب نسخه إلى قسمين. يتم نسخها، وتعيش الصورة في المخزن المؤقت لبعض الوقت (على سبيل المثال، يوم واحد)، وعندها فقط يتم مسحها من هناك. يؤدي هذا إلى تحسين تجربة المستخدم بشكل كبير، لأن المستخدم يقوم بتحميل صورة، كقاعدة عامة، تبدأ الطلبات على الفور في المتابعة، أو قام بنفسه بتحديث الصفحة وتحديثها. ولكن كل هذا يتوقف على التطبيق الذي يقوم بالتحميل.
أو، على سبيل المثال، الأشخاص الآخرون الذين بدأوا في إظهار أنفسهم، يرسلون الطلبات على الفور بعد هذه الصورة. لم يتم تخزينه بعد في ذاكرة التخزين المؤقت؛ الطلب الأول يحدث بسرعة كبيرة. في الأساس نفس الشيء من ذاكرة التخزين المؤقت للصور. التخزين البطيء لا يشارك في هذا على الإطلاق. وعندما يتم مسحه بعد يوم واحد، يكون إما مخزنًا مؤقتًا بالفعل على طبقة التخزين المؤقت لدينا، أو على الأرجح لم يعد أحد بحاجة إليه. أولئك. لقد نمت تجربة المستخدم هنا بشكل جيد للغاية بسبب مثل هذه التلاعبات البسيطة.
حسنًا، والأهم من ذلك: توقفنا عن فقدان البيانات.
دعنا نقول فقط أننا توقفنا يحتمل نفقد البيانات، لأننا لم نفقدها حقًا. ولكن كان هناك خطر. ونحن نرى أن هذا الحل بالطبع جيد، لكنه يشبه إلى حد ما تخفيف أعراض المشكلة، بدلاً من حلها بالكامل. ولا تزال هناك بعض المشاكل.
أولاً، هذه نقطة فشل في شكل المضيف المادي نفسه الذي تعمل عليه كل هذه الآلية، فهو لم يختف.
ثانيا، لا تزال هناك مشاكل مع شبكات SAN، ولا تزال صيانتها الثقيلة، وما إلى ذلك. لم يكن الأمر عاملاً حاسماً، لكنني أردت أن أحاول العيش بدونه بطريقة أو بأخرى.
وقمنا بعمل النسخة الثالثة (في الحقيقة الثانية في الحقيقة) - نسخة الحجز. كيف كانت؟
وهذا ما كان عليه -
مشاكلنا الرئيسية تكمن في حقيقة أن هذا مضيف فعلي.
أولاً، نقوم بإزالة شبكات SAN لأننا نريد التجربة، ونريد تجربة محركات الأقراص الثابتة المحلية فقط.
هذا هو بالفعل 2014-2015، وفي ذلك الوقت أصبح الوضع مع الأقراص وقدرتها في مضيف واحد أفضل بكثير. قررنا لماذا لا نحاول ذلك.
وبعد ذلك نأخذ ببساطة قسم النسخ الاحتياطي الخاص بنا وننقله فعليًا إلى جهاز منفصل.
وهكذا نحصل على هذا المخطط. لدينا سيارتان تقومان بتخزين نفس مجموعات البيانات. يقومون بعمل نسخة احتياطية لبعضهم البعض بشكل كامل ويقومون بمزامنة البيانات عبر الشبكة من خلال قائمة انتظار غير متزامنة في نفس MySQL.
السبب وراء نجاح هذا الأمر هو أن لدينا القليل من السجلات. أولئك. إذا كانت الكتابة قابلة للمقارنة بالقراءة، فربما كان لدينا نوع من الحمل والمشاكل في الشبكة. هناك القليل من الكتابة، والكثير من القراءة - هذه الطريقة تعمل بشكل جيد، أي. نادرًا ما نقوم بنسخ الصور بين هذين الخادمين.
كيف يعمل هذا، إذا نظرت بمزيد من التفصيل.
رفع. يقوم الموازن ببساطة باختيار مضيفين عشوائيين مع زوج ويقوم بالتحميل إليه. وفي الوقت نفسه، يقوم بطبيعة الحال بإجراء فحوصات صحية والتأكد من عدم سقوط السيارة. أولئك. يقوم بتحميل الصور فقط على خادم مباشر، ثم من خلال قائمة انتظار غير متزامنة يتم نسخها كلها إلى جاره. مع التحميل، كل شيء بسيط للغاية.
المهمة أصعب قليلاً.
لقد ساعدتنا Lua هنا، لأنه قد يكون من الصعب إنشاء مثل هذا المنطق على Vanilla NGINX. نقوم أولاً بتقديم طلب إلى الخادم الأول، لمعرفة ما إذا كانت الصورة موجودة، لأنه من المحتمل أن يتم تحميلها، على سبيل المثال، إلى أحد الجيران، ولكنها لم تصل إلى هنا بعد. إذا كانت الصورة هناك، فهذا جيد. نعطيها على الفور للعميل وربما نقوم بتخزينها مؤقتًا.
إذا لم يكن هناك، فإننا ببساطة نقدم طلبًا إلى جارنا ونضمن استلامه من هناك.
الذي - التي. مرة أخرى يمكننا أن نقول: قد تكون هناك مشاكل في الأداء، لأن هناك رحلات ذهابًا وإيابًا مستمرة - تم تحميل الصورة، وهي ليست هنا، ونحن نقدم طلبين بدلاً من طلب واحد، ويجب أن يعمل هذا ببطء.
في حالتنا، هذا لا يعمل ببطء.
نقوم بجمع مجموعة من المقاييس على هذا النظام، ويبلغ المعدل الذكي المشروط لهذه الآلية حوالي 95٪. أولئك. إن تأخر هذه النسخة الاحتياطية صغير، ونتيجة لهذا فإننا نضمن تقريبًا أنه بعد تحميل الصورة، سنلتقطها في المرة الأولى ولن نضطر إلى الذهاب إلى أي مكان مرتين.
إذن ما الذي حصلنا عليه وهو رائع حقًا؟
في السابق، كان لدينا قسم النسخ الاحتياطي الرئيسي، ونقرأ منه بالتتابع. أولئك. لقد بحثنا دائمًا عن العنصر الرئيسي أولاً، ثم عن النسخة الاحتياطية. لقد كانت خطوة واحدة.
الآن نستخدم القراءة من جهازين في وقت واحد. نقوم بتوزيع الطلبات باستخدام Round Robin. في نسبة صغيرة من الحالات نقوم بتقديم طلبين. لكن بشكل عام، لدينا الآن ضعف مخزون القراءة الذي كان لدينا من قبل. وتم تقليل الحمل بشكل كبير سواء على أجهزة الإرسال أو مباشرة على آلات التخزين، والتي كانت لدينا أيضًا في ذلك الوقت.
أما بالنسبة للتسامح مع الخطأ. في الواقع، هذا هو ما ناضلنا من أجله بشكل أساسي. مع التسامح مع الخطأ، أصبح كل شيء رائعًا هنا.
تعطلت سيارة واحدة.
لا مشكلة! قد لا يستيقظ مهندس النظام في الليل، سينتظر حتى الصباح، ولن يحدث شيء سيء.
إذا فشل هذا الجهاز، فإن قائمة الانتظار معطلة، ولا توجد مشاكل أيضًا، فسيتم تجميع السجل ببساطة أولاً على الجهاز الحي، ثم ستتم إضافته إلى قائمة الانتظار، ثم إلى السيارة التي سوف تدخل حيز التنفيذ بعد مرور بعض الوقت.
نفس الشيء مع الصيانة. نحن ببساطة نقوم بإيقاف تشغيل أحد الأجهزة، ونخرجه يدويًا من جميع المجمعات، ويتوقف عن استقبال حركة المرور، ونجري نوعًا من الصيانة، ونعدل شيئًا ما، ثم نعيده إلى الخدمة، ويتم تنفيذ هذه النسخة الاحتياطية بسرعة كبيرة. أولئك. يوميًا، ينتهي وقت توقف سيارة واحدة في غضون دقيقتين. وهذا في الحقيقة قليل جدًا. مع التسامح مع الخطأ، أقول مرة أخرى، كل شيء رائع هنا.
ما هي الاستنتاجات التي يمكن استخلاصها من مخطط التكرار هذا؟
لقد حصلنا على التسامح مع الخطأ.
سهل الاستخدام. نظرًا لأن الأجهزة تحتوي على محركات أقراص ثابتة محلية، فهذا أكثر ملاءمة من الناحية التشغيلية للمهندسين الذين يعملون معها.
لقد حصلنا على بدل قراءة مزدوج.
هذه مكافأة جيدة جدًا بالإضافة إلى التسامح مع الخطأ.
ولكن هناك أيضا مشاكل. الآن لدينا تطوير أكثر تعقيدًا لبعض الميزات المتعلقة بهذا، لأن النظام أصبح متسقًا بنسبة 100٪ في النهاية.
يجب علينا، على سبيل المثال، في بعض المهام الخلفية، أن نفكر باستمرار: "ما هو الخادم الذي نعمل عليه الآن؟"، "هل توجد بالفعل صورة حالية هنا؟" إلخ. كل هذا بالطبع انتهى، وبالنسبة للمبرمج الذي يكتب منطق الأعمال، فهو شفاف. ولكن، مع ذلك، ظهرت هذه الطبقة المعقدة الكبيرة. لكننا على استعداد لتحمل هذا مقابل الأشياء الجيدة التي تلقيناها منه.
وهنا ينشأ بعض الصراع مرة أخرى.
لقد قلت في البداية أن تخزين كل شيء على محركات الأقراص الثابتة المحلية أمر سيء. والآن أقول أننا أحببنا ذلك.
نعم، في الواقع، مع مرور الوقت تغير الوضع كثيرا، والآن هذا النهج له العديد من المزايا. أولاً، نحصل على عملية أبسط بكثير.
ثانيًا، إنها أكثر إنتاجية، لأننا لا نملك وحدات التحكم التلقائية هذه أو التوصيلات بأرفف الأقراص.
هناك كمية هائلة من الآلات هناك، وهي مجرد عدد قليل من الأقراص التي يتم تجميعها هنا على الجهاز في الغارة.
لكن هناك سلبيات.
وهذا أغلى بحوالي 1,5 مرة من استخدام شبكات SAN حتى بأسعار اليوم. لذلك، قررنا عدم تحويل مجموعتنا الكبيرة بأكملها بجرأة إلى سيارات ذات محركات أقراص ثابتة محلية وقررت ترك الحل المختلط.
تعمل نصف أجهزتنا مع محركات الأقراص الثابتة (حسنًا، ليس النصف - ربما 30 بالمائة). والباقي سيارات قديمة كان لها نظام الحجز الأول. لقد قمنا ببساطة بإعادة تركيبها، نظرًا لأننا لم نكن بحاجة إلى بيانات جديدة أو أي شيء آخر، فقد قمنا ببساطة بنقل الحوامل من مضيف فعلي واحد إلى مضيفين.
ولدينا الآن مخزون كبير من القراءة، وقمنا بتوسيعه. إذا قمنا سابقًا بتركيب وحدة تخزين واحدة على جهاز واحد، فإننا نقوم الآن بتركيب أربعة وحدات تخزين، على سبيل المثال، على زوج واحد. ويعمل بشكل جيد.
دعونا نلقي نظرة مختصرة على ما أنجزناه، وما ناضلنا من أجله، وما إذا كنا قد نجحنا.
نتائج
لدينا مستخدمون - ما يصل إلى 33 مليونًا.
لدينا ثلاث نقاط تواجد - براغ وميامي وهونج كونج.
وهي تحتوي على طبقة تخزين مؤقت، تتكون من سيارات ذات أقراص محلية سريعة (SSD)، حيث يتم تشغيل الآلات البسيطة من NGINX وaccess.log وPython daemons، والتي تعالج كل هذا وتدير ذاكرة التخزين المؤقت.
إذا كنت ترغب في ذلك، فأنت في مشروعك، وإذا كانت الصور ليست مهمة بالنسبة لك كما هي بالنسبة لنا، أو إذا كانت السيطرة على المفاضلة مقابل سرعة التطوير وتكاليف الموارد في الاتجاه الآخر بالنسبة لك، فيمكنك استبدالها بأمان مع CDN، هل تعمل شبكات CDN الحديثة بشكل جيد.
بعد ذلك تأتي طبقة التخزين، حيث لدينا مجموعات من أزواج الأجهزة التي تدعم بعضها البعض، ويتم نسخ الملفات بشكل غير متزامن من واحد إلى آخر كلما تغيرت.
علاوة على ذلك، تعمل بعض هذه الأجهزة مع محركات الأقراص الثابتة المحلية.
بعض هذه الأجهزة متصلة بشبكات SAN.
ومن ناحية، فهو أكثر ملاءمة للاستخدام وأكثر إنتاجية قليلا، من ناحية أخرى، فهو مناسب من حيث كثافة المواضع والسعر لكل جيجابايت.
هذه نظرة عامة مختصرة على بنية ما حصلنا عليه وكيف تطور كل شيء.
بعض النصائح الإضافية من القبطان، بسيطة جدًا.
أولاً، إذا قررت فجأة أنك بحاجة ماسة إلى تحسين كل شيء في البنية التحتية للصور الخاصة بك، فقم بالقياس أولاً، لأنه ربما لا يلزم تحسين أي شيء.
اسمحوا لي أن أقدم لكم مثالا. لدينا مجموعة من الأجهزة التي ترسل الصور من المرفقات في المحادثات، والمخطط يعمل هناك منذ عام 2009، ولا أحد يعاني منه. الجميع بخير، الجميع يحب كل شيء.
من أجل القياس، قم أولاً بتعليق مجموعة من المقاييس، وانظر إليها، ثم حدد ما الذي لا تشعر بالرضا عنه وما الذي يحتاج إلى تحسين. من أجل قياس ذلك، لدينا أداة رائعة تسمى Pinba.
فهو يسمح لك بجمع إحصائيات مفصلة للغاية من NGINX لكل طلب ورموز الاستجابة وتوزيع الأوقات - كل ما تريد. لديها ارتباطات بجميع أنواع أنظمة التحليلات المختلفة، ومن ثم يمكنك النظر إليها بشكل جميل.
قمنا بقياسه أولاً، ثم قمنا بتحسينه.
إضافي. نحن نحسن القراءة باستخدام ذاكرة التخزين المؤقت، والكتابة باستخدام التجزئة، ولكن هذه نقطة واضحة.
إضافي. إذا كنت قد بدأت للتو في بناء نظامك، فمن الأفضل أن تجعل الصور كملفات غير قابلة للتغيير. لأنك ستفقد على الفور فئة كاملة من المشكلات المتعلقة بإبطال ذاكرة التخزين المؤقت وكيفية العثور على الإصدار الصحيح من الصورة وما إلى ذلك.
لنفترض أنك قمت بتحميل مائة ملف، ثم قمت بتدويرها وجعلها ملفًا مختلفًا فعليًا. أولئك. لا داعي للتفكير: الآن سأوفر مساحة صغيرة، وأكتبه في نفس الملف، وأغير الإصدار. هذا لا يعمل دائمًا بشكل جيد ويسبب الكثير من الصداع لاحقًا.
النقطة التالية. حول تغيير الحجم على الطاير.
في السابق، عندما قام المستخدمون بتحميل صورة، كنا نقوم على الفور بقص مجموعة كاملة من الأحجام لجميع المناسبات، ولعملاء مختلفين، وكانت جميعها موجودة على القرص. الآن لقد تخلينا عن هذا.
لقد تركنا ثلاثة أحجام رئيسية فقط: صغيرة ومتوسطة وكبيرة. نحن ببساطة نقوم بتقليص حجم كل شيء آخر من الحجم الموجود خلف الحجم الذي طلب منا في Uport، ونقوم ببساطة بتصغير الحجم وإعطائه للمستخدم.
تبين أن وحدة المعالجة المركزية لطبقة التخزين المؤقت هنا أرخص بكثير مما لو قمنا باستمرار بإعادة إنشاء هذه الأحجام في كل وحدة تخزين. لنفترض أننا نريد إضافة واحدة جديدة، سيستغرق هذا شهرًا - قم بتشغيل برنامج نصي في كل مكان من شأنه أن يفعل كل هذا بدقة، دون تدمير المجموعة. أولئك. إذا كانت لديك الفرصة للاختيار الآن، فمن الأفضل أن تفعل أقل عدد ممكن من الأحجام المادية، ولكن بحيث يكون بعض التوزيع على الأقل، على سبيل المثال، ثلاثة. ويمكن تغيير حجم كل شيء آخر بسرعة باستخدام وحدات جاهزة. كل شيء سهل للغاية ويمكن الوصول إليه الآن.
والنسخ الاحتياطي المتزايد غير المتزامن أمر جيد.
كما أظهرت ممارستنا، يعمل هذا المخطط بشكل رائع مع النسخ المتأخر للملفات التي تم تغييرها.
النقطة الأخيرة واضحة أيضًا. إذا لم يكن لدى البنية التحتية الخاصة بك مثل هذه المشكلات الآن، ولكن هناك شيء يمكن أن ينكسر، فسوف ينكسر بالتأكيد عندما يصبح أكثر من ذلك بقليل. لذلك من الأفضل التفكير في هذا الأمر مسبقًا وعدم مواجهة مشاكل معه. هذا كل ما أردت أن أقوله.
الاتصالات
»
»
هذا التقرير عبارة عن نسخة من إحدى أفضل الخطب التي ألقاها في مؤتمر مطوري الأنظمة عالية التحميل . لم يتبق سوى أقل من شهر حتى انعقاد مؤتمر HighLoad++ 2017.
لدينا بالفعل جاهزة ، يتم الآن تشكيل الجدول الزمني بنشاط.
نواصل هذا العام استكشاف موضوع البنى والقياس:
- / إيجور فاسيليف
- / دميتري إيجوروف
- / أناتولي بلاسكوفسكي
- / رومان شيخوفتسوف، أليكسي جروماتشيكوف
- / فيليب ديلجادو
نستخدم أيضًا بعض هذه المواد في دورتنا التدريبية عبر الإنترنت حول تطوير الأنظمة عالية التحميل عبارة عن سلسلة من الرسائل والمقالات والمواد ومقاطع الفيديو المختارة خصيصًا. يحتوي كتابنا المدرسي بالفعل على أكثر من 30 مادة فريدة. يتصل!
المصدر: www.habr.com