关于一个天天请求50W次接口的设计实现过程

　　从大学开始关注博客园，到工做以后注册了博客园帐号，直至今日终于可以静下心来将本身我的的所学，所得，所悟可以分享出来与你们分享，好开心~

　　言归正传，需求背景是博主所在的公司为一个在线OTA公司，客户端上各个项目（酒店，机票，景区，出境之类）的订单列表接口融合在一块儿以后对客户的查看订单很是不方便，并且列表信息相对于客人来讲过于冗余，可是列表接口又不能缺乏，为了推进客户体验，将当前待使用的行程信息可以更加完整的展示给客户，因而推进了行程助手的需求。

　　该需求主要目的就是将客人的历史订单摒弃掉，而将客人待出行使用的订单信息完整的表现给客人，提高客户的出行体验。

　　需求下来以后，针对于我这边，机票项目而言，须要作到的不单单是将订单信息展示出来，围绕行程这个主题，须要将航班的动态信息也可以动态的展示给客人。

　　须要解决的几个问题：

　　1.航空公司信息，机场信息为静态信息，查询数据库过于浪费

　　2.查询的信息较多，须要优化查询sql

　　3.动态信息因为不和订单相关联的表在一个数据库中，而跨库联查不可取，须要重点解决

　　问题思考过程：

　　1.航空公司和机场信息这种静态信息，查库是明显耗时耗力的，航空公司的信息因为比较少，表内的记录在五十条左右，所以采用单例模式，将信息加载在内存中直接调取便可。机场信息因为存在的记录在五百条左右，并且每条信息的维度不少，所以采用了Redis这种支持List的存储系统，提升性能。

　　2.查询SQL，涉及到了5张业务逻辑表的查询，与DBA确认查询索引，提升查询语句的性能。

　　3.航班动态信息从供应商处推送得到会落地到本地库中，因为更新比较频繁，并且跨库查询太耗时，所以数据库这一块已经暂时放弃了，

　　处理动态信息方面，博主使用了MC(Memcached)+JOB(不明白的同窗百度Quartz调度系统)搭建了更新航班动态信息的缓存框架，

　　主要思路是，使用JOB捞取供应商落地的信息，根据推送时间，每60秒捞取一次当前最近90秒的更新信息，同时将订单相关的一些固定信息也一并组装，同步到MC中。

　　在接口内部进行查询的时候优先进入MC中查询信息，当MC中查询不到时再去库里捞取，拼装返回

　　收获：

　　1.逻辑上的思考须要缜密，将有可能碰到的问题列出来，逐一的思考解决方案就会找到胜利的钥匙

　　2.在数据库发生瓶颈，难以达到预期效果时，巧妙的去运用缓存（单键类，Redis，MC）是一个很是好的解决方案，可是缓存的更新机制须要考虑清楚，不然会成为一个累赘