开发者

Does the order of fields in a RabbitMQ topic matter?

开发者 https://www.devze.com 2023-02-18 06:15 出处:网络
I\'m creating a logging facility for an application that will use RabbitMQ to collect log messages. I\'m trying to decide on how I should structure the topic fiel开发者_JS百科d of the message.

I'm creating a logging facility for an application that will use RabbitMQ to collect log messages. I'm trying to decide on how I should structure the topic fiel开发者_JS百科d of the message.

One way I could do it is something like:

<instance uuid>.<major component>.<minor component>.<log level>

or another alternative is something like:

<log level>.<major component>.<minor component>.<instance uuid>

Are there any performance or other considerations I should take in to account when deciding on the order of fields in the topic? or is it mostly arbitrary? As far as I can tell they are equally easy to match against using wildcards if I plan to use a topic exchange.


I think the order probably isn't as important as the complexity (the number of period delimiters) and the number of bindings which your broker will have. The amount of wildcarding used in your bindings will affect it too. But the question is, how much will all these affect performance?

If you are only going to have a few hundred queues bound with this scheme, I wouldn't worry. The Rabbit team just posted a new blog post on what they've been doing in the area of message routing within topic exchanges, and it's obvious that it's heavily, heavily optimized. Given the last chart in that blog post, I would at least install and run Rabbit MQ 2.4.0 as your broker.

Finally, I'd suggest running some very realistic soak/performance tests using both of your proposed orderings and see if they perform differently with your application. That's the most reliable way to find out if the ordering will affect your system.


I think that the only area where it matters is if you need to use # wildcard for routing from and exchange to queues.

If you have a.b.c.d and a.f.g.h then you can do things like a.#

but if you use d.a.c.b and h.a.g.f then you need to do something like *.a.# and you might be tempted to try #.a.# which will not do what you expect.

  • is faster than # and one wildcard match is faster than two.

On the other hand, a long list of non-wildcard matches may be quicker than you think. Time for benchmarking.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号