一个消息队列应该具有的功能

宋鑫    2015-06-29

本文:一个消息队列应该具有的功能,原创于:宋鑫的官方网站,转载请注明出处,谢谢。

1.持久化(备份,还原)

2.事务,消息传递顺序

3.协议支持

4.集群

5.支持Ajax?不都是HTTP,JSON?

6.事件触发器

7.单点

8.发布订阅

9.消息优先级

10.消息路由(向多个list发送)

保证每条消息至少可被消费一次(at-least-once)。

数据冗余 Qos控制 在Message Data Server层针对每个队列都设置有单独的QoS控制,针对该队列的访问请求量不得超过其QoS上限值。

通常有许多选项作为消息传递的精确语义,包括:

  • 持久性 – 消息可能被保存在内存中,写入到磁盘,或甚至提交到DBMS,如果可靠性要求表明了更加资源密集型的解决方案。
  • 安全策略 – 哪些应用程序可以访问这些消息?
  • 消息清理策略 – 队列或消息应当有存活时间
  • 消息过滤 – 一些系统支持过滤数据,因此,订阅者只能看到匹配预定义兴趣标准的消息
  • 交付策略 – 我们是不是应该保证消息传递至少一次,或不超过一次?
  • 路由策略 – 在一个有许多队列服务器的系统中,哪些服务器应该收到一条消息或一队列的消息?
  • 批量策略 – 是否立即将消息传送?还是说系统应该稍等,并尝试一次传递多条消息?
  • 排队标准 – 什么时候应当考虑消息“入队”?什么时候队列有了?或者,何时它被转发到至少一个远程队列?或所有队列?
  • 已收通知 – 发布者可能需要知道,何时部分或全部订阅者收到了消息。

其他异步的例子存在于事件通知系统和发布/订阅系统。

  • 一个应用程序可能需要通知别人事件发生了,但并不需要等待响应。
  • 在发布/订阅系统中,应用程序“发布”信息,任意数量的客户端阅读。

在上面的例子中,让信息发送者等待是不合理的,例如,如果其中一个接收方已崩溃。 应用程序不必仅作同步或异步 。交互的应用程序可能需要立即回应部分请求(如告诉客户,销售请求已被接受,正在处理库存调货预约),但是也许队列中的其他部分(如完成费用计算,将数据转发到中心记账系统,还有调用各种其它服务)会过一会才完成。 在这些情况下,用一个子系统进行消息排队(或可选择广播消息系统)可有助于提高整体系统的行为。


文章有用?分享给你的朋友们,让更多的人受益


更多精彩干货,尽请关注我的个人微信公众号
wechat