接口调用数据的常用方案

最近很想总结一下接口调用的知识点，因为现在前后分离是趋势，一个程序员前后兼顾不仅不专业，效率低，也不利于维护。

说到调接口，无非就是前端请求，后台返回数据。所以今天首先要谈的是获取数据的三种方案。

三种方案

方案一： 读取数据库

PS:直接读取数据库，取出数据库封装好，再返回。

方案二：数据库与缓存并用

PS: 这里说的缓存不是浏览器里的缓存，而是redis或memachche等缓存技术。当收到请求时，先判断是否已加入缓存，如果已经有了缓存，直接读取缓存返回就OK了。如果没有，就跟方案一一样查询数据库，封装数据，然后加入到缓存里，方便下次使用。

方案三： 数据库加缓存加定时任务

ps: 与第二种的区别是，提前在服务器执行一条持久的脚本，把数据从数据库取好，封装好，加到缓存里。这样接到请求时就可以直接获取了。

方案对比

为了更直观一些，我画了个简单的流程图做对比。

缓存与不缓存相比

通过图中可以看出，三种方案最快都是一步返回。但是由于缓存是放在内存的，数据库是放在硬盘的。所以缓存数据肯定要快很多。并且封装数据会有逻辑处理，也会有资源消耗。因此方案一与后两种比起来，肯定是速度上比不过了。相当于空间换时间。

方案一与方案三

因为有定时任务在持久的把数据放到缓存里。所以方案三肯定效率高，而且方案三的定时任务可能是在晚上或者中午等访问量低的时候进行，这就极大的缓解了服务器压力。但是缺点也很明显，就是更新时效差。不管定时任务执行频率多高，也不是即时的。比如说我要获取库存剩余量。方案三是10秒更新一次缓存，那么返回的数据就不一定对了。 

方案一与方案二

方案一与方案二的数据都是最新的（假设有即时更新缓存），就不用考虑信息更新的时效性了。那么这两者的区别在哪呢。就在那个逻辑判断的地方，如果直接返回缓存数据，那么方案二效率高。如果每次请求都要查询再缓存，那么还不如方案一。

三种方案的应用场景

方案一

没得说，这种直接请求数据库的方案。适用于数据少，处理快，并且对信息时效要求严的场景。

方案二

这种方案适合某些更新不太频繁，胆却请求比较频繁的数据。比如banner图，菜单等内容。

方案三

适合逻辑处理时间长，且对信息更新时效不严格的数据。比如统计数据类。可以把定时任务每天晚上执行一次。就像支付宝的年帐单，银行系统的回款，都不是马上出来的。相当于时间换空间。

总结

不管哪种方案，目的都是为了节省资源并且不影响客户体验，也就是最大化的合理使用资源。有钱了随便砸服务器。没钱的话，就得多想招儿了。相信会有更多的大牛分享更多的优秀方案。