Reliable System Integration and Scaling with WSO2 Message Broker
1 like1,035 views
To view the recording of this webinar please use the below URL: http://wso2.com/library/webinars/2016/03/reliable-system-integration-and-scaling-with-wso2-message-broker/ Messaging has been used widely by enterprise architects to reliably integrate and scale systems. Commonly used messaging patterns include distributed queues/topics and dead letter channels with varied quality of service levels. When adopting a message broker, architects not only need to look at features but also at the deployment and maintenance complexity, internal architecture and surrounding concepts. This session will discuss the internal architecture of WSO2 Message Broker (WSO2 MB) 3.1 and focus on Improved performance with optimized message dissemination model Ease of use and reliability with a message persistence layer backed by RDBMS Simplified deployment layout and less operational complexity with Hazelcast based clustering scheme New features of WSO2 MB 3.1
![[@NaukriEngineering] Messaging Queues](https://cdn.slidesharecdn.com/ss_thumbnails/queueprocessing-161111064335-thumbnail.jpg?width=560&fit=bounds)
Ad
More Related Content
What's hot (19)
Similar to Reliable System Integration and Scaling with WSO2 Message Broker (20)
Ad
More from WSO2 (20)
![[Roundtable] Choreo - The AI-Native Internal Developer Platform as a Service](https://cdn.slidesharecdn.com/ss_thumbnails/choreo-deck-250328074645-511dded7-thumbnail.jpg?width=560&fit=bounds)
Ad
Recently uploaded (20)
Reliable System Integration and Scaling with WSO2 Message Broker
- 1. Reliable System Integration and Scaling with WSO2 Message Broker Ramith Jayasinghe Senior Technical Lead WSO2
- 2. Messaging Models/Concepts • RPC style - Request/Response, Synchronous, Non-persistent - e.g. Web Services, Thrift, REST • Point to Point (Queues) - A message is delivered only once to a single consumer • Publish/Subscribe (Topics) - Broadcast a message to all the subscribers
- 3. Messaging Models/Concepts • Durable Subscriptions - Same as topic subscriptions - Subscriber offline - Messages get queued - Subscriber back online - Messages get delivered - Un-subscription needed to remove queuing
- 4. Messaging Models/Concepts • Transactional ( send/consume -> rollback, reject, commit) • Guaranteed Delivery, QOS ( MQTT, AMQP), Persistence • Dead letter channel • Hierarchical topics - Games.FootBall.UK, Games.FootBall.USA, - Games.Cricket.SriLanka, Games.Football.UK
- 5. Distributed Queues • Provides strict or best effort support for inorder delivery • There are no guarantee about the global order seen across subscribers
- 6. WSO2 Message Broker • Design Objectives: - Higher performance (by not routing messages over the network multiple hops) - High availability and fault tolerance. - Leaner deployment layout ( and clustering story) • v 3.0.0 - Significant architectural changes. • v 3.1.0 - Latest version - Minor improvements - PostgreSQL support
- 7. WSO2 MB v 3.x.x Design Objectives • Avoid message routing over the network multiple times. • Use storage to share messages between nodes Allow database to scale as separate layer. • Use distributed coordination to control the behavior (i.e. Hazelcast)
- 8. WSO2 MB v 3.x.x Design Objectives • Content and metadata are saved separately into a database shared between all cluster nodes. • All nodes knows about all subscribers ( - via Hazelcast coordination) • Each node will logically divide messages into group (known as Slots).
- 9. WSO2 Message Broker Design More information about disruptor: https://lmax-exchange.github.io/disruptor/
- 10. WSO2 Message Broker Design - Inbound All events coming to broker are added to ‘inbound disruptor’ such as: ● Messages ● Message acknowledgements ● Create/Delete queues topics ● Subscribe/Unsubscribe ● UI Events Inbound disruptor: ● Sequence inbound events ( - disruptor behaviour) ● Generate internal Message IDs ( length = java - long) ● persist/delete messages ● Execute other control functions. Note: #1. Internal message Ids are time based. Therefore, MB cluster needs to be time synced. #2. Inbound path can be tuned for best performance ( broker.xml).
- 11. WSO2 Message Broker Design - Outbound All message going out of broker are added to ‘outbound disruptor” Slot Delivery Worker pool: 1) Connects to coordinator node ( - get messages to deliver) 2) Fetches metadata of messages and add to outbound disruptor Outbound disruptor: 1) Fetch message payloads (in parallel) 2) Forward fetched messages to transport. Note: Slot delivery thread pool and outbound disruptors can be tuned for best performance (broker.xml).
- 12. WSO2 Message Broker Design - Distributed Queues • Content and metadata are saved separately into a database shared between all cluster nodes. • All nodes knows about all subscribers ( - via Hazelcast coordination) • Each node will logically divide messages into group (known as Slots).
- 13. WSO2 Message Broker Design - Distributed Queues • Cluster elects a leader ( known as Coordinator); Usual the first node to start in cluster. • Coordinator keeps track of all the slots available (via Hazelcast) • Nodes with subscriptions acquire a slot (from Coordinator) and deliver them to subscribers.
- 14. WSO2 Message Broker v 3.1.0 - Features ● Message Queuing Telemetry Transport (MQTT) ● Shared Subscriptions ● RDBMS based message store (MSSQL, Oracle, H2, MySQL, PostgreSQL) ● Real time statistics/graphs (on each server) via carbon-matrices ● Improved internals
- 15. MQTT support in WSO2 MB • Lightweight, pub-sub protocol designed for IOT use-cases. • Hierarchical topic structures and wildcard subscriptions • All quality of service levels and retained messages
- 16. Shared Durable Subscriptions Extension to JMS 1.1, until JMS 2.0 support is released. Purpose: Ability to load balance. broker.xml: <allowSharedTopicSubscriptions>true</allowSharedTopicSubscriptions>
- 17. Back pressure / Flow Control - Inbound • Every system has its limits. • Safeguards server from sudden bursts of message loads • Flow control based on: – Total inbound events – Inbound events per connection/channel – Global error conditions (e.g. offline databases) <flowControl> <!-- This is the global buffer limits which enable/disable the flow control globally --> <global> <lowLimit>800</lowLimit> <highLimit>8000</highLimit> </global> <!-- This is the channel specific buffer limits which enable/disable the flow control locally. --> <bufferBased> <lowLimit>100</lowLimit> <highLimit>1000</highLimit> </bufferBased> </flowControl>
- 18. General Improvements • Real time statistics/graphs – Quickly figure out bottlenecks in a production deployments. – Database read/write latencies – Inbound/Outbound event rates – Number of Connections/Channels etc. • Performance Improvements – Disruptor based thread model – Improved internals ( topic matching, slot based delivery, caching)
- 19. Improvements in MB v 3.1.0 • Support for PostgreSQL as the message store. • LZ4 Compression for storage – Dramatic performance improvement large/text oriented message payloads • Forcefully disconnect Consumers – If a subscriber misbehaves, admin can disconnect the client forcefully.
- 20. Roadmap • Support for AMQP 1.0 and JMS 2.0 • Move to Carbon 5 • Improved GUI • Improvements to Storage Scheme • Performance improvements. • Websockets + Stomp
- 21. What makes WSO2 MB different ● Simplified clustering story (- Queues/Topics) - Users don’t have to worry about how brokers transmit messages in the cluster. ● RDBMS for persistence →Easy to manage and use ● Simpler Cluster deployments → Minimum deployment effort + maintenance.
- 22. Use Case – Guaranteed Delivery with WSO2 ESB • Guarantees In-Order Delivery. • Throttle messages ( for slow consumers/systems). • Ensure reliable messaging
- 23. An Extended Use case - Where MB fits
- 24. CONTACT US !