我创建了一个REST API – 简而言之,我的客户端点击了一个特定的URL,然后她获得了一个JSON响应.
在内部,当URL被命中时,相当复杂的过程开始,并且在使用微服务架构时涉及各种服务.
我正在观察一些性能瓶颈,并决定切换到消息队列系统.现在的想法是,一旦用户点击URL,就会在内部消息队列上发布请求,等待它被消费.此消费者将处理并发布回队列,这将发生很多次,直到最后,为用户提供服务的同一节点将收到要传递给用户的已处理响应.
现在正在使用异步“即发即忘”模式.但我的问题是,一旦处理结果返回并且没有阻塞(即它可以处理多个请求直到收到响应),为特定人员服务的节点如何能够记住它正在服务的人？如果它有任何区别,我的堆栈看起来有点像：TomCat,Spring,Kubernetes和RabbitMQ.
总之,请求节点(其作业是推送队列中的项目)如何与请求JSON响应的客户端保持开放连接(即客户端正在等待JSON响应)并接收正确客户端的数据？
如果无法更改客户端行为,则必须保持会话处于打开状态,直到请求未完全处理为止.这可以通过使用工作池(期货/协程,线程或进程)来实现,其中每个工作者为给定请求保持会话开放.
这种方法有一些缺点,我会把它作为最后的手段.首先,您只能提供与池大小成比例的有限数量的并发请求.最后,当您的处理在队列后面时,您的前端将无法估计任务完成所需的时间.这意味着您将不得不处理容易失败的持久会话(如果用户放弃了会怎样？).
如果可以更改客户端行为,则最常用的方法是使用完全异步流.当客户端发起请求时,它将被置于队列中并返回任务标识符.客户端可以使用给定的TaskId轮询状态更新.每次客户端请求有关任务的更新时,您只需检查它是否已完成并相应地做出响应.任务仍在进行时的常见模式是让前端在再次尝试之前返回到客户端估计的时间量.这允许您的服务器控制客户端轮询的频率.如果您的架构支持它,您可以加倍努力并提供有关进度的信息.
任务正在进行时的示例响应：
{"status": "in_progress","retry_after_seconds": 30,"progress": "30%"}
更复杂但更优雅的解决方案包括使用HTTP回调.简而言之,当客户端请求新任务时,它提供了一个元组(URL,Method),服务器可以使用它来表示处理完成.然后它等待服务器将信号发送到给定的URL.你可以看到一个更好的解释here.在大多数情况下,这个解决方案是矫枉过正.但我认为值得一提.
