التخزين المؤقت مع خادم متعددة

Question

أقوم بإنشاء تطبيق يتضمن عدة خوادم.(4 خوادم يحتوي كل منها على قاعدة بيانات وخادم ويب.قاعدة بيانات رئيسية واحدة و3 تابعين + موازن تحميل واحد)

هناك عدة طرق لتمكين التخزين المؤقت.في الوقت الحالي، أصبح الأمر بسيطًا إلى حد ما وغير فعال على الإطلاق.يتم إجراء جميع عمليات التخزين المؤقت على مشاركة قسم NFS بين جميع الخوادم.NFS هو عنق الزجاجة في الهندسة المعمارية.

1. لدي عدة أفكار تنفذ التخزين المؤقت.يمكن أن يتم ذلك على الخادم المستوى (نظام الملفات المحلي) ولكن المشكلة هي إبطال ذاكرة التخزين المؤقت ملف عندما يكون المحتوى التحديث على كل الخادم:يمكن أن يكون يتم ذلك عن طريق وجود ذاكرة تخزين مؤقت صغيرة مدى الحياة (غير فعال لأن سيتم تحديث ذاكرة التخزين المؤقت في وقت أقرب إلى ذلك يجب أن يكون معظم الوقت)
2. ويمكن أيضا أن يتم ذلك عن طريق الرسائل نظام (XMPP على سبيل المثال) حيث كل خادم التواصل مع بعضها البعض.الخادم المسؤول عن إبطال ذاكرة التخزين المؤقت إرسال ملف اطلب من جميع الآخرين السماح لهم اعلم أن ذاكرة التخزين المؤقت قد تم يبطل.الكمون هو على الأرجح أكبر (خذ المزيد من الوقت للجميع لمعرفة أن ذاكرة التخزين المؤقت قد تم إبطال ) ولكن طلبي لا يتطلب ذاكرة تخزين مؤقت ذرية ابطال.
3. النهج الثالث هو استخدام السحابة نظام لتخزين ذاكرة التخزين المؤقت (مثل CouchDB) ولكن ليس لدي أي فكرة عن أداء لهذا واحد.هل هذا أسرع من استخدام قاعدة بيانات SQL؟

لقد خططت لاستخدام Zend Framework ولكني لا أعتقد أنه مناسب حقًا (باستثناء أن بعض الحزم ربما تكون موجودة في إطار عمل آخر للتعامل مع XMPP وCouchDB)

متطلبات:ذاكرة التخزين المؤقت المستمرة (في حالة إعادة تشغيل الخادم، لا ينبغي فقدان ذاكرة التخزين المؤقت لتجنب إسقاط الخادم أثناء إعادة إنشاء ذاكرة التخزين المؤقت)

Answer 1

أعتقد أنني وجدت حلاً جيدًا نسبيًا.

أستخدم Zend_Cache لتخزين كل ملف ذاكرة تخزين مؤقت محليًا.لقد قمت بإنشاء برنامج خفي صغير يعتمد على خادم النانو الذي يدير ملفات ذاكرة التخزين المؤقت محليًا أيضًا.عندما يقوم خادم واحد بإنشاء/تعديل/حذف ملف ذاكرة تخزين مؤقت محليًا، فإنه يرسل نفس الإجراء إلى كل الخادم من خلال البرنامج الخفي الذي يقوم بنفس الإجراء.

هذا يعني أن لدي ملفات تخزين مؤقت محلية وإجراءات عن بعد في نفس الوقت.ربما ليست مثالية، ولكن ينبغي أن تعمل في الوقت الراهن.كان CouchDB بطيئًا جدًا ولم يكن NFS موثوقًا بدرجة كافية.

Answer 2

http://www.danga.com/memcached/

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

(أيضًا، تعمل memcached على تشغيل أشياء مثل YouTube وWikipedia وFacebook، لذلك أعتقد أنه من الثابت إلى حد ما أن المؤسسات التي لديها الوقت والمال والموهبة لإجراء تقييم جدي للعديد من خيارات التخزين المؤقت الموزعة تستقر مع memcached!)

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

Answer 3

دفاعًا عن memcached كمخزن مؤقت، إذا كنت تريد أداءً عاليًا مع تأثير منخفض لإعادة تشغيل الخادم، فلماذا لا يكون لديك 4 خوادم memcached فقط؟أو 8؟سيكون لكل "إعادة تشغيل" تأثير أقل على خادم قاعدة البيانات.