ما هو الخطأ مع الاقتراع ؟

https://stackoverflow.com/questions/320284

11-07-2019
|

سؤال

سمعت عدد قليل من المطورين مؤخرا لا الاقتراع الاشياء (قواعد البيانات, ملفات, الخ.) لتحديد عندما يكون هناك شيء قد تغير ثم قم بتشغيل مهمة ، مثل الاستيراد.

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

ومع ذلك أود أن تحديد الأسباب لماذا الناس يفضلون نهج واحد على الآخر والأهم من ذلك كيف يمكن إقناع الآخرين بأن الاقتراع هو الخطأ في هذا العصر ؟

المحلول

الاقتراع هو "مخطئ" على هذا النحو.

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

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

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

ما هو "خطأ" مع الاقتراع ؟

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

ولكن...

ليس خطأ في حد ذاته.
يمكن أن تكون فعالة جدا.
هو بسيط جدا.

نصائح أخرى

هناك سببان لماذا الاقتراع يمكن أن تعتبر سيئة من حيث المبدأ.

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

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

أمثلة من الأشياء التي تستخدم الاقتراع في هذا اليوم وهذا العصر:

عملاء البريد الإلكتروني استطلاع جديد رسائل (حتى مع IMAP).
قراء آر إس إس استطلاع التغييرات إلى الأعلاف.
محركات البحث استطلاع التغييرات إلى صفحة الفهرس.
ستاكوفيرفلوو المستخدمين استطلاع أسئلة جديدة ، من خلال ضرب 'تحديث' ;-)
تورنت العملاء استطلاع تعقب (و كل الأخرى, أعتقد, مع DHT) لإجراء تغييرات في سرب.
Spinlocks على متعدد النظم الأساسية يمكن أن تكون أكثر كفاءة التزامن بين النوى ، في الحالات التي يكون فيها التأخير قصيرة جدا أن يكون هناك وقت لتحديد موعد آخر موضوع على هذه النواة ، قبل الأخرى الأساسية يفعل ما نحن في انتظار.

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

في أوقات أخرى ، الاقتراع رخيصة بما فيه الكفاية للعمل حتى عندما يكون هناك المتزامن الإخطار.

على ملف محلي ، إخطار من التغييرات من المرجح أن يكون الخيار الأفضل من حيث المبدأ.على سبيل المثال ، قد (قد) منع القرص الغزل إلى أسفل إذا كنت إلى الأبد بدس ذلك ، على الرغم ثم مرة أخرى على نظام تشغيل ذاكرة التخزين المؤقت.وإذا كنت الاقتراع في كل ثانية على الملف الذي يتغير سوى مرة واحدة في الساعة ، قد يكون داع الاحتلال 0.001% (أو أيا كان) من الجهاز الخاص بك قوة المعالجة.هذه الأصوات صغيرة, ولكن ماذا يحدث عندما يكون هناك 100,000 الملفات التي تحتاج إلى الانتخابات ؟

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

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

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

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

والاقتراع العميل لا مقياس وكذلك الإخطارات الخادم. تخيل الآلاف من العملاء يطلب من الخادم "أي بيانات جديدة؟" كل 5 ثواني. الآن تخيل الخادم حفظ قائمة من العملاء للإبلاغ البيانات الجديدة. إعلام الخادم جداول أفضل.

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

ووبسيطة - الاقتراع سيئة - غير فعالة، وإهدار الموارد، وما إلى ذلك هناك دائما شكل من أشكال الاتصال في المكان الذي يراقب لحدث من نوع ما على أي حال، حتى لو لم يتم اختيار "الاقتراع '

وهكذا لماذا تتقدموا خطوة وضعت الاقتراع إضافي في المكان.

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

إذا واصلتم بالاتصال / رنين صديقة وشيس الخاص بك أبدا الإجابات، ثم لماذا تبقي الدعوة؟ مجرد ترك رسالة، وانتظر حتى انها "تدعو إلى الوراء؛)

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

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

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

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

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

الشيء عن الاقتراع هو أنه يعمل!موثوق بها وسهلة التنفيذ.

تكاليف تجميع يمكن أن تكون عالية -- إذا كنت مسح بيانات يتغير كل دقيقة عندما لا يوجد سوى اثنين من التغييرات يوم كنت تستهلك الكثير من الموارد صغير جدا نتيجة.

لكن المشكلة مع أي إخطار technoligy أنها أكثر تعقيدا من ذلك بكثير لتنفيذ و ليس فقط أنها يمكن أن تكون غير موثوق بها ولكن (وهذا هو كبير ولكن) لا يمكنك بسهولة معرفة عندما لا تعمل.

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

وأرى العديد من الإجابات هنا، ولكن أعتقد أن أبسط الجواب هو الجواب هو النفس:

ولأن هو (عادة) أبسط بكثير إلى رمز حلقة الاقتراع من لجعل البنية التحتية للرد.

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

ليس هذا هو الرد على سؤالك.لكن واقعيا, لا سيما في هذا "العصر" حيث المعالج دورات رخيصة و عرض النطاق الترددي كبيرة ، الاقتراع هو في الواقع جيدة جدا حل بعض المهام.

الفوائد:

رخيصة
موثوق بها
قابلة للاختبار
مرنة

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

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

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

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

وفيما يلي ملخص جيد للمزايا النسبية الشد والجذب: https://stpeter.im /index.php/2007/12/14/push-and-pull-in-application-architectures/

وأتمنى أن تلخيص ذلك الى مزيد من هذه الإجابة ولكن بعض الأشياء من الأفضل تركها يمس.

عند التفكير في SQL الاقتراع في يوم من VB6 كنت قادرا على إنشاء مجموعات السجلات باستخدام WithEvents الكلمة الذي كان في وقت مبكر تجسد المتزامن "الاستماع".

أنا شخصيا دائما ابحث عن طريقة استخدام الأحداث مدفوعة التنفيذ قبل الاقتراع.إذا تعذر ذلك دليل تنفيذ أي من الأمور التالية قد تساعد:

sql service broker / تبعية الدرجة
نوع من الانتظار التكنولوجيا(RabbitMQ أو ما شابه)
البث UDP - تقنية مثيرة للاهتمام التي يمكن أن سيتم بناؤها مع العديد من عقدة المستمعين.ليس من الممكن دائما على الإنترنت يعمل على الرغم من.

بعض هؤلاء قد تتطلب طفيف تصميم المشروع الخاص بك, ولكن في المؤسسة العالمية قد تكون أفضل طريق للذهاب بدلا من الاقتراع الخدمة.

وAgreee مع معظم الردود التي التزامن / التراسل عادة ما يكون أفضل. وأنا أتفق تماما مع الجواب روبرت غولد. ولكن أود أن أضيف نقطة واحدة.

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

في النهاية، ما يجعل استخدام <م> اكثر احساسا لحالة استخدام مع نطاق القدرة في الاعتبار.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow