轮训数据库,WebSocket的前身方案：轮训API设计思路

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

轮训接口：

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

轮训优缺点：

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

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

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

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

多个轮训怎么办？

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

合并原则：多个业务之间互不干扰！

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

合并思路：

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

异常处理：

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

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

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