实现这一接口。这允许你独立的扩展或修改两边的处理过程,只要确保它们遵
守同样的接口约束。
•
有些情况下,处理数据的过程会失败。除非数据被持久化 ,否则将造成丢失。
消息队列把数据进行持久化直到它们已经被完全处理 ,通过这一方式规避了
数据丢失风险。在被许多消息队列所采用的"插入-获取-删除"范式中,在把一
个消息从队列中删除之前 ,需要你的处理过程明确的指出该消息已经被处理
完毕,确保你的数据被安全的保存直到你使用完毕。
•
•
因为消息队列解耦了你的处理过程 ,所以增大消息入队和处理的频率是很容
易的;只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩
灵活性 & 峰值处理能力
在访问量剧增的情况下,应用仍然需要继续发挥作用 ,但是这样的突发流量并
不常见;如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨
大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突
发的超负荷的请求而完全崩溃。
•
当体系的一部分组件失效,不会影响到整个系统。消息队列降低了进程间的耦
合度,所以即使一个处理消息的进程挂掉 ,加入队列中的消息仍然可以在系统
恢复后被处理。而这种允许重试或者延后处理请求的能力通常是造就一个略
感不便的用户和一个沮丧透顶的用户之间的区别。
•
消息队列提供的冗余机制保证了消息能被实际的处理 ,只要一个进程读取了
该队列即可。在此基础上,IronMQ 提供了一个"只送达一次"保证。无论有多
少进程在从队列中领取数据,每一个消息只能被处理一次。这之所以成为可能,
是因为获取一个消息只是"预定"了这个消息,暂时把它移出了队列。除非客户
端明确的表示已经处理完了这个消息 ,否则这个消息会被放回队列中去 ,在一
段可配置的时间之后可再次被处理。
缓冲
•
$ " #$
评论0
最新资源