应用场景

异步处理

消息队列的一的特点之一就是异步处理,这就决定了对于实时返回的信息就没办法使用消息队列。经常使用的消息队列比如发送邮箱验证、短信验证。因为一般的逻辑是串行方式,消息队列采用的是并行的模式。

串行方式:串行方式基本上是在编程中最常见的方式了,也就是完全按照流程做事。举个例子,我早上起床后,先刷牙(5分钟),然后再吃早饭(20分钟),我使用的时间是20+5分钟

并行方式:并行方式也可以是算是异步处理,这样处理的效率会更快。举个例子,我晚上下班回家,我一边泡脚(5分钟),泡脚的同时,我还顺便吃了晚饭(20分钟),这个过程我花了20分钟,因为泡脚和吃饭是同时进行的。

消息队列实现方式:

应用解耦

用户在下单之后,账单系统把账单信息发给库存系统,库存系统进行发货。但是如果库存系统某次访问不了,可能会导致订单失败。

消息队列形式:

流量削峰

很多网站的访问瓶颈大多数都是出现在数据库上面,如果某个接口出现访问量太大,必然会增加压力。或者某个接口调用第三方API,很容易出现数据丢失的状况,这种情景可以使用消息队列。

阿里云消息队列和消息服务

消息服务和消息队列的对比

对比项目 消息服务(MNS,原MQS) 消息队列(ONS)
queue模型 Yes Yes
官方SDK Java,C++,Python,C#,PHP,Node.js(非官方),Golang(非官方) Java,C/C++,C#,PHP(http),Python(http)
支持JMS Yes No
协议支持 HTTP TCP,HTTP,MQTT
延时消息 Yes Yes
定时消息 No Yes
事务消息 Yes Yes
消息Batch操作 Yes No
保证消息至少消费一次 Yes Yes
支持RAM访问控制 Yes Yes
消息优先级 Yes No
消息推拉模式 Pull,Push Pull,Push
消息轨迹追踪 Yes Yes
服务端消息过滤 Yes Yes
qps性能 默认5000 默认5000
数据可靠性 99.99999999% 99.99%
数据堆积 不限 不限
服务可用性 99.9% 99.9%

API对比

消息服务API地址

消息队列http API地址

消息服务的接口相对齐全一些,支持的类型也相对齐全,topic和queue两种形式。不过开发起来比较费劲,因为涉及到签名的过程,在接收的时候,为了保证消息的安全性,需要进行验签,验签通过或才能进行逻辑处理。

消息队列的http接口比较简单,但是消息的重复率较高,达到了20%,官网提供的demo比较简单,只有发送,消费和删除,需要进程循环接收消息,比较消耗资源open API接口齐全,但是暂时没有支持PHP的SDK,综合考虑下选择了消息服务。

发表评论

电子邮件地址不会被公开。 必填项已用*标注