نظام المنتج / المستهلك باستخدام قاعدة البيانات (MySQL)، هل هذا ممكن؟

Question

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

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

لقد كنت أبحث في البرنامج المساعد في قائمة انتظار الرسائل Q4M ل MySQL ولكن يبدو معقدا للاستخدام.

أحتاج حقا إلى بعض المدخلات حول كيفية بناء نظامي بشكل أفضل.

Answer 1

أحتاج إلى استخدام شيء لتنسيق نظامي مع العديد من المستهلكين / المنتجين كل يعمل على آلات مختلفة مع أنظمة تشغيل مختلفة

هذا هو قائمة انتظار الرسائل. لا تتبع البدائل الأخرى. كل شيء آخر (أي استخدام قاعدة بيانات مع إدراج وحذف) هو بطيء بشكل كبير ومرهقة.

غالبا ما تبني بناء قائمة انتظار رسالة كبيرة، بطيئة مع قاعدة بيانات بشكل سيء في الممارسة العملية لأن قواعد البيانات (1) بطيئة، (2) قواعد البيانات هائلة ومعقدة، (3) لديك قضايا قفل والتنافس التي تجعل كل معاملة بطيئة، ( 4) إنه أكثر من ذلك أكثر من المشكلة تستحق.

هناك العديد من حلول قائمة انتظار الرسائل.

إذا لم تتمكن من جعل عمل Q4M، فيجب عليك الانتقال إلى آخر.

http://en.wikipedia.org/wiki/message_queue.

http://linux.die.net/man/7/mq_overview.

http://qpid.apache.org/

http://code.google.com/p/httpsqs/

Answer 2

في الواقع (إلى حد ما) معقدة لبناء مثل هذا النظام. (أقول إلى حد ما، لأنه قابل للقيام بالطبع).

إذا كان لديك العديد من المنتج و واحد المستهلك، إنه سهل. كل منتج تكتب في وقت واحد، والمستهلك واحد قراءة البيانات بمجرد أن تكون مرئية (ملتزمة).

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

أود أن أقترح استخدام حل مدمج. يمكنك أيضا قراءة هذا السؤال حول سؤال مماثل.

Answer 3

أعتقد أنه من الممكن دون برنامج طرف ثالث.

سيكون التصميم الأول لي مثل هذا:

• المنتج يكتب البيانات إلى قاعدة البيانات
• لضمان الاتساق يجب أن تستخدم المعاملات
• عملية المستهلك البيانات (اقرأ وحذف) أيضا باستخدام المعاملات.

بسبب شرط المعاملات InnoDB هو الاختيار المنطقي لمحرك التخزين. كما يجب أن تختار بعناية مستوى العزلة. تخميني الأول هو "Serializable" لتجنب قراءة الوهمية، ولكن ربما يكون مستوى أضعف أيضا ممكن.

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

Answer 4

ذلك يعتمد المواقف.

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

آمل أن يساعد ذلك.