У меня есть система, которая имеет строгие требования «один раз и только один раз» в отношении того, что она делает.Это управляемая событиями система с промежуточным программным обеспечением, которая не может гарантировать один и только один раз обмен сообщениями (она помечает любое данное сообщение как «доставленное», если сомневается, является ли это повторной доставкой).Обработка «один раз и только один раз» в основном сводится к состоянию нашего основного предметного объекта, то есть это довольно стандартная установка, при которой ....
- сообщения прибывают
- бизнес-логикавыполняется
- состояние обновляется
- выходные данные генерируются и отправляются в нисходящие системы
3 должен в конечном итоге попасть в базу данных (книги и записи), 4 может занятьразличные формы, но все они являются своего рода сообщениями для внешних систем.Существует множество других потоков, но все они сводятся к такому стилю обработки.Все сообщения будут работать с одним экземпляром объекта основного домена, и поэтому обработка может быть привязана к этому экземпляру к одному jvm.
Мой Q довольно общий, возможно, слишком общий, но я все равно спрошу.А именно, какие стратегии / модели можно использовать для увеличения пропускной способности при сохранении требуемых гарантий?Кроме того, каковы основные ошибки, которые убивают производительность?
Например, одна из идей заключается в том, чтобы избежать какой-либо стойкости на критическом пути, что сводится к вопросу о том, как поддерживать согласованность состояния в памяти без необходимости обновления из базы данных.
Вы можете предположить, что можно масштабировать с помощью некоторой стратегии разбиения, но этот аспект выходит за рамки вопроса q.Вопрос о том, как увеличить пропускную способность отдельного узла в такой системе.
Обратите внимание, что это java / oracle в условиях большого предприятия, поэтому нишевое оборудование (например, exadata & friends или какой-то необычный сетевой комплект)Это хорошо.