需求背景是博主所在的公司为一个在线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）是一个非常好的解决方案，但是缓存的更新机制需要考虑清楚，否则会成为一个累赘。
该需求主要目的就是将客人的历史订单摒弃掉，而将客人待出行使用的订单信息完整的表现给客人，提升客户的出行体验。
需求下来之后，针对于我这边，机票项目而言，需要做到的不仅仅是将订单信息展现出来，围绕行程这个主题，需要将航班的动态信息也能够动态的展现给客人。
需要解决的几个问题：
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）是一个非常好的解决方案，但是缓存的更新机制需要考虑清楚，否则会成为一个累赘。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/30417691/viewspace-1781589/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
要创造价值
下一篇：
定制jvm，编译属于自己的jdk
请登录后发表评论
登录
全部评论
