Механизм сохранения должен основываться на потребностях вашего приложения. Тесно связанной проблемой будет отказоустойчивость / доступность.
Говоря исключительно о скорости сохранения сообщений, KahaDB будет самым быстрым; он настроен специально для шаблонов, окружающих обмен сообщениями (запись / чтение / удаление). Если вы будете использовать что-то вроде MSSQL, даже при включенном ведении журналов, вы потеряете эффективность на несколько порядков (в мг / сек). Эта настройка хорошо работает, если вы заинтересованы в публикации больших объемов сообщений и хотите оставить восстановление сообщений на усмотрение администратора или какого-то процесса «изобретено здесь».
Итак, почему вы выбрали бы другой механизм сохранения? Высокая доступность.
Re: что-то вроде реляционной базы данных, возможно, это что-то уже доступно на вашем предприятии, что означает, что кто-то (надеюсь) прошел через кластеризацию и тестирование аварийного восстановления. Это означает, что у вас должна быть возможность настроить главный / подчиненный, и ваши сообщения будут восстановлены, если мастер отключится. Подчиненный обнаружит потерю блокировки и начнет использовать точно такое же хранилище сообщений. Эта настройка идеальна, если ваш порог производительности намного ниже, но вы крайне обеспокоены временем работоспособности и тем, что всегда можете публиковать / подписывать сообщения.
Несмотря на это, в хорошо настроенной системе мы говорим> = сотни мсг / с, поэтому соображения производительности скорее всего , а не будут вашей первой проблемой. Если бы производительность действительно была столь важной, я бы рассмотрел что-то наподобие RabbitMQ , которое определенно хорошо себя зарекомендовало, чтобы быть чрезвычайно эффективным за счет усложнения настройки высокой доступности. .
Вот обсуждение некоторых опций восстановления после отказа с ActiveMQ . Я остановился на использовании общего / подчиненного файла с общей установкой KahaDB в сети SAN. Кажется, это хорошее решение среднего уровня.