WSO2 Message Broker is not yet another message broker. Rather, it can scale to meet high messaging demands due to following reasons.
1. Scale adding more broker nodes as a cluster and publish your messages or do subscriptions in a load balanced way.
2. Scale Cassandra for high availability and high speed message writing and reading.
3. Cassandra is very fast in reading and writing large messages natively.
Because of above reasons, even if many commercial and conventional message brokers has very low performance when "size of a message" becomes large, WSO2 Message Broker can function delivering reasonable performance, if you are not happy with the performance it can be scaled.
This post addresses how messages addressed to queues are handled only. Further synchronization of subscriptions and others states among cluster nodes are out of scope of this post.
Following diagram depicts the internal behavior of a single node of WSO2 MB cluster.
Basic message flow happens according to following sequence.
1. To publish a message client uses JMS. Andes client library has implementations for JMS API 1.1. It will transfer the message to WSO2 MB according to AMQP 0-91 specification.
2. At WSO2 MB side first it will decode the message (metadata and data chunks) according to the AMQP protocol specification.
3. The message content will be written separately into Cassandra. This will be done "only once per a message during its life-time in WSO2 MB" (even for clustered environment).
4. When the message interpretation is done we send the metadata (this has all routing information) of the message to a "global queue". In a cluster there is a predefined number of global queues (by default this value is 10). Every global queue is shared among all the server nodes. We decide to which global queue it should be written using a hash function.
5. There are "Global Queue Worker Threads" residing inside each server node in the cluster. Its responsibility is to read metadata from a particular shared global queue and copy it to nodes (particularly for "node queues" of nodes) which are having actual subscriptions for messages. These threads are shared among the nodes. So this load is always distributed.
6. There is a Cassandra space for each node, which will eventually get messages from to deliver it for its subscriptions. As above said, after Global Queue Worker Threads have copied messages to the node queue that particular node has access to them.
7. "QueueDeliveryWorker" thread delivers messages back to AMQP interface to deliver messages to actual subscriptions.
8. Inside WSO2 MB, message will go though a state model when delivered. Acknowledgement modes and transactions are handled by this state model.
9. Now message will get buffered into subscriber client side. There is an internal buffer there will pre-fetch messages so that the subscriber does not always need to poll messages from server.
10. Application at subscriber side will receive message from this buffer and eventually acknowledge.
11. server will remove message (metadata and content) from Cassandra space.
12. If ack did not came for a defined time server will resend the message with "re-delivered" JMS message header.
13. Message will be redelivered for defined number of time as above and eventually will we written into Dead Letter Channel (comes in the next version of WSO2 Message Broker).
14. Message Expiration will be handled properly future.
15. Flow control and message throttling will be implemented in on-coming releases.
WSO2 Message Broker is an actively developing project at WSO2. We will introduce many new features in near feature together with performance enhancements.
Give it a try downloading the product from here.
What's more, all the code is free too :D
Welcome to discuss and support us to develop.
1. Scale adding more broker nodes as a cluster and publish your messages or do subscriptions in a load balanced way.
2. Scale Cassandra for high availability and high speed message writing and reading.
3. Cassandra is very fast in reading and writing large messages natively.
Because of above reasons, even if many commercial and conventional message brokers has very low performance when "size of a message" becomes large, WSO2 Message Broker can function delivering reasonable performance, if you are not happy with the performance it can be scaled.
This post addresses how messages addressed to queues are handled only. Further synchronization of subscriptions and others states among cluster nodes are out of scope of this post.
Following diagram depicts the internal behavior of a single node of WSO2 MB cluster.
Basic message flow happens according to following sequence.
1. To publish a message client uses JMS. Andes client library has implementations for JMS API 1.1. It will transfer the message to WSO2 MB according to AMQP 0-91 specification.
2. At WSO2 MB side first it will decode the message (metadata and data chunks) according to the AMQP protocol specification.
3. The message content will be written separately into Cassandra. This will be done "only once per a message during its life-time in WSO2 MB" (even for clustered environment).
4. When the message interpretation is done we send the metadata (this has all routing information) of the message to a "global queue". In a cluster there is a predefined number of global queues (by default this value is 10). Every global queue is shared among all the server nodes. We decide to which global queue it should be written using a hash function.
5. There are "Global Queue Worker Threads" residing inside each server node in the cluster. Its responsibility is to read metadata from a particular shared global queue and copy it to nodes (particularly for "node queues" of nodes) which are having actual subscriptions for messages. These threads are shared among the nodes. So this load is always distributed.
6. There is a Cassandra space for each node, which will eventually get messages from to deliver it for its subscriptions. As above said, after Global Queue Worker Threads have copied messages to the node queue that particular node has access to them.
7. "QueueDeliveryWorker" thread delivers messages back to AMQP interface to deliver messages to actual subscriptions.
8. Inside WSO2 MB, message will go though a state model when delivered. Acknowledgement modes and transactions are handled by this state model.
9. Now message will get buffered into subscriber client side. There is an internal buffer there will pre-fetch messages so that the subscriber does not always need to poll messages from server.
10. Application at subscriber side will receive message from this buffer and eventually acknowledge.
11. server will remove message (metadata and content) from Cassandra space.
12. If ack did not came for a defined time server will resend the message with "re-delivered" JMS message header.
13. Message will be redelivered for defined number of time as above and eventually will we written into Dead Letter Channel (comes in the next version of WSO2 Message Broker).
14. Message Expiration will be handled properly future.
15. Flow control and message throttling will be implemented in on-coming releases.
WSO2 Message Broker is an actively developing project at WSO2. We will introduce many new features in near feature together with performance enhancements.
Give it a try downloading the product from here.
What's more, all the code is free too :D
Welcome to discuss and support us to develop.
No comments:
Post a Comment