什么是轮询
轮询一开始应该是CPU调度算法里的概念，通俗来说就是CPU每隔一段时间都问下需不需要服务。这个概念延伸到web服务中也类似，前端每隔一段时间去向服务器请求信息。
为什么需要轮询
那为什么要用轮询呢？其实这里说的也算是轮询的优点。
当前端每隔一段时间都要确认一些信息是否有变化时，就需要用到轮询。毕竟前端要获取到服务器状态变更，要么主动拉、要么让服务器推。主动拉的情况，又分为用户行为触发和我们定时去拉，要想信息尽可能新，肯定不能只等用户的行为去触发，也需要我们每隔一段时间去拉。所以我们就得出轮询第一个优点——信息相对较新。
除此之外，轮询里面我们还可以把这个软件多个模块都需要的信息请求都封装到一次请求，这样减少了前端的请求数量，可以减少前端多次网络请求的资源耗费，可能也可以减轻服务器负担。第二个优点——减少网络请求数量。
服务器主动推？
上面提到了服务器主动推的请求，网页端能做到让服务器主动推吗？不都是HTTP请求吗？HTTP请求其实也有多种方法做到主动推：
- 前端以更小的时间间隔去请求，看上去就想服务器主动推一样及时，但耗费资源多
- HTTP/2其实也支持主动推，需要服务器那边进行额外的设置，当收到某个请求时，把其他资源也一起返回，但这种要改配置，改完得重启服务，把业务逻辑与服务器配置放一起搞，看上去就很不妥，在实际开发中，一般这是分离的，你控制不到服务器配置。还有一个办法，在响应头加上Link命令，服务器就会带上对应资源。不过不管怎么说，这还不是真正的主动推，仍然要把响应紧跟在请求后，只不过是可以放多几个响应
http://www.ruanyifeng.com/blog/2018/03/http2_server_push.html
- 基于HTTP的websocket协议，建立链接后，服务器可随时推，这就是真正的主动推了，但这也有兼容性问题，有些新的api在某些版本的浏览器不支持。而且这也需要后台进行改动，支持新协议、数据一更新就推送给所有监听这个key的后台，这里的后台开销相比传统的请求-响应会不会多很多？看上去当用户量大，当依赖关系一多，内存耗费就会多很多。
轮询的缺点
- 信息只是相对新，但不是绝对新。比如用户删除、添加、更新某个信息时，如果你这个信息状态的更新是依赖轮询接口的，你不可能在更新成功后，立即调用轮询接口，因为前面说过轮询接口可能会封装很多模块的请求，立即更新的耗费是很大的，可能很多信息都不是必要的。我这里的做法是，前端在确认信息更新成功后，先显示假数据给用户（前端构造的更新后的数据）。前提是后端告知前端信息的确更新成功，且下次轮询一定返回了新数据，这个后端还是应该要保证到的。当然，你也可以要求后端同学给封装一个新的接口，单独给你返回你需要的数据，但相比写假数据，哪个开发成本低、维护成本低其实一目了然。
总结
轮询获取数据在某些情景下是必要的，但可能因为信息更新的不及时，需要做一些兼容逻辑。