При любом асинхронном обмене сообщениями вы должны решать проблему «быстрого производителя / медленного потребителя». Есть несколько способов справиться с этим.
- Добавить потребителей. С WebSphere MQ вы можете запускать очередь в зависимости от глубины. Некоторые магазины используют это для добавления новых потребительских экземпляров по мере увеличения глубины очереди. Затем, когда глубина очереди начинает уменьшаться, лишние потребители отмирают. Таким образом, потребители могут автоматически масштабироваться с учетом меняющихся нагрузок. Другие брокеры обычно имеют аналогичную функциональность.
- Сделайте очередь и основную файловую систему действительно большими. Этот метод пытается полностью поглощать пики рабочей нагрузки в очереди. В конце концов, именно это и было предназначено для организации очередей. Проблема в том, что он плохо масштабируется, и вы должны выделить диск, чтобы 99% времени было почти пустым.
- Срок действия старых сообщений. Если у сообщений установлен срок действия, вы можете очистить их. Некоторые JMS-брокеры делают это автоматически, в то время как в других вам может понадобиться просмотреть очередь, чтобы удалить сообщения с истекшим сроком. Проблема заключается в том, что не все сообщения теряют свою деловую ценность и имеют право на истечение срока действия. Большинство сообщений о запрете (и журналах аудита и т. Д.) Попадают в эту категорию.
- Дроссель назад производитель. Когда очередь заполняется, ничто не может поместить в нее новые сообщения. В WebSphere MQ приложение-производитель получает код возврата, указывающий, что очередь заполнена. Если приложение различает фатальные и временные ошибки, оно может остановиться и повторить попытку.
Ключом к успешной реализации любого из них является то, что вашей системе разрешено предоставлять «мягкие» ошибки, на которые приложение будет реагировать. Например, многие магазины будут повышать параметр MAXDEPTH очереди при первом получении условия QFULL. Если глубина очереди превышает размер базовой файловой системы, то получается, что вместо «мягкой» ошибки, которая влияет на одну очередь, файловая система заполняется и затрагивается весь узел. Вы НАМНОГО лучше настраиваете систему так, чтобы очередь достигала значения MAXDEPTH задолго до заполнения файловой системы, но также позволяла приложению или другим процессам каким-либо образом реагировать на полную очередь.
Но что бы вы ни делали, опция № 4 выше обязательна. Независимо от того, сколько дискового пространства вы выделите или сколько пользовательских экземпляров вы развернули, или как быстро вы истекаете срок действия сообщений, всегда есть вероятность, что ваши потребители не будут отставать от производства сообщений. Когда это происходит, приложение вашего производителя должно сбросить скорость или поднять тревогу и остановиться или сделать что-либо кроме зависания или смерти. Асинхронный обмен сообщениями является асинхронным только до того момента, когда вам не хватит места для очередей сообщений. После этого ваши приложения синхронизируются и должны корректно обрабатывать эту ситуацию, даже если это означает (изящно) закрывать свои собственные.