Spring - DeferredResult 异步返回实现

[TOC]

@Edit by Typora

通常我们经常会遇到一些需要实现异步返回的场景，如长轮询、服务器端处理流程较为复杂并且处理时间比较长的情况，这个时候，如果接受>一、概念

MQ的消费模式分两种：push和pull。

所谓push就是服务端主动推送消息给客户端，而pull则是客户端需要主动到服务端取数据。
二、两种模式的优缺点

21 push模式的优缺点

push优点：

服务端主动推送给客户端，及时性很高

push缺点：

1当客户端消费能力远低于服务端生产能力，那么一旦服务端推送大量消息到客户端时，就会导致客户端消息堆积，处理缓慢，甚至服务崩溃。（那么如何解决这个问题呢？需要mq提供流控制，也就是依据客户端消费能力做流控。比如rabbitmq设置Qos，限制消费数量。）

2服务端需要维护每次传输状态，以防消息传递失败进行重试。
22 pull模式的优缺点

pull模式优点：

1客户端可以依据自己的消费能力进行消费

2传输失败时不需要重试，反正数据还在服务端。

pull模式缺点：

1主动到服务端拉取消息。这个拉取消息的间隔需要设置好，不太好设置。间隔太短，对服务器请求压力过大。间隔时间过长，那么必然会造成一部分数据的延迟。（也有一些解决方案，间隔时间指数级增长，5ms，10ms，20ms，40ms，80ms。。。然后再回到5ms，一定程度上解决，但是如果在41ms时来了数据，那么到80ms就有40ms左右的时间延迟。另外在腾讯的CMQ里有一套长轮询的解决方案，就是取数据时要是没有数据可消费，不是直接返回而是连接等待，一直有数据来了再返回）
三、push和pull模式不同适用场景

对于服务端生产消息数据比较大时，而消费端处理比较复杂，消费能力相对较低时，这种情况就适用pull模式。

对于数据实时性要求高的场景，就比较适用与push模式。
四、不同消息中间件支持的模式
另外springboot集成的rabbitmq封装的就是push模式。