More Related Content
Similar to Switch or broker (20)
Switch or broker
- 1. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
Switch or Broker?
A comparison of two models for
reliable AMQP architectures
by Pieter Hintjens, iMatix Corporation
January, 2006
- 2. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
The Classic View
● The "reliable message broker"
● Big, powerful message broker
● Uses high-availability and transactions
● Queues are durable, persistent, heavy
● Consistent with traditional world view
● Strong centralization
● One place to look for all data
● One server to configure, administer, etc.
- 3. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
Reliable message broker
App
App
App
App
Reliable
message
broker
Persistent
queues
- 4. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
What do we get?
● Point-to-point reliability
● When we have successfully passed a message
to the broker, we can be sure it will be deliv-
ered to the recipient.
● If there is a recipient...
● Pretty complex
● Pedantic message delivery
● Distributed transaction processing
● Performance vs. persistence trade-offs
- 5. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
High-availability cluster
App
App
App
App
?
- 6. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
HA reliability challenges
● Guarantee reliability during failover
● Coordination between HA peers
● Transactions between HA peers
● A problem area for most products
● Presumably a solvable problem...
● But even MQ Series occasionally drops mes-
sages
● Broker is now very complex
● ...and HA is visible in the protocol
- 7. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
What about wide-area networks?
?
?
?
- 8. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
WAN reliability challenges
● Only as reliable as weakest link
● Excludes use of untrusted middlemen
● Excludes use of thin "edge" brokers
● Contrary to modern network design
● Requires few, expensive boxes
● Does not scale by adding hardware
● Reliability through complexity?
- 9. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
The iMatix View
● The "asynchronous message switch"
● Cheap, disposable message switches
● Organized into high-availability pairs
● Queues are transient and memory-based
● Consistent with modern world view
● Cheap and simple
● No data to look for
● Minimal configuration and administration
- 10. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
Asynchronous message switch
App
App
App
App
Asynchronous
message
switch
- 11. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
What do we get?
● No reliability in protocol or server
● Messages can be lost en-route
● Very simple
● Trivial message delivery
● No transactions
● Fastest possible performance
● Message loss is very rare
● But...
● Of course, we need full reliability
- 12. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
Reliability over AMS (R/AMS)
● Three main messaging scenarios
● Data distribution (pub-sub)
● Request-response (service request)
● Data distribution can be unreliable
● Data can be resent periodically
● Request-response should be reliable
● This is the classic MQ scenario
- 13. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
R/AMS schema
App
App
App
App
Persistence
Asynchronous
message
switch
- 14. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
R/AMS technique
● Client API provides two messaging APIs
● Data distribution
● Request-response (R-R)
● R/AMS is implemented for R-R only
● Record request in store
● Send request to AMQP server
● Wait for a matching response
● If needed, send the request again
● When response arrives, update store
● After timeout, alert application to failure
- 15. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
R/AMS with a HA cluster
App
App
App
App
Persistence
- 16. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
R/AMS + HA is simple
● No assumption of reliability in network
● HA is limited to peer-coordination
● No message flow between peers
● Proven solution in production use
● Broker remains relatively simple
● HA is invisible in the protocol
● Persistence is also invisible
- 17. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
What about wide-area networks?
- 18. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
R/AMS + WAN is simple
● No assumption of reliability in network
● It does not matter how large network grows
● Reliability is orthogonal to network
● Allows use of untrusted middlemen
● Allows use of thin "edge" servers
● Moves towards "AMQP in every wall-
plug" vision
- 19. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
Why is R/AMS nice?
● Protocol remains simple
● Even simpler than 0.8 release
● Brokers remain simple & light
● No persistence, no transactions, no acks
● R/AMS is (almost) unilateral
● No interoperability burden
● Recipient must detect & discard duplicates
● R/AMS is easy to understand
● Very intuitive, obvious for programmers
- 20. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
R/AMS is fast
● Data distribution can be scaled
● AMS fanout for high volumes & subscribers
● Zero overhead for data distribution
● No centralized storage bottleneck
● Reliable message broker can only run as fast
as its data store
● Asynchronous message switch runs at full
speed
● Persistence cost is spread out across network
- 21. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
Can R/AMS do everything?
● No, it cannot
● R/AMS is a "90%" solution
● Specifically for request-response
● Also solves data distribution optimally
● Does not do file distribution
● Does not do other messaging models
● But... these can be layered on top
● Cannot solve “MQ Series” challenge
- 22. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
R/AMS as a transport layer
● How do we implement file distribution?
● Consider R/AMS as a transport layer
● Use only request-response messaging
● Construct services around R/AMS
● File distribution over R/AMS:
● Through use of "file broker" application
● R/AMS to and from file broker
- 23. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
Vision of AMQP for R/AMS
● Fastest possible transport layer (SCTP)
● Removal of all reliability from protocol
● New "thin" content class
● No persistent messages
● No transactions
● No acknowledgments
● Stripped-down message properties
- 24. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
AMQP evolution for R/AMS
● Orthogonal transport protocols
● Ability to choose between TCP/IP, SCTP
● Central wiring management layer
● Exchanges, queues, bindings
● Orthogonal content classes
● Basic content class, thin content class
● No content class interoperability
- 25. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
Switch vs Broker
Switch
● Simple protocol
● Simple server
● Edge storage
● Intelligent API
● WAN friendly
● Silicon friendly
● Unconventional
Broker
● Complex protocol
● Complex server
● Central storage
● Simple client API
● WAN hostile
● Silicon hostile
● Conventional
- 26. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
Conclusions
● R/AMS has significant advantages
● Simply, cheap, flexible
● Compatible with AMQP->hardware strategy
● Elegant solution for HA & WAN
● Reliable message broker is outdated
● Solves problems of the past
● R/AMS is future-proof design
● Cheap, scalable, simple
● Forces standard messaging patterns
- 27. Copyright © 2006-2007 iMatix Corporation
CreativeCommons Attribution-Share Alike 2.5
Thank you
● For more information please contact the
author at ph@imatix.com.