從大學開始關注博客園，到工作之后注冊了博客園賬號，直至今日終於能夠靜下心來將自己個人的所學，所得，所悟能夠分享出來與大家分享，好開心~
言歸正傳，需求背景是博主所在的公司為一個在線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）是一個非常好的解決方案，但是緩存的更新機制需要考慮清楚，否則會成為一個累贅