【问题标题】:Understanding why you would want to process Message Queues at a future time了解您为什么要在未来处理消息队列
【发布时间】:2020-06-06 14:23:57
【问题描述】:
所以我试图了解队列解决了哪些实际问题。通过阅读谷歌的所有信息,我得到了高水平。
所以我正在研究 A 公司的架构,他们有不同的作业队列用例,例如
- 聊天消息
- 文件转换
- 正在搜索
- 繁重的 sql 查询
为什么要稍后处理?
这是我的最佳猜测...
- 假设我有一个可以一次处理 10 个“事物”的应用程序。
- 然后我的应用程序会最大化其处理能力。
- 收到了第 11 个请求,因此应用将其放入队列中以供以后处理
假设这是一个有效的用例,添加更多服务器来处理更多“事物”难道不是有意义的吗?是不是因为添加更多服务器比使用 Queue 并牺牲一点响应时间成本更高?
鉴于我的用例示例,队列还可以解决哪些其他问题?
【问题讨论】:
标签:
redis
rabbitmq
distributed-computing
amazon-sqs
amazon-swf
【解决方案1】:
你有没有在银行忙的时候排队过?你会在队列中等待。
“但是,”你可以说,“增加更多的员工来处理更多的客户难道没有意义吗?是因为增加更多的员工比雇佣一个队列和牺牲一点响应时间成本更高吗?”
那是正确的。根据每天到达的客户高峰数量来为银行配备人员可能会非常昂贵。低于此级别的员工并让一些客户排队等候更便宜。
此外,每天的客户数量并非 100% 可预测。队列允许过多的需求在不破坏系统的情况下等待。
队列启用解耦。
例如,想象一下客户购买商品的在线商店。他们选择商品,提供信用卡号并点击“购买”。如果信用卡被拒绝,在线商店可以立即提示他们重新输入号码。此交互必须在客户仍在线时立即进行。
但是,在生成发票、将记录添加到会计系统和从货架上提取库存时,无需让客户等待。这可以与订购流程分离。一个很好的方法是将订单推送到队列中,该队列可以由下一个系统处理。
如果“下一个系统”此时恰好处于离线状态,则没有理由取消整个销售。当“下一个系统”重新上线时,可以处理交易。这比仅仅因为一个组件(不是立即需要)发生故障而使整个过程失败要好得多。
底线:队列非常好。它们可以更好地处理故障。它们使事情更有弹性(只需等待几分钟,然后再试一次!)。当进程与队列架构兼容时,应始终使用它们。
【解决方案2】:
让我们做场景
没有队列的场景 1:
- 您请求端点 /blabla/do-eveything/
-
这个请求做
从非常慢的 FTP 下载图像
例如 1.5 秒(可以出错,重试吗?添加 +X 秒)
将图像附加到电子邮件
发送电子邮件(3 秒)
例如 1 秒(可以出错,重试吗?添加 +X 秒)
收到确认 > 商店确认到第三家公司跟踪的东西
例如 1.5(可以出错,重试吗?添加 +X 秒)
在跟踪确认时,从另一家第三方公司更新您的数据以用于大数据
例如 2 秒(可以出错,重试吗?添加 +X 秒)
...你明白了
在一切都失败时返回响应,例如 11 秒后(这会变慢)或更长时间或超时
最终用户说 20 年前互联网速度更快,也许我需要改变我的互联网连接或改变我的 16 个线程
场景 2 尽可能排队:
- 您请求端点 /blabla/do-eveything/
-
这个请求做
队列作业“DO_EVERYTHING”
例如 0.02 秒
在 0.250 秒内返回响应
最终用户说是网站/应用程序太快,我可以保持我的 56K 互联网连接
在队列/事件系统上,一项失败的作业可以稍后重试,而不会影响最终用户
您可以暂停工作,在原始消息后添加无限数量的任务/步骤
更好的容错性
使用队列将为您提供更好的微/纳米服务架构,更好的测试,因为您可以测试单个作业,而不是一个可以做所有事情的完整控制器......
是的,也许是工作多,多思考,但假期结束时不需要考虑工作