Обработка большого количества данных

Question

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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