开发者

Is Message Queuing the right strategy for a high-bandwidth data feed?

开发者 https://www.devze.com 2023-04-11 03:16 出处:网络
I have a huge network of data-collection servers which generate a large volume of real-time data. In the past I\'ve provided partners with the ability to get this data in near-real-time using HTTP GE

I have a huge network of data-collection servers which generate a large volume of real-time data.

In the past I've provided partners with the ability to get this data in near-real-time using HTTP GET's. But for many reasons I'm eager to ditch this.

So yeah... I'm eager to build out a new distribution system and I was thinking that a Message Queuing System was the way to go.

I need to be able to distribute data from my sources to a number of different partners. Some partners receive all of it, others just get a portion. And, if a partner gets disconnected, they need to be able to reconnect and not miss any data. (Although, for the sake of disk and memory I'd like their queued messages to expire after hour or so)

Lastly I need the system to be able to handle tens of thousands of enqueue's per minute.

Do you think Message Queuing is an appr开发者_JAVA百科opriate scheme?

I was looking at using RabbitMQ. Is it difficult to maintain?

Thanks Very Much!

-Z


I cannot tell you if it is the right strategy in your specific case, but message products are indeed used in high message rate systems every day.

Much of the investment world uses various products, both commercial (Tibco) and Open source (ZeroMQ) to name just two, to handle market data from exchanges and other sources. These are likely at least as active as your data sensors are.

The publish/subscribe model, where some receivers want some messages and some receivers want all, along with late-join or other so-called guaranteed messaging are indeed standard features on most of these products.

So do go ahead and investigate products, I have not used RabbitMQ myself, so cannot comment on it specifically, however with a minimal abstraction layer, you should be able to insulate yourself from too many platform specific calls, and therefore allow you to swap message-bus implementers if the need arises. (You may even want to build such a shim as part of a proof-of-concept to test out more than one product for your specific purpose. You get experience in multiple products, flesh out the facade layer, and get up to speed on the products)

Good Luck

0

精彩评论

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

关注公众号