عندما يتعلق الأمر بالمنتج الذي تم تطويره لأكثر من عقد من الزمان، فليس من المستغرب على الإطلاق العثور على تقنيات قديمة فيه. ولكن ماذا لو اضطررت خلال ستة أشهر إلى الحفاظ على الحمل أعلى بعشر مرات، وستزيد تكلفة السقوط مئات المرات؟ في هذه الحالة، أنت بحاجة إلى مهندس Highload رائع. لكن في ظل عدم وجود خادمة كلفوني بحل المشكلة. سأخبرك في الجزء الأول من المقالة كيف انتقلنا من مجموعة Redis إلى مجموعة Redis، وفي الجزء الثاني سأقدم نصائح حول كيفية البدء في استخدام المجموعة وما يجب الانتباه إليه عند استخدامه.

اختيار التكنولوجيا

غير أن سيئة؟ ريديس منفصلة (redis مستقل) في تكوين 1 سيد وعبيد N؟ لماذا أسميها تكنولوجيا عفا عليها الزمن؟

لا، Redis ليس بهذا السوء... ومع ذلك، هناك بعض العيوب التي لا يمكن تجاهلها.

• أولاً، لا يدعم Redis آليات التعافي من الكوارث بعد حدوث فشل رئيسي. لحل هذه المشكلة، استخدمنا تكوينًا مع النقل التلقائي لكبار الشخصيات إلى سيد جديد، وتغيير دور أحد العبيد وتبديل الباقي. لقد نجحت هذه الآلية، لكن لا يمكن وصفها بأنها حل موثوق. أولاً، حدثت إنذارات كاذبة، وثانيًا، كان يمكن التخلص منه، وبعد التشغيل كانت هناك حاجة إلى إجراءات يدوية لشحن الزنبرك.

• ثانيًا، أدى وجود سيد واحد فقط إلى مشكلة التجزئة. كان علينا إنشاء عدة مجموعات مستقلة "1 master وN العبيد"، ثم توزيع قواعد البيانات يدويًا بين هذه الأجهزة ونأمل ألا تتضخم إحدى قواعد البيانات غدًا كثيرًا بحيث يتعين نقلها إلى مثيل منفصل.

ما هي الخيارات؟

• الحل الأغلى والأغنى هو Redis-Enterprise. هذا حل محاصر مع الدعم الفني الكامل. على الرغم من أنها تبدو مثالية من الناحية الفنية، إلا أنها لم تناسبنا لأسباب أيديولوجية.
• مجموعة Redis. يوجد دعم لتجاوز الفشل الرئيسي والتقسيم. الواجهة لا تختلف تقريبًا عن الإصدار العادي. يبدو الأمر واعدًا، وسنتحدث عن المزالق لاحقًا.
• Tarantool، Memcache، Aerospike وغيرها. كل هذه الأدوات تفعل الشيء نفسه تقريبًا. لكن لكل منها عيوبه الخاصة. قررنا ألا نضع كل بيضنا في سلة واحدة. نستخدم Memcache و Tarantool لمهام أخرى، وبالنظر إلى المستقبل، سأقول أنه في ممارستنا كان هناك المزيد من المشاكل معهم.

مواصفات الاستخدام

دعونا نلقي نظرة على المشاكل التي قمنا بحلها تاريخيًا باستخدام Redis والوظائف التي استخدمناها:

• ذاكرة التخزين المؤقت قبل طلبات الخدمات البعيدة مثل 2GIS | جولانج
  

  احصل على مجموعة MGET MSET "SELECT DB"

• ذاكرة التخزين المؤقت قبل MYSQL | بي أتش بي
  

  احصل على مجموعة MGET MSET SCAN "KEY BY PATTERN" "SELECT DB"

• المخزن الرئيسي لخدمة العمل مع الجلسات وإحداثيات السائق | جولانج
  

  احصل على مجموعة MGET MSET "SELECT DB" "ADD GEO KEY" "GET GEO KEY" SCAN

كما ترون، لا الرياضيات العليا. ما هي الصعوبة إذن؟ دعونا نلقي نظرة على كل طريقة على حدة.

طريقة
وصف
ميزات مجموعة Redis
حل

اجلس
مفتاح الكتابة/القراءة

مجيت مسيت
كتابة/قراءة مفاتيح متعددة
ستكون المفاتيح على عقد مختلفة. يمكن للمكتبات الجاهزة إجراء عمليات متعددة داخل عقدة واحدة فقط
استبدل MGET بخط أنابيب لعمليات N GET

حدد قاعدة البيانات
حدد القاعدة التي سنعمل بها
لا يدعم قواعد بيانات متعددة
ضع كل شيء في قاعدة بيانات واحدة. إضافة البادئات إلى المفاتيح

SCAN
انتقل من خلال كافة المفاتيح في قاعدة البيانات
وبما أن لدينا قاعدة بيانات واحدة، فإن المرور عبر جميع المفاتيح الموجودة في المجموعة أمر مكلف للغاية
احتفظ بثابت داخل مفتاح واحد وقم بإجراء HSCAN على هذا المفتاح. أو رفض تماما

جيو
العمليات باستخدام Geokey
لم يتم تقسيم Geokey

المفتاح حسب النمط
البحث عن المفتاح حسب النمط
وبما أن لدينا قاعدة بيانات واحدة، فسوف نقوم بالبحث في جميع المفاتيح الموجودة في المجموعة. غالي جدا
رفض أو الحفاظ على الثابت، كما في حالة SCAN

Redis مقابل مجموعة Redis

ماذا نخسر وماذا نكسب عند التحول إلى المجموعة؟

• العيوب: نفقد وظائف العديد من قواعد البيانات.
  • إذا أردنا تخزين بيانات غير مرتبطة منطقيًا في مجموعة واحدة، فسيتعين علينا صنع عكازات على شكل بادئات.
  • نفقد جميع العمليات "الأساسية"، مثل SCAN وDBSIZE وCLEAR DB وما إلى ذلك.
  • أصبح تنفيذ العمليات المتعددة أكثر صعوبة لأنها قد تتطلب الوصول إلى عدة عقد.
• المزايا:
  • التسامح مع الخطأ في شكل تجاوز الفشل الرئيسي.
  • المشاركة على جانب Redis.
  • نقل البيانات بين العقد ذريًا وبدون توقف.
  • إضافة وإعادة توزيع السعة والأحمال دون توقف.

أود أن أستنتج أنه إذا لم تكن بحاجة إلى توفير مستوى عالٍ من التسامح مع الخطأ، فإن الانتقال إلى المجموعة لا يستحق كل هذا العناء، لأنه يمكن أن يكون مهمة غير تافهة. ولكن إذا اخترت في البداية بين إصدار منفصل وإصدار عنقودي، فيجب عليك اختيار مجموعة، لأنها ليست أسوأ، بالإضافة إلى أنها ستريحك من بعض الصداع

الاستعداد للتحرك

لنبدأ بمتطلبات الحركة:

• يجب أن تكون سلسة. التوقف الكامل للخدمة لمدة 5 دقائق لا يناسبنا.
• وينبغي أن تكون آمنة وتدريجية قدر الإمكان. أريد أن يكون لدي بعض السيطرة على الوضع. لا نريد التخلص من كل شيء مرة واحدة والصلاة من أجل زر التراجع.
• الحد الأدنى من فقدان البيانات عند التحرك. نحن ندرك أنه سيكون من الصعب جدًا التحرك ذريًا، لذلك نسمح ببعض عدم التزامن بين البيانات في Redis العادي والمجمع.

صيانة الكتلة

قبل هذه الخطوة مباشرة، يجب أن نفكر فيما إذا كان بإمكاننا دعم المجموعة:

• الرسوم البيانية. نستخدم Prometheus وGrafana لرسم رسم بياني لتحميل وحدة المعالجة المركزية واستخدام الذاكرة وعدد العملاء وعدد عمليات GET وSET وAUTH وما إلى ذلك.
• خبرة. تخيل أنه سيكون لديك غدًا مجموعة ضخمة تحت مسؤوليتك. إذا انكسر، فلا أحد يستطيع إصلاحه إلا أنت. إذا بدأ في التباطؤ، فسوف يركض الجميع نحوك. إذا كنت بحاجة إلى إضافة موارد أو إعادة توزيع الحمل، فارجع إليك. لكي لا يتحول اللون الرمادي إلى اللون الرمادي عند عمر 25 عامًا، يُنصح بتوفير هذه الحالات والتحقق مسبقًا من كيفية تصرف التكنولوجيا في ظل إجراءات معينة. دعونا نتحدث عن هذا بمزيد من التفصيل في قسم "الخبرة".
• المراقبة والتنبيهات. عندما تنهار مجموعة ما، فأنت تريد أن تكون أول من يعرف عنها. لقد اقتصرنا هنا على إشعار بأن جميع العقد تُرجع نفس المعلومات حول حالة المجموعة (نعم، يحدث ذلك بشكل مختلف). ويمكن ملاحظة المشكلات الأخرى بسرعة أكبر من خلال التنبيهات الصادرة عن خدمات عملاء Redis.

تحرك

كيف سنتحرك:

• بادئ ذي بدء، تحتاج إلى إعداد مكتبة للعمل مع المجموعة. لقد اتخذنا go-redis كأساس لإصدار Go وقمنا بتغييره قليلاً ليناسب أنفسنا. قمنا بتنفيذ طرق متعددة من خلال خطوط الأنابيب، وقمنا أيضًا بتصحيح قواعد الطلبات المتكررة بشكل طفيف. واجه إصدار PHP المزيد من المشكلات، لكننا استقرنا في النهاية على php-redis. لقد قدموا مؤخرًا دعم المجموعة ويبدو جيدًا في رأينا.
• بعد ذلك، تحتاج إلى نشر المجموعة نفسها. يتم ذلك حرفيًا في أمرين بناءً على ملف التكوين. سنناقش الإعداد بمزيد من التفاصيل أدناه.
• للتحرك التدريجي نستخدم الوضع الجاف. نظرًا لأن لدينا نسختين من المكتبة بنفس الواجهة (واحدة للإصدار العادي والأخرى للمجموعة)، فلا يكلف الأمر شيئًا لإنشاء غلاف يعمل مع إصدار منفصل وبالتوازي يكرر جميع الطلبات المقدمة إلى المجموعة، قارن الإجابات واكتب التناقضات في السجلات (في حالتنا في NewRelic). وبالتالي، حتى لو تعطل إصدار المجموعة أثناء الطرح، فلن يتأثر إنتاجنا.
• بعد طرح المجموعة في الوضع الجاف، يمكننا أن ننظر بهدوء إلى الرسم البياني لتناقضات الاستجابة. إذا تحرك معدل الخطأ ببطء ولكن بثبات نحو ثابت صغير، فكل شيء على ما يرام. لماذا لا تزال هناك اختلافات؟ نظرًا لأن التسجيل في إصدار منفصل يحدث في وقت أبكر قليلاً مما هو عليه في المجموعة، وبسبب التأخر الميكروي، فقد تتباين البيانات. كل ما تبقى هو إلقاء نظرة على سجلات التناقض، وإذا تم تفسيرها جميعًا من خلال عدم ذرية السجل، فيمكننا المضي قدمًا.
• يمكنك الآن تبديل الوضع الجاف في الاتجاه المعاكس. سنكتب ونقرأ من المجموعة وننسخها في نسخة منفصلة. لماذا؟ خلال الأسبوع القادم أود أن أراقب عمل المجموعة. إذا اتضح فجأة أن هناك مشكلات في ذروة الحمل، أو أننا لم نأخذ شيئًا ما في الاعتبار، فلدينا دائمًا عودة طارئة إلى الكود القديم والبيانات الحالية بفضل الوضع الجاف.
• كل ما تبقى هو تعطيل الوضع الجاف وتفكيك الإصدار المنفصل.

الخبرة

أولاً، باختصار حول تصميم المجموعة.

بادئ ذي بدء، يعد Redis متجرًا ذا قيمة أساسية. يتم استخدام السلاسل التعسفية كمفاتيح. يمكن استخدام الأرقام والسلاسل والهياكل بأكملها كقيم. هناك عدد كبير جدًا من هذه الأخيرة، ولكن لفهم الهيكل العام، هذا ليس مهمًا بالنسبة لنا.
المستوى التالي من التجريد بعد المفاتيح هو الفتحات (SLOTS). ينتمي كل مفتاح إلى واحدة من 16 فتحة. يمكن أن يكون هناك أي عدد من المفاتيح داخل كل فتحة. وهكذا، تم تقسيم جميع المفاتيح إلى 383 مجموعة مفككة.

بعد ذلك، يجب أن يكون هناك N عقد رئيسية في المجموعة. يمكن اعتبار كل عقدة بمثابة مثيل Redis منفصل يعرف كل شيء عن العقد الأخرى داخل المجموعة. تحتوي كل عقدة رئيسية على عدد من الفتحات. تنتمي كل فتحة إلى عقدة رئيسية واحدة فقط. يجب توزيع كافة الفتحات بين العقد. إذا لم يتم تخصيص بعض الفتحات، فلن يكون من الممكن الوصول إلى المفاتيح المخزنة فيها. من المنطقي تشغيل كل عقدة رئيسية على جهاز منطقي أو فعلي منفصل. ومن الجدير بالذكر أيضًا أن كل عقدة تعمل على نواة واحدة فقط، وإذا كنت تريد تشغيل مثيلات Redis متعددة على نفس الجهاز المنطقي، فتأكد من تشغيلها على نواة مختلفة (لم نجرب هذا، ولكن من الناحية النظرية يجب أن يعمل) . بشكل أساسي، توفر العقد الرئيسية مشاركة منتظمة، والمزيد من العقد الرئيسية تسمح بتوسيع نطاق طلبات الكتابة والقراءة.

بعد توزيع جميع المفاتيح بين الفتحات، وتوزع الفتحات بين العقد الرئيسية، يمكن إضافة عدد عشوائي من العقد التابعة إلى كل عقدة رئيسية. داخل كل رابط من هذه الروابط الرئيسية والتابعة، سيعمل النسخ المتماثل العادي. هناك حاجة إلى العبيد لتوسيع نطاق طلبات القراءة ولتجاوز الفشل في حالة الفشل الرئيسي.

الآن دعونا نتحدث عن العمليات التي سيكون من الأفضل أن نكون قادرين على القيام بها.

سنصل إلى النظام عبر Redis-CLI. نظرًا لأن Redis ليس لديه نقطة دخول واحدة، فيمكنك إجراء العمليات التالية على أي من العقد. في كل نقطة، ألفت الانتباه بشكل منفصل إلى إمكانية إجراء العملية تحت الحمل.

• أول وأهم شيء نحتاجه هو تشغيل العقد العنقودية. تقوم بإرجاع حالة المجموعة، وتظهر قائمة العقد، وأدوارها، وتوزيع الفتحات، وما إلى ذلك. يمكن الحصول على مزيد من المعلومات باستخدام معلومات المجموعة وفتحات المجموعة.
• سيكون من الجميل أن تكون قادرًا على إضافة وإزالة العقد. لهذا الغرض هناك عمليات لقاء الكتلة ونسيان الكتلة. يرجى ملاحظة أنه يجب تطبيق نسيان المجموعة على كل عقدة، سواء كانت العقدة الرئيسية أو النسخ المتماثلة. ويجب استدعاء اجتماع الكتلة فقط على عقدة واحدة. يمكن أن يكون هذا الاختلاف مربكًا، لذا من الأفضل التعرف عليه قبل البدء في استخدام مجموعتك. تتم إضافة العقدة بأمان في المعركة ولا تؤثر على تشغيل المجموعة بأي شكل من الأشكال (وهذا أمر منطقي). إذا كنت ستقوم بإزالة عقدة من المجموعة، فيجب عليك التأكد من عدم وجود فتحات متبقية عليها (وإلا فإنك تخاطر بفقدان الوصول إلى جميع المفاتيح الموجودة على هذه العقدة). أيضًا، لا تحذف سيدًا لديه عبيد، وإلا فسيتم إجراء تصويت غير ضروري لسيد جديد. إذا لم تعد العقد تحتوي على فتحات، فهذه مشكلة صغيرة، ولكن لماذا نحتاج إلى خيارات إضافية إذا كان بإمكاننا حذف العبيد أولاً.
• إذا كنت بحاجة إلى تبديل وضعي السيد والعبد بالقوة، فسيقوم أمر تجاوز فشل المجموعة بذلك. عند الاتصال به في المعركة، عليك أن تفهم أن السيد لن يكون متاحا أثناء العملية. عادةً ما يحدث التبديل في أقل من ثانية، ولكنه ليس ذريًا. يمكنك أن تتوقع فشل بعض الطلبات المقدمة إلى السيد خلال هذا الوقت.
• قبل إزالة العقدة من المجموعة، يجب ألا يكون هناك أي فتحات متبقية عليها. من الأفضل إعادة توزيعها باستخدام أمر إعادة تقسيم الكتلة. سيتم نقل الفتحات من سيد إلى آخر. قد تستغرق العملية بأكملها عدة دقائق، ويعتمد ذلك على حجم البيانات التي يتم نقلها، ولكن عملية النقل آمنة ولا تؤثر على تشغيل المجموعة بأي شكل من الأشكال. وبالتالي، يمكن نقل جميع البيانات من عقدة إلى أخرى مباشرة تحت التحميل، ودون القلق بشأن توفرها. ومع ذلك، هناك أيضا الدقيقة. أولاً، يرتبط نقل البيانات بحمل معين على عقد المستلم والمرسل. إذا كانت عقدة المستلم محملة بالفعل بشكل كبير على المعالج، فلا يجب عليك تحميلها بتلقي بيانات جديدة. ثانيًا، بمجرد عدم وجود فتحة واحدة على السيد المرسل، سيذهب جميع العبيد على الفور إلى السيد الذي تم نقل هذه الفتحات إليه. والمشكلة هي أن كل هؤلاء العبيد سيرغبون في مزامنة البيانات مرة واحدة. وستكون محظوظًا إذا كانت المزامنة جزئية وليست كاملة. ضع ذلك في الاعتبار واجمع بين عمليات نقل الفتحات وتعطيل/نقل العبيد. أو نأمل أن يكون لديك هامش كافٍ من الأمان.
• ماذا يجب أن تفعل إذا اكتشفت أثناء عملية النقل أنك فقدت فتحاتك في مكان ما؟ أتمنى ألا تؤثر هذه المشكلة عليك، ولكن إذا حدث ذلك، فهناك عملية إصلاح نظام المجموعة. على أقل تقدير، ستقوم بتوزيع الفتحات عبر العقد بترتيب عشوائي. أوصي بالتحقق من عملها عن طريق إزالة العقدة ذات الفتحات الموزعة من المجموعة أولاً. نظرًا لأن البيانات الموجودة في الفتحات غير المخصصة غير متوفرة بالفعل، فقد فات الأوان للقلق بشأن المشكلات المتعلقة بتوفر هذه الفتحات. وفي المقابل، لن تؤثر العملية على الفتحات الموزعة.
• عملية أخرى مفيدة هي المراقبة. يسمح لك برؤية القائمة الكاملة للطلبات التي تذهب إلى العقدة في الوقت الفعلي. علاوة على ذلك، يمكنك التعرف عليه ومعرفة ما إذا كانت هناك حركة المرور اللازمة.

ومن الجدير بالذكر أيضًا إجراء تجاوز الفشل الرئيسي. باختصار، إنه موجود، وفي رأيي، يعمل بشكل رائع. ومع ذلك، لا تعتقد أنه إذا قمت بفصل سلك الطاقة من جهاز به عقدة رئيسية، فسوف يقوم Redis بالتبديل على الفور ولن يلاحظ العملاء الخسارة. في ممارستي، يحدث التبديل في بضع ثوان. خلال هذا الوقت، لن تكون بعض البيانات متاحة: تم اكتشاف عدم توفر السيد، وتصويت العقد لعقدة جديدة، ويتم تبديل العبيد، وتتم مزامنة البيانات. أفضل طريقة للتأكد بنفسك من نجاح المخطط هي إجراء تمارين محلية. ارفع المجموعة الموجودة على الكمبيوتر المحمول الخاص بك، وأعطها الحد الأدنى من التحميل، وقم بمحاكاة العطل (على سبيل المثال، عن طريق حظر المنافذ)، وقم بتقييم سرعة التبديل. في رأيي، فقط بعد اللعب بهذه الطريقة لمدة يوم أو يومين، يمكنك أن تكون واثقًا من تشغيل التكنولوجيا. حسنًا، أو آمل أن يعمل البرنامج الذي يستخدمه نصف مستخدمي الإنترنت.

ترتيب

في كثير من الأحيان، يكون التكوين هو أول ما تحتاجه لبدء العمل مع الأداة. وعندما يعمل كل شيء، فإنك لا تريد حتى لمس التكوين. يتطلب الأمر بعض الجهد لإجبار نفسك على العودة إلى الإعدادات وتصفحها بعناية. في ذاكرتي، كان لدينا فشلان خطيران على الأقل بسبب عدم الانتباه إلى التكوين. انتبه بشكل خاص إلى النقاط التالية:

• timeout 0
  الوقت الذي يتم بعده إغلاق الاتصالات غير النشطة (بالثواني). 0- لا تغلق
  لم تكن كل مكتباتنا قادرة على إغلاق الاتصالات بشكل صحيح. من خلال تعطيل هذا الإعداد، فإننا نخاطر ببلوغ الحد الأقصى لعدد العملاء. من ناحية أخرى، إذا كانت هناك مشكلة كهذه، فإن الإنهاء التلقائي للاتصالات المفقودة سوف يخفيها، وقد لا نلاحظ ذلك. بالإضافة إلى ذلك، يجب عدم تمكين هذا الإعداد عند استخدام الاتصالات المستمرة.
• حفظ xy وإلحاق نعم فقط
  حفظ لقطة RDB.
  سنناقش مشكلات RDB/AOF بالتفصيل أدناه.
• توقف عن الكتابة على خطأ bgsave no وبيانات الخدمة التابعة التي لا معنى لها نعم
  إذا تم تمكينه، إذا تعطلت لقطة RDB، فسيتوقف السيد عن قبول طلبات التغيير. إذا فُقد الاتصال بالسيد، فيمكن للعبد الاستمرار في الاستجابة للطلبات (نعم). أو سيتوقف عن الرد (لا)
  نحن لسنا سعداء بالوضع الذي يتحول فيه Redis إلى قرع.
• فترة العبد repl-ping 5
  بعد هذه الفترة الزمنية، سنبدأ بالقلق من تعطل البرنامج الرئيسي وحان الوقت لتنفيذ إجراء تجاوز الفشل.
  سيتعين عليك إيجاد توازن يدويًا بين الإيجابيات الخاطئة وإثارة تجاوز الفشل. في ممارستنا هذا هو 5 ثوان.
• حجم repl-backlog 1024 ميجابايت وepl-backlog-ttl 0
  يمكننا تخزين هذا القدر من البيانات بالضبط في مخزن مؤقت للنسخة المتماثلة الفاشلة. إذا نفاد المخزن المؤقت، فسيتعين عليك إجراء المزامنة بالكامل.
  تشير الممارسة إلى أنه من الأفضل تحديد قيمة أعلى. هناك الكثير من الأسباب التي قد تؤدي إلى تأخر النسخة المتماثلة. إذا تأخرت، فمن المرجح أن سيدك يكافح بالفعل من أجل التأقلم، وستكون المزامنة الكاملة هي القشة الأخيرة.
• الحد الأقصى للعملاء 10000
  الحد الأقصى لعدد العملاء لمرة واحدة.
  في تجربتنا، من الأفضل تحديد قيمة أعلى. يتعامل Redis مع 10 آلاف اتصالات بشكل جيد. فقط تأكد من وجود مآخذ كافية على النظام.
• سياسة الذاكرة القصوى volatile-ttl
  القاعدة التي يتم من خلالها حذف المفاتيح عند الوصول إلى الحد الأقصى للذاكرة المتوفرة.
  المهم هنا ليس القاعدة نفسها، بل فهم كيف سيحدث ذلك. يمكن الإشادة بـ Redis لقدرته على العمل بشكل طبيعي عند الوصول إلى الحد الأقصى للذاكرة.

مشاكل RDB و AOF

على الرغم من أن Redis يقوم بتخزين جميع المعلومات في ذاكرة الوصول العشوائي (RAM)، إلا أن هناك أيضًا آلية لحفظ البيانات على القرص. بتعبير أدق، ثلاث آليات:

• RDB-snapshot - لقطة كاملة لجميع البيانات. قم بالتعيين باستخدام تكوين SAVE XY ويقرأ "احفظ لقطة كاملة لجميع البيانات كل X ثانية إذا تغيرت مفاتيح Y على الأقل."
• ملف الإلحاق فقط - قائمة العمليات بترتيب تنفيذها. يضيف عمليات واردة جديدة إلى الملف كل X ثانية أو كل عملية Y.
• RDB وAOF هما مزيج من الاثنين السابقين.

جميع الأساليب لها مزاياها وعيوبها، ولن أدرجها جميعا، سألفت الانتباه فقط إلى النقاط التي، في رأيي، ليست واضحة.

أولاً، يتطلب حفظ لقطة RDB استدعاء FORK. إذا كان هناك الكثير من البيانات، فيمكن أن يؤدي ذلك إلى تعليق Redis بالكامل لمدة تتراوح بين بضعة مللي ثانية إلى ثانية. بالإضافة إلى ذلك، يحتاج النظام إلى تخصيص ذاكرة لمثل هذه اللقطة، مما يؤدي إلى الحاجة إلى الاحتفاظ بإمداد مزدوج من ذاكرة الوصول العشوائي على الجهاز المنطقي: إذا تم تخصيص 8 جيجابايت لـ Redis، فيجب أن يكون 16 جيجابايت متاحًا على الجهاز الظاهري مع هو - هي.

ثانيا، هناك مشاكل مع المزامنة الجزئية. في وضع AOF، عند إعادة توصيل العبد، بدلاً من المزامنة الجزئية، يمكن إجراء المزامنة الكاملة. لماذا يحدث هذا، لم أستطع أن أفهم. لكن الأمر يستحق أن نتذكر هذا.

هاتان النقطتان تجعلنا نفكر بالفعل فيما إذا كنا نحتاج حقًا إلى هذه البيانات الموجودة على القرص إذا كان كل شيء مكررًا بالفعل بواسطة العبيد. لا يمكن فقدان البيانات إلا في حالة فشل جميع العبيد، وهذه مشكلة على مستوى "حريق في العاصمة". كحل وسط، يمكنك اقتراح حفظ البيانات فقط على العبيد، ولكن في هذه الحالة تحتاج إلى التأكد من أن هؤلاء العبيد لن يصبحوا أبدًا سادة أثناء التعافي من الكوارث (لهذا يوجد إعداد أولوية تابع في التكوين الخاص بهم). بالنسبة لأنفسنا، في كل حالة محددة، نفكر فيما إذا كان من الضروري حفظ البيانات على القرص، وفي أغلب الأحيان تكون الإجابة "لا".

اختتام

وفي الختام أتمنى أن أكون قد تمكنت من إعطاء فكرة عامة عن كيفية عمل redis-cluster لمن لم يسمعوا به على الإطلاق، كما لفتت الانتباه إلى بعض النقاط غير الواضحة لمن كان يستخدمه لفترة طويلة.
شكرًا على وقتك، وكما هو الحال دائمًا، نرحب بالتعليقات حول هذا الموضوع.

المصدر: www.habr.com