Обработка большого объема данных

Question

Мы изучаем интеграцию нашей платформы с Salesforce через Salesforce Outbound Messaging (SOM). Каждый раз, когда клиент обновляет объект (ы) в Salesforce, SOM вызовет нашу конечную точку Webservice с обновленным объектом (объектами) (до 100 объектов за один вызов). Наше Webservice необходимо обновить соответствующие записи в нашей базе данных.

SOM работает достаточно хорошо для наших целей, за исключением 1 вопроса.

Некоторые клиенты проводят массовые ночные обновления. Это не редкость для обновления 200 000-500 000 объектов. Это означает, что мы получим 2000-5000 вызовов со 100 объектами за очень короткий период времени. Наш Webservice будет перегружен настолько большим количеством данных, особенно если несколько клиентов делают массовые обновления близко друг к другу.

Чтобы справиться с этим большим объемом/шипом Web-сервер создаст сообщение на сервере приложений для каждого объекта в вызове SOM. Другой процесс будет принимать сообщения из очереди сообщений и обновлять базу данных.

MSMQ is only limited by hardware поэтому должен быть способен обрабатывать миллионы сообщений, пока мы очищаем отставание.

Главный вопрос заключается в том, что этот хороший дизайн для работы с большим количеством данных/вызовов webservice? Есть ли лучший способ?

Answer 1

Если вы обеспокоены способностью вашей системы обрабатывать большой объем из salesforce за короткий промежуток времени, возможно, вам стоит посмотреть на replication api. Это скорее модель тяги. Вы вызываете salesforce, когда будете готовы потреблять больше данных.

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

Answer 2

Вы просто ищете простую очередь, которая в основном хранит запросы веб-сервисов для асинхронной упорядоченной обработки на досуге, а не синхронно? Если это так, полноценные службы MQ - это переполнение WAY. Это довольно тривиальная (минус очевидная многопоточность), чтобы создать очередь в памяти, которая способна хранить 100 запросов k рабочих запросов и может сбрасывать свое состояние на диск или поддерживаться DB. Даже с нуля, хотя есть множество легких библиотек для Java и .NET, которые помогут в этом.

Решения NoSQL, такие как Redis, также были бы жизнеспособными вариантами (Redis, вероятно, превосходит другие параметры NoSQL из-за собственной поддержки списков и хэшей, а также легкой очистки диска). Amazon SQS предоставит вам безумно дешевое + масштабируемое хранилище сообщений в облаке, что было бы плюсом, если бы вы искали устойчивость - вы могли бы свободно снимать конечную точку обработки в течение нескольких часов без видимой видимости для конечного клиента, и все прохладные игрушки, которые вы получаете «из коробки» с AWS.

Answer 3

Я не буду хранить один объект за сообщение, а один набор объектов (одно сообщение SOM) в вашей локальной очереди сообщений. Помните, что после того, как вы ответили Ack на salesforce, вам нужно взять на себя ответственность за сохранение и восстановление сообщений и т. Д., Я бы подумал, что MSMQ отлично подходит.

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