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

Question

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

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

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

Answer 1

Опрос не является «неправильным».

Многое зависит от того, как оно реализовано и с какой целью. Если вы действительно заботитесь о немедленном уведомлении об изменении, это очень эффективно. Ваш код сидит в узком цикле, постоянно опросив (запрашивая) ресурс, изменился ли он/обновился. Это означает, что вы будете уведомлены, как только сможете, что что-то другое. Но ваш код ничего не делает, и есть накладные расходы по многим вызовам объекта.

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

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

Что такое «неправильное» с опросом?

• Это может быть ресурс.
• Это может быть ограничение (особенно если у вас есть много вещей, о которых вы хотите узнать/опрос).
• Это может быть излишним.

Но ...

• Это не по своей сути неправильно.
• Это может быть очень эффективным.
• Это очень просто.

Answer 2

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

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

Я всегда стараюсь избегать опроса, но иногда я делаю опрос в любом случае, особенно когда фактические прибыли от асинхронной обработки не так велики, например, когда действуют против небольших локальных данных (конечно, вы получаете немного быстрее, но пользователи не заметят разницы в таком случае). Так что есть место для обеих методологий ИМХО.

Answer 3

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

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

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

Answer 4

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

В базе данных вы можете активировать обновление/вставку, а затем вызвать свой внешний код, чтобы что-то сделать. Однако может быть просто, что у вас нет требования к мгновенным действиям. Например, вам может потребоваться только получить данные из базы данных A в базу данных B в другой сети в течение 15 минут. База данных B может быть недоступна из базы данных A, поэтому вы в конечном итоге выполняете опрос или в качестве автономной программы, находящейся поблизости, в базе данных B.

Кроме того, опрос - очень простая задача для программирования. Это часто делается на первом этапе, когда ограничения времени короткие, и потому что он работает достаточно хорошо, он остается.

Answer 5

Есть две причины, по которым опрос может считаться неудачным по принципу.

1. Это пустая трата ресурсов. Очень вероятно, что вы проверите изменения, пока никаких изменений не произошло. Процессы ЦП/пропускная способность трассировки на это действие не приводят к изменению и, следовательно, лучше потратить на что-то еще.

2. Опрос сделан на определенном интервале. Это означает, что вы не будете знать, что произошли изменения до следующего перерыва этого интервала.

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

Answer 6

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

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

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

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

Answer 7

Его простой опрос - плохое, неэффективное, трата ресурсов и т. Д. Всегда есть какая-то форма подключения, которая в любом случае контролирует какое-то событие, даже если «опрос» не выбран.

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

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

Если вы продолжаете звонить или звонить вашей подруге, а shes никогда не отвечает, то зачем звонить? Просто оставьте сообщение и подождите, пока она «перезвонит»;)

Answer 8

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

Answer 9

Я иногда использую опрос для определенных ситуаций (например, в игре я бы опросил состояние клавиатуры каждый кадр), но никогда в цикле, который ТОЛЬКО делает опрос, скорее я бы сделал опрос как проверку (имеет ресурс X изменился? Если да, сделайте что-нибудь, иначе обработайте что-нибудь еще и еще раз проверьте позже). Вообще говоря, я избегаю опроса в пользу асинхронных уведомлений.

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

Answer 10

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

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

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

Answer 11

Примеры вещей, которые используют опрос в этот день и возраст:

• Email клиентов опрос на наличие новых сообщений (даже с IMAP).
• Опрос читателей RSS для изменений в каналах.
• Опрос поисковых систем для внесения изменений на страницы, которые они индексируют.
• Опрос пользователей StackOverflow для новых вопросов, нажав 'refresh' ;-)
• Клиенты Bittorrent опросили трекер (и друг друга, я думаю, с DHT) для изменений в рое.
• Spinlocks на многоядерных системах может быть наиболее эффективной синхронизацией между ядрами, в случаях, когда задержка слишком короткая, чтобы было время запланировать еще один поток на этом ядре, прежде чем другое ядро ​​сделает все, что мы ожидаем ,

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

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

Для локального файла уведомление об изменениях, вероятно, будет лучшим вариантом в принципе. Например, вы могли бы (возможно) предотвратить дисковое вращение вниз, если вы навсегда его подталкиваете, хотя тогда ОС может кэшировать. И если вы каждый месяц прогоняете файл, который меняется только один раз в час, вы можете без необходимости занимать 0,001% (или что-то еще) от вычислительной мощности вашей машины. Это звучит крошечно, но что происходит, когда есть 100 000 файлов, которые нужно опросить?

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

Answer 12

Я думаю, люди должны понимать, что в большинстве случаев на каком-то уровне проводится опрос даже в случае или прерывания но вы изолированы от фактического кода, выполняющего опрос. На самом деле, это самая желательная ситуация ... изолировать себя от реализации и просто иметь дело с событием. Даже если вы должны сами выполнить опрос, напишите код, чтобы он был изолирован, и результаты были рассмотрены независимо от реализации.

Answer 13

Я вижу много ответов, но я думаю, что самый простой ответ ответа это сам:

Потому что (как правило) гораздо проще кодировать цикл опроса, чем сделать инфраструктуру для обратных вызовов.

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

Answer 14

Опрос клиентов не масштабируется, а также уведомления о сервере. Представьте, что тысячи клиентов спрашивают у сервера «какие-либо новые данные?» каждые 5 секунд. Теперь представьте, что сервер хранит список клиентов для уведомления о новых данных. Предупреждение сервера лучше масштабируется.

Answer 15

Вот хороший обзор относительных достоинств Тяговое и толкающее: https://stpeter.im/index.php/2007/12/14/push-and-pull-in-application-architectures/

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

Answer 16

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

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

• SQL
• какое-то технологии очередей (RabbitMQ или аналогичное)
• UDP вещания - интересный метод, который может быть построенный с несколькими прослушивателями узлов. Тем не менее, это не всегда возможно.

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

Answer 17

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

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

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