關於一個天天請求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）是一個很是好的解決方案，可是緩存的更新機制須要考慮清楚，不然會成爲一個累贅