请教各位，一个关于云端消息队列的疑惑

[ericgui]

首先，大家使用消息队列的原因有很多，其中一个常见的原因是稍后处理耗时任务，比如发邮件，短信等。这个是很基本的，就不多说了。

那么，这个处理的核心是，快速把任务加入到队列里， 比如保存在 mysql 或者 redis，缩短用户的响应时间，然后快速把 response 返回给用户。

所以，快速，就是关键。毕竟发送邮件需要好几百 ms，写入到 redis 也许 10ms 就够了。

但现在很多云服务推出消息队列的功能，我还没用过。

我猜测，你要调用 api 的，这个 api 肯定是 http 请求啊，这个请求会很耗时吧。这样使用一个云端消息队列有何意义呢？

请指教，谢谢。

澄清一点：

使用云服务的队列服务，肯定是要安装 sdk，这个 sdk 背后肯定是发送 http 请求到云端，如果 enqueue 成功，就有 200 OK 返回来的。

这个猜测是对的吗？

如果是对的，那么，把任务加入到队列这个过程，就很耗时啊。这样做，是不是就没什么太大意义了？

当然了，加入队列之后，可以对失败任务重新执行，这个我懂。

但我想说的是，如果使用云服务的消息队列，调用他们的 api，耗时也很长的。

和在 localhost 或者内网搭建消息队列相比，云服务的消息队列有什么更值得使用的理由？

[yuikns]

1. 快速是指标，执行并只执行一次才是关键。
2. “这个 api 肯定是 http 请求啊”，API==HTTP 这个 assertion 第一次听说。
3. 快慢都是相对的。

[ericgui]

@yuikns 我说的是调用云服务消息队列这个服务的 api，难道不是 http 吗？

[izoabr]

不是走 AMQP 的么？

[yuikns]

首先，https://help.aliyun.com/document_detail/29532.html 可以不
其次，即便是 HTTP，也可以是毫秒级的，再加上批量处理，吞吐量也可以用
最后，这个主要是共享运维开销和 scale out。比如开始某个小团队每天调用几千次，后来增加三四个数量级，都有一个服务帮忙兜底。
理论上和自己准备队列相比，可以少养一帮运维团队，以及出大事可以甩锅分担风险。这是银行总是用 MS，以及很多公司订阅 RH 的原因。不过实际上对方可能就把你交的钱给退了，公司还是会死。

[yuikns]

@yuikns 另外，如果用阿里云的服务，通常就是面向阿里编程，部署的服务往往也在阿里里面，通过内网连接服务，吞吐量和速度还可以。

[yuikns]

另外，要是你每年给阿里几十万或更多，会有专门的 agent 和你联系。你可以选择微信 :) 。打算加机器，不会用，出现各种相关问题都可以在线喊人，对方会帮你联系他们的团队调度。

[ericgui]

@yuikns 早说嘛，“加钱，世界触手可及”，这个我懂

哈哈

感谢高人赐教！

[binux]

返回延迟和吞吐量是两回事，即使延迟会增大，但是吞吐量是可以水平拓展的。

[jadec0der]

如果你用的是云服务的主机，那没道理自己买机器搭 MQ。买云服务的 MQ 在量少的时候更便宜，在量大的时候更稳定，还可以省掉一份运维工资。至于延迟，都在一个机房的，和你的内网速度一样。

[lhx2008]

他们只是帮你开个 VPS，装个 Redis 而已，别想太多了。根本不是中心式的。

[www5070504]

并发量高 延迟也不是那么重要吧 单线程要等上一个请求返回 可以用多线程 协程之类的呗

[ericgui]

@www5070504 有道理

[ericgui]

@jadec0der 有道理

[okwork]

使用过云端消息队列，如果是内网（即和主服务器同区） http 也很稳定，速度基本和自建没差别。如果是跨区，速度其实可以接受，但是有一定几率请求失败（低于千分之一），要 2 次请求。

[ericgui]

@okwork 感谢分享

[flowfire]

没太懂。。。
意思是加到队列里，还没执行就给一个执行成功的回调然后再后面有时间再执行吗
这样真的不会给调用者带来困扰吗。。。