最近在review自己的数据同步代码,不过在看自己通过消息队列取消息的时候意识到一个问题,由于数据同步的架构是将源数据处理后放入消息队列中,然后通过轮询的方式取出消息,存入目的数据库。但是,由于现在是死循环取消息,若是不存在消息的时候,会休息1分钟的时间。但是这种模式会重复发送HTTP请求,造成资源的浪费。所以这时候想到了长轮询的方式,可以发现自己对于长轮询和短轮询的理解并不是很深刻,所以,给自己画画重点,小板凳坐好~
什么是长连接和短连接
其实网上解释都大同小异,但是也有很多文章看着让我产生误解。不过有一篇文章黑字粗体的提醒画重点的解释,在这里复述一遍:
- HTTP协议是基于请求/响应模式的,因此只要服务端给了响应,本次HTTP连接就结束了,换而言之,HTTP请求就没有长连接的说法,所以就没有短连接了。
- 网上所说的HTTP分为长连接和短连接,其本质是TCP连接。由于TCP连接是一个双向的通道,它是可以保持一段时间不关闭的,所以TCP连接才有真正的长连接和短连接这一说法。
上面画下重点~
然后,具体说明是长连接和短连接呢?
- 短连接: 每次HTTP请求都会建立TCP连接,管理容易。
- 长连接: 只需要建立一次TCP连接,以后的HTTP请求重复使用同一个TCP连接,可是不易于管理。
长短连接的应用场景:
- 一般长连接主要是应用于实时性高的场景。
- 类似于WEB网站的HTTP服务一般都是使用短连接,为了方便于资源的回收。
什么是长轮询和短轮询
上面介绍了长短连接,但是上面是长短轮询呢?
- 短轮询:重复发送HTTP请求,一般是死循环,我就是这么做的。
- 长轮询:CLIENT 和 SERVER 端一直建立着连接,等待目标响应。
解决方案
由于项目中消息队列使用的是AWS的SQS,SQS中拥有用作与长轮询的方法--ReceiveMessage;当我们将WaitTimeSeconds设置为0的时候,则会变为短轮询。
结语
无论是短轮询还是长轮询,可以根据自己的需求来处理,毕竟长轮询的方法并不是很好的去实现。SQS拥有作为长轮询的方法,但是,同时可以作为消息队列的RabbitMQ和Redis。编码可能会花费一定的时间,所以,按需解决吧~