Сбор распределенных данных в центральной базе данных
Мне было поручено обновить существующую систему сбора данных, поступающих из торговых точек, и добавления их в центральную базу данных. Тот, который работает сейчас, основан на передаче по FTP/SFTP, где информация отправляется один раз в день, обычно ночью. К сожалению, из-за нестабильной связи (низкокачественные модемы 2G/3G) некоторые файлы повреждены. Так как всего несколько магазинов были подключены таким образом, все работало гладко, но с ростом числа магазинов участились ошибки. Что еще хуже, время, необходимое для вставки данных в центральную базу данных, занимает до 12 - 14 часов (включая ожидание загрузки данных из всех магазинов), и это не может произойти в течение рабочего дня, поскольку это заблокирует процесс создание отчетов о продажах и других действий с базой данных - поэтому мы действительно не торопимся со временем обработки здесь.
Идея, предложенная моим менеджером, заключается в том, чтобы отправлять данные непрерывно в течение дня. Пакеты данных будут значительно меньше, поэтому их передача и вставка будут намного быстрее, центральный сервер будет содержать фактические (почти в реальном времени) данные, а ночь может использоваться для длительных операций с базами данных, таких как создание резервных копий, восстановление индексов и т. Д.
Пройдя по многим сайтам, я обнаружил, что:
- использование веб-службы ASMX теперь устарело, и вместо него следует использовать WCF
- WCF с MSMQ или System Messaging можно использовать для безопасной передачи данных, где мне не нужно особо заботиться о подтверждении доставки данных, согласованности, отключении узлов и т. Д.
- в соответствии с http://blogs.msdn.com/b/motleyqueue/archive/2007/09/22/system-messaging-versus-wcf-queuing.aspx организация очередей WCF лучше
- Существуют также другие технологии для реализации очереди сообщений, такие как RabbitMQ, ZeroMQ и т. д.
И вот тут я запутался. Имея так много вариантов, есть ли у вас плюсы и минусы этих технологий? Мы использовали.NET с Windows Forms и SQL Server, но если бы это было необходимо, мы могли бы перейти на что-то более подходящее. Я также немного боюсь эффективности сервера. После некоторых вычислений сервер будет получать около 15 пакетов данных в секунду (пик). Это много? Я знаю, что есть много веб-сайтов без серьезной серверной инфраструктуры, которые обрабатывают сотни посетителей в Интернете и по-прежнему работают без сбоев, но веб-сайт в основном загружает данные клиенту, и здесь мы будем загружать их с клиента.
Я также нашел несколько схожий вопрос SO: Middleware для построения сбора данных и мониторинга для распределенной системы, где упоминалось DDS. Что вы думаете о внедрении некоторых серверов промежуточного программного обеспечения, которые бы справлялись с низкокачественными ссылками на точки продаж, чтобы основной сервер не был забит передачей 1 КБ / с?
Я был бы благодарен за всю вашу помощь. Заранее спасибо!
2 ответа
Из того, что я понимаю, у вас есть в основном две проблемы:
- Потенциал для потери / повреждения данных вызова
- Производительность записи в базу данных
Возможность потери / повреждения данных вызова вызвана недостаточной надежностью при передаче данных от клиента к сервису.
И неясно, что является причиной проблем с конкуренцией / производительностью базы данных, за исключением смутной ссылки на большие объемы, поэтому этот ответ будет более ориентирован на решение первой проблемы.
Вы правильно определили необходимость надежной асинхронной передачи данных в качестве способа решения проблем надежности в вашей текущей настройке.
Глядя на MSMQ, чтобы поставить это является действительным первым шагом. MSMQ обеспечивает надежную связь через семантику хранения и пересылки сообщений, которая поставляется из коробки и требует очень небольшого количества настроек.
К сожалению, MSMQ подходит для двух задач:
- Надежный сетевой протокол и
- Клиентский сервис, работающий как на отправляющей, так и на принимающей машине.
Из вашего описания выше я не верю, что 1 существует (Интернет не является надежной сетью), и вы вполне можете бороться с 2 - MSMQ поставляется только с Windows Server или бизнес / корпоративными версиями Windows на рабочем столе.(* См. ниже...)
В качестве возможного решения проблемы надежности сети вы можете использовать конечную точку WCF или RESTful (используя Nancy или WebApi) для предоставления сервисных операций, предоставляемых через HTTP, которые будут принимать входящие вызовы от клиентских компьютеров. Эти технологии совершенно разные, поэтому вам нужно убедиться, что вы делаете правильный выбор на раннем этапе.
WCF поддерживает WS-ReliableMessaging из спецификации SOAP 1.2 из коробки, что позволяет осуществлять надежные вызовы веб-службы по протоколу http, однако это очень сложная конфигурация и, как правило, не очень удобная среда для работы.
REST намного проще, чем WCF в.Net, очень легкий и простой в использовании. Тем не менее, для надежной доставки вам придется предоставить какую-то операцию GET (в дополнение к POST, чтобы позволить клиенту отправлять данные), которая будет вызываться (в течение разумного периода времени) для проверки того, что данные были зафиксированы. Клиент должен был бы реализовать некоторую семантику повторных попыток, если результат "подтверждения" GET был отрицательным.
Несмотря на то, что для маршрута WCF требуются две операции, а не одна, я бы предпочел подход REST. Я сделал много и того, и другого, и REST-сервисы гораздо приятнее работать.
(*) Это не означает, что MSMQ не будет работать в вашем окончательном решении, просто он не будет использоваться для решения проблемы надежности передачи. Тем не менее, он все еще может быть использован для решения другой вашей проблемы - проблемы записи в базу данных. Если бы вы ставили в очередь входящие запросы после их поступления на сервер, они могли бы обрабатываться "автономным" процессом, который затем мог бы надежным образом выполнять необходимые операции с базой данных. Это можно сделать с помощью очередей транзакций MSMQ.
В ответ на комментарии:
99% сообщений передаются из магазина на главный сервер, но если необходимо внести некоторые изменения (коррекция цен, скидки и т. Д.), Эти данные необходимо отправить в магазин.
Этот вид изменений вещей. Если бы я с самого начала понял, что у вас есть двунаправленное требование, и, видя, как вам удалось установить связь с msmq, я бы подтолкнул вас к NServiceBus, который является действительно крутой оболочкой для MSMQ. Причина, по которой я бы сделал это, заключается в том, что у вас, похоже, есть как одностороннее, так и требование публикации-подписки, которое очень хорошо поддерживается NServiceBus.
Rabbitmq может легко справляться с тысячами 1кб сообщений в секунду.
Поскольку ваш вариант использования не связан с обработкой данных в реальном времени, я бы сказал, что вам следует объединить несколько сообщений и отправить их в виде пакета. Этого было бы достаточно, чтобы распределить нагрузку в течение дня.
Поскольку мотивация здесь не в том, чтобы обрабатывать данные в режиме реального времени, тогда любой транспортный уровень сделает эту работу. Даже ftp / sftp. Поскольку rabbitmq здесь будет работать нормально, это не типичный вариант использования.
Поскольку вы упомянули, что одной из ваших проблем является медленная / ненадежная сеть, я бы посоветовал сжать файлы перед их отправкой, а на принимающей стороне немедленно проверить их целостность. Rsync или подобное, вероятно, отлично справится с этой задачей.