WebSocket的前身方案:轮训API设计思路

[软件开发] 季雨林 2019/10/17 13:22:01

开发socket已经有几年,随着socket这种“主动”触发的优势体现,很多web端也有了这类实时更新需求,这个需求在没有WebSocket的情况下并非实现不了,只不过是需要使用定时器反复“刷新结果”,也就是轮训。WebSocket也就在这种长连接需求下应运而生,然而,新生事物总是需要一点时间才能被完全认可并使用。所以本文讲讲WebSocket的前身方法:轮训接口的设计。


轮训接口:

顾名思义就是普通的接口,但是多了“轮训”特点,比如本站初期公布的“车辆跟踪”页面,就是10秒送从服务器端拉取一下新的数据位置。


轮训优缺点:

优点:开发简单,开发过普通接口的人,也都会开发轮训接口

缺点:“被动”触发,只有到了刷新时间才会去拿到新结果,因此更新相当于不是实时的。

说到这一点,我可以额外分享下我“抢小米手机”的经历:再倒计时秒杀的web界面,我把页面开多个,然后选择一个倒计时时间最短的留着,接下来使用这个页面进行“抢购”操作,这样一来很显然我要领先他人0-1秒的时间优势!

还有个缺点:请求太频繁,会导致连接数过大。虽然接口访问是短连接,但是一个连接端口,在使用后的一段时间(大概是1分钟)是不会被复用的,因此服务器端会随着连接数增加,有运行变慢的表现。


多个轮训怎么办?

有些业务需要“多”轮训,因为他有多个业务。这个时候,选择建立多组轮训并非不可取,只是轮训的缺点会进一步暴露出来。因此在这个情况提倡“轮训业务合并”!

合并原则:多个业务之间互不干扰!

坚决不能因为某个判断不符合逻辑,就直接返回或者抛出异常。

合并思路:

根据http请求的一来一回特点,需要分别梳理“上行业务”和“下行业务”。

异常处理:

该有的异常还得有,只是返回值的结构,需要针对性的做不同类别设计。最粗糙的做法是,使用json数组方式返回一个“错误集合”,分别提示那些业务执行结果的成与败!

读取内容要进行缓存过滤:

对于轮训业务中的查询业务,显然不是需要每次都“读取数据库”,所以呢,在后端数据不发生变动的情况下,应当使用缓存标识进行过滤,让大量的数据库访问在内存里完成!


原文地址: https://www.opengps.cn/Blog/View.aspx?id=497 文章的更新编辑依此链接为准。欢迎关注源站原创文章!

评论

暂无评论!

发表评论:

用于接收作者回复信息
点击更换验证码 - openGPS提示