Comments 2
Использование Ms SQL в качестве Message store для гарантированной доставки какую производительность обеспечивает? Хотя бы качественные оценки.
Вы сравнивали с другими шинами (GlassFish, Jboss, ActiveMQ и другими)?
Вы сравнивали с другими шинами (GlassFish, Jboss, ActiveMQ и другими)?
Если говорить о выборе MS SQL в качестве Message store, то в данном случае альтернатив не предусмотрено: The platform is based on Windows Server and Microsoft SQL Server. (https://msdn.microsoft.com/en-us/library/dn282142.aspx). Хотя, детально в вопрос я, если честно, не вникал.
Если говорить о надежности MS SQL, то для Message store можно настроить AlwaysOn (пришедший на смену Mirroring).
Но тут разговор, наверно, больше о высоком уровне доступности. Т.е. по факту сервер БД, как конечная точка, один. А входных каналов (серверов с настроенной Service Bus) много и они объединены в высокодоступную «ферму». Подробнее об этом описано в разделе MSDN архитектура (https://msdn.microsoft.com/ru-ru/library/dn441428.aspx).
Из практического опыта, определенная магия там конечно есть. Если один «входной» сервер с Service Bus падает, то клиент это понимает и обращается к другому серверу, не генерируя при этом исключения. Такая же магия есть и в механизме load balancing.
С точки зрения API, вы создаете ServiceBusConnectionStringBuilder, указываете несколько Endpoints и StsEndpoints (наряду с ManagementPort, RuntimePort, SharedAccessKeyName, SharedAccessKeyName), а клиент при недоступности одного, сам обращается к другим.
Сравнить с GlassFish, Jboss, ActiveMQ, к сожалению, не довелось. Но за наводку большое спасибо!
Если говорить о надежности MS SQL, то для Message store можно настроить AlwaysOn (пришедший на смену Mirroring).
Но тут разговор, наверно, больше о высоком уровне доступности. Т.е. по факту сервер БД, как конечная точка, один. А входных каналов (серверов с настроенной Service Bus) много и они объединены в высокодоступную «ферму». Подробнее об этом описано в разделе MSDN архитектура (https://msdn.microsoft.com/ru-ru/library/dn441428.aspx).
Из практического опыта, определенная магия там конечно есть. Если один «входной» сервер с Service Bus падает, то клиент это понимает и обращается к другому серверу, не генерируя при этом исключения. Такая же магия есть и в механизме load balancing.
С точки зрения API, вы создаете ServiceBusConnectionStringBuilder, указываете несколько Endpoints и StsEndpoints (наряду с ManagementPort, RuntimePort, SharedAccessKeyName, SharedAccessKeyName), а клиент при недоступности одного, сам обращается к другим.
Сравнить с GlassFish, Jboss, ActiveMQ, к сожалению, не довелось. Но за наводку большое спасибо!
Sign up to leave a comment.
Настраиваем свою комнатную Service Bus for Windows Server