I know there's no definitive answer to this but I'm sure there's a good steer I should be following.
I have ~ 20k terminal devices awaiting product updates, which they have requested via a web Api. The terminal talks to the Web API 'get my products' method which makes a call into our backend.
The backend responds by publishing all the relevant products to an exchange which is bound to a queue that the terminal is subscribing to.
My question is whether we're better off having a separate (direct) exchange per terminal which is in turn bound to a single queue for the terminal.
Or should we implement it as publish to one (direct) exchange which is bound to ~ 20k queues, each of which has the terminals id as it's routing key, thus letting rabbit do our delivery to the correct queue for us for us.
Any thoughts or pointers gratefully received guys, particularly around resource usage, performance issues and so on.
Steve
Related
Here's an example:
TYPE : TOPIC
exchange.v1 -> queue.order
exchange.v2 -> queue.log
so when the apps running it's must configure the exchange first right? and in a single service only can have 1 exchange?
I have 1 service for logging and 1 service for ordering. all proses will be sent into logging service and then forward another event. in this case to queue.order
So it's possible to publish an event from a different exchange? or I miss something? please let me know :(
Exchanges are not tied to “services”, much less in a 1:1 manner.
Exchanges in RabbitMQ are message sinks. Any existing exchanges can be published to by any number of applications (“services”) with adequate permissions.
Exhanges can either be pre-deployed or created automatically by an application. Pre-deployment is usually more common. This may or may not be outside the lifecycle of a single “service”.
Exchanges (depending on type) may also route to any number of queues on the same vhost.
Now, with all of that out of the way..
It is very possible to forward a message from a queue to another exchange: read from queues (stores), publish to exchanges (sinks). This can be done in code or even from a tool like the Shovel plugin - the “correct” approach depends significantly based on semantics, just as the choice of routing.
Personally, I recommend keeping RabbitMQ processing chains to as limited a scope as allowed by the application domain.
I'm working with a product suite which uses RabbitMQ as a back end for service bus messaging. Many of the clients use software (NeuronESB) which is supposed to automatically configure exchanges, queues and channels as needed. Somewhere in the system exchanges in Rabbit are being deleted and not re-created, resulting in unexpected issues. Because of the size of the system and closed source nature of at least one of the service bus clients, an audit of code has been unsuccessful in determining the source of the deletion of these exchanges.
I have tried using the firehose functionality of Rabbit, but that only provides the messages being sent through Rabbit, not the internal activities I need.
What methods are available for logging the creation and deletion of exchanges in RabbitMQ? Ideally I would like to know the date, time and client IP of the deleter, but even just getting the date and time would allow me to narrow my search of logs to help find the offender.
Try Events Exchange plugin that should do the trick.
If not working for some reason, the last resort I can think of:
Get a test environment with less clients/messages if you app is busy, then analyse your traffic with wireshark (it can understand amqp) to filter out requests to delete exchange.
This is a new area for me so hopefully my question makes sense.
In my program I have a large number of clients which are windows services running on laptops - that are often disconnected. Occasionally they come on line and I want them to receive updates based on user profiles. There are many types of notifications that require the client to perform some work on the local application (i.e. the laptop).
I realize that I could do this with a series of restful database queries, but since there are so many clients (upwards to 10,000) and there are lots of different notification types, I was curious if perhaps this was not a problem better suited for a messaging product like RabbitMQ or even 0MQ.
But how would one set this up. (let's assume in RabbitMQ?
Would each user be assigned their own queue?
Or is it preferable to have each queue be a distinct notification type and you would use some combination of direct exchanges or filtering messages based on a routing key, where the routing key could be a username.
Since each user may potentially have a different set of notifications based on their user profile, I am thinking that each client/consumer would have a specific message for each notification sitting on a queue waiting for them to come online and process it.
Is this the right way of thinking about the problem? Thanks in advance.
It will be easier for you to balance a lot of queues than filter long ones, so it's better to use queue per consumer.
Messages can have arbitrary headers and body so it is the right place for notification types.
Since you will be using long-living queues, waiting for consumers on disk - you better use lazy queues https://www.rabbitmq.com/lazy-queues.html (it's available since version 3.6.0)
We have multiple web and windows applications which were deployed to different servers that we are planning to integrate using NservierBus to let all apps can pub/sub message between them, I think we using pub/sub pattern and using MSMQ transport will be good for it. but one thing I am not clear if it is a way to avoid hard code to set sub endpoint to MSMQ QueueName#ServerName which has server name in it directly if pub is on another server. on 6-pre I saw idea to set endpoint name then using routing to delegate to transport-level address, is that a solution to do that? or only gateway is the solution? is a broker a good idea? what is the best practice for this scenario?
When using pub/sub, the subscriber currently needs to know the location of the queue of the publisher. The subscriber then sends a subscription-message to that queue, every single time it starts up. It cannot know if it subscribed already and if it subscribed for all the messages, since you might have added/configured some new ones.
The publisher reads these subscriptions messages and stores the subscription in storage. NServiceBus does this for you, so there's no need to write code for this. The only thing you need is configuration in the subscriber as to where the (queue of the) publisher is.
I wrote a tutorial myself which you can find here : http://dennis.bloggingabout.net/2015/10/28/nservicebus-publish-subscribe-tutorial/
That being said, you should take special care related to issues regarding websites that publish messages. More information on that can be found here : http://docs.particular.net/nservicebus/hosting/publishing-from-web-applications
In a scale out situation with MSMQ, you can also use the distributor : http://docs.particular.net/nservicebus/scalability-and-ha/distributor/
As a final note: It depends on the situation, but I would not worry too much about knowing locations of endpoints (or their queues). I would most likely not use pub/sub just for this 'technical issue'. But again, it completely depends on the situation. I can understand that rich-clients which spawn randomly might want this. But there are other solutions as well, with a more centralized storage and an API that is accessed by all the rich clients.
I've been reading through the documentation on the NServiceBus site but am struggling to piece it all together.
The goal is to provide a durable messaging solution between on-premise back office systems and a public facing web site in another data center.
I will need bidirectional (on-premise <> web site) pub-sub and request-response communication.
The documentation makes it clear that there isn't one central point that all communication goes through, but surely the subscriptions need to persisted somewhere (in a central location?).
The NServiceBus gateway does look like it would meet my requirements but I can't find any working examples of this.
Can someone provide a bit more detail on how the Gateway works and whether it will meet my requirements?
The subscriptions are persisted on each publisher endpoint. Say you have a service endpoint publishing web orders. All other services who are interested can subscribe by sending a subscription message to the publisher, who then stores the subscriptions locally. When a message is available the publisher evaluates the subscriptions and send a message to each of the subscribers.
This brings us onto your other requirement - that of request/response. Because NSB is based on msmq, everything is asynchronous. The most a publisher could do is send a response to a caller just saying that the request has been received and will be published. The nature of async messaging means that you cannot have a synchronous response from any downstream subscribers.
But this cost comes with benefits - namely reliability and availability.
Reliability - because you are using durable messaging the messages will eventually be delivered, at which point a response can be generated which will also eventually find it's way back to the caller. This is highly reliable when compared to request response.
Availability: because the publisher service is always able to send a message (whether a downstream subscriber is available or not), it never needs to block incoming requests. If you load balance your publisher somehow you can easily achieve availability at enterprise levels.
However you need to balance this against your latency requirements. Asynchrony usually equals latency. So if you have latency requirements in the sub-100 ms range NSB may not be your best bet.
Apologies for not answering your query about NSB Gateway - I have never used it.
Hope this helps.
The Gateway solves the communication problem between sites. It will ensure that messages get delivered from SiteA to SiteB. The messages are hashed and validated on the other end. Apparently there isn't an example of this in 2.5, so I'm thinking of throwing one together as this has come up a few times in the past month.