Что не так с опросом?

Question

Я слышал, как несколько разработчиков недавно говорили, что они просто опрашивают материал (базы данных, файлы и т. Д.), Чтобы определить, что что-то изменилось, и затем запускают задачу, такую ​​как импорт.

Я действительно против этой идеи и чувствую, что использование доступных технологий, таких как Remoting , WCF и т. Д., Было бы намного лучше, чем опрос.

Однако я хотел бы определить причины, по которым другие люди предпочитают один подход другому, и что более важно, как я могу убедить других в том, что опрос не прав в наши дни?

Answer 1

Смысл опроса в том, что он работает! Его надежный и простой в реализации.

Стоимость объединения может быть высокой - если вы сканируете базу данных на предмет изменений каждую минуту, когда есть только два изменения в день, вы расходуете много ресурсов для очень маленького результата.

Однако проблема с любой технологией уведомлений заключается в том, что они гораздо сложнее реализовать и не только могут быть ненадежными, но (и это большое НО) вы не можете легко определить, когда они не работают.

Так что, если вы проводите опускание опросов для какой-либо другой технологии, убедитесь, что она пригодна для использования средними программистами и является сверхнадежной.

Answer 2

Это не ответ на ваш вопрос. Но реально, особенно в этот «день и век», когда процессорные циклы дешевы, а полоса пропускания велика, опрос для некоторых задач является довольно хорошим решением.

Преимущества:

• Дешевые
• Надежный
• Testable
• Гибкий

Answer 3

Как и все, это зависит. В большой системе с высокими транзакциями, над которой я работаю, в настоящее время используется уведомление с SQL (DLL, загруженная в SQL Server, которая вызывается расширенным SP из-за триггеров на определенных таблицах. Затем DLL уведомляет другие приложения о том, что есть над чем работать).

Однако мы отходим от этого, потому что мы можем практически гарантировать, что будет работа, которую нужно выполнять постоянно. Поэтому, чтобы уменьшить сложность и немного ускорить процесс, приложения будут обрабатывать свою работу и немедленно опрашивать БД на предмет новой работы. Если его не будет, он попытается через небольшой промежуток времени.

Кажется, это работает быстрее и намного проще. Однако другая часть приложения, которая имеет гораздо меньший объем, не выигрывает от увеличения скорости при использовании этого метода - если только интервал опроса не очень мал, что приводит к проблемам с производительностью. Итак, мы оставляем все как есть для этой части. Поэтому хорошо, когда это уместно, но потребности у всех разные.

Answer 4

Я согласен, что избегать голосования - это хорошая политика. Однако, ссылаясь на пост Роберта , я бы сказал, что простота опроса может сделать его лучшим подходом в тех случаях, когда проблемы, упомянутые здесь, не являются такой большой проблемой, поскольку асинхронный подход часто значительно меньше. удобочитаемым и сложным в обслуживании, не говоря уже об ошибках, которые могут запутаться в его реализации.

Answer 5

Согласитесь с большинством ответов, что Async / Messaging обычно лучше. Я абсолютно согласен с ответом Роберта Гулда. Но я хотел бы добавить еще одно замечание.

Еще одно дополнение - опрос может убить двух зайцев одним выстрелом. В одном конкретном случае использования проект, с которым я был связан, использовал очередь сообщений между базами данных, но проводил опрос с сервера приложений на одну из баз данных. Поскольку сеть между сервером приложений и БД иногда отключалась, опрос дополнительно использовался для уведомления приложения о сетевых проблемах.

В конце используйте то, что имеет смысл наиболее разумно для случая использования с учетом масштабируемости.

Answer 6

Размышляя об опросе SQL, еще во времена VB6 вы могли создавать наборы записей с помощью ключевого слова WithEvents, которое было ранним воплощением асинхронного «прослушивания».

Лично я всегда искал бы способ использования реализации, управляемой событиями, перед опросом. В противном случае может помочь ручная реализация любого из следующего:

• сервисный брокер sql / класс зависимостей
• Некоторая технология очереди (RabbitMQ или аналогичная)
• UDP трансляция - интересная техника, которая может быть построенным с несколькими слушателями узла. Хотя не всегда возможно в некоторых сетях.

Для некоторых из них может потребоваться небольшая редизайн вашего проекта, но в корпоративном мире может быть лучший путь, чем услуга опроса.

Answer 7

Вот хорошее резюме относительных достоинств push и pull: https://stpeter.im/index.php/2007/12/14/push-and-pull-in-application-architectures/

Хотелось бы обобщить это далее в этом ответе, но некоторые вещи лучше оставить без изменений.