Message Queue vs. Web Services?
2016-05-09 09:36
405 查看
From stackoverflow.com
When you use a web service you have a client and a server:
If the server fails the client must take responsibility to handle the error.
When the server is working again the client is responsible of resending it.
If the server gives a response to the call and the client fails the operation is lost.
You don't have contention, that is: if million of clients call a web service on one server in a second, most probably your server will go down.
You can expect an immediate response from the server, but you can handle asynchronous calls too.
When you use a message queue like RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo you expect different and more fault tolerant results:
If the server fails, the queue persist the message (optionally, even if the machine shutdown).
When the server is working again, it receives the pending message.
If the server gives a response to the call and the client fails, if the client didn't acknowledge the response the message is persisted.
You have contention, you can decide how many requests are handled by the server (call it worker instead).
You don't expect an immediate synchronous response, but you can implement/simulate synchronous calls.
Message Queues has a lot more features but this is some rule of thumb to decide if you want to handle error conditions yourself or leave them to the message queue.
When you use a web service you have a client and a server:
If the server fails the client must take responsibility to handle the error.
When the server is working again the client is responsible of resending it.
If the server gives a response to the call and the client fails the operation is lost.
You don't have contention, that is: if million of clients call a web service on one server in a second, most probably your server will go down.
You can expect an immediate response from the server, but you can handle asynchronous calls too.
When you use a message queue like RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo you expect different and more fault tolerant results:
If the server fails, the queue persist the message (optionally, even if the machine shutdown).
When the server is working again, it receives the pending message.
If the server gives a response to the call and the client fails, if the client didn't acknowledge the response the message is persisted.
You have contention, you can decide how many requests are handled by the server (call it worker instead).
You don't expect an immediate synchronous response, but you can implement/simulate synchronous calls.
Message Queues has a lot more features but this is some rule of thumb to decide if you want to handle error conditions yourself or leave them to the message queue.
相关文章推荐
- osg中的事件适配器GUIEventAdapter的含义
- UIViewController的生命周期
- uva 3485 Optimal Array Multiplication Sequence
- paper:synthesizable finit state machine design techniques using the new systemverilog 3.0 enhancements之fsm summary
- BlueTooth聊天软件(支持表情和语音)
- Implement Queue using Stacks
- paper:synthesizable finit state machine design techniques using the new systemverilog 3.0 enhancements之全0/1/z/x的SV写法
- hdu1423Greatest Common Increasing Subsequence(最长公共递增子序列)
- paper:synthesizable finit state machine design techniques using the new systemverilog 3.0 enhancements之enhanced coding styles
- xcodebuild
- build_native.py 未找到工程 xxx\proj.android' 可用的 Android 目标平台。 Android 目标平台版本应该大于或等于 20
- mcc、mbuild和mex命令详解
- Top K Frequent Elements=-leetcode
- DuiLib学习笔记(二) 扩展CScrollbar属性
- StringBuilder和Stringbuffer 对比
- AVQueue的一些总结
- MAX Common SubSequence
- 子线程为什么不能更新UI
- 关于UITableViewCell (xib) 自适应高度的问题
- iOS xib或storyborad中给UI控件设置边框颜色