有乙個功能，提供兩個介面，乙個是a服務查詢列表某天的資料，乙個是b服務查詢列表中單個物件某天的資料。
需要實現的效果是，
（1）呼叫a服務得到今天的資料
（2）然後再次呼叫a服務查詢昨天的資料，
（3）然後迴圈a服務獲取的資料依次呼叫b服務，查詢每個物件的其他屬性，然後獲取某個中間結果。
（4）然後根據上面的中間結果和第依次呼叫a服務的結果組裝最後結果（postlogic）。
整體的活**，大致如下：
假如服務a呼叫時間為800ms,服務b呼叫getdata的平均時間為300ms（假設10次）， 則在執行postlogic前耗時約為800ms *2 + 300ms*10=4.6s。
如果服務a的兩次請求和服務b的一次請求，服務提供方可以包裝成一次，當然效率會更高，但是無法提供。
那麼，腫麼辦？
服務a的兩次是可以非同步併發請求的，而服務b依賴於服務a的第一次請求結果，因此如果服務a兩次非同步併發請求，則理想條件下耗時為800ms。
服務b的10次也可以非同步併發請求，則伺服器b的耗時理想狀態下為300ms。
非同步方案使用執行緒池執行callable任務，返回值為future物件。
（帶返回值的非同步任務）
則postlogic之前總耗時被優化為800ms+300ms = 1.1s。
然後可以再優化，對結果進行快取，如果快取有資料直接返回，如果沒有查詢並計算後再快取。
可以使用redis，設定快取失效時間。
（典型的空間換時間）
這樣不僅第一次請求耗時盡可能縮短，而且第二次以後請求超快（10-50ms）。
我們要想想耗時的常見因素，主要是
io網路
伺服器效能
資源的建立和釋放：執行緒的建立和銷毀、連線（資料庫連線、網路連線）的建立和銷毀
轉換：字元到位元組轉換等
演算法的時間複雜度高（如多層for迴圈，而且資料量很大）
資料庫查詢條件複雜沒命中索引等
因此我們思考的角度是
將序列變為並行或併發
同步操作變異步操作
多個請求合併成乙個請求
用空間換時間
演算法時間複雜度的優化
提高機器效能（cup/記憶體/寬頻/磁碟等）
利用各種池，如資料庫連線池、快取連線池等
資料庫索引優化
乙個業務場景的優化討論
碰到這樣乙個業務場景 每個使用者訂單會有好幾個合同檔案，其中某些合同檔案需要蓋章，蓋章是有專門的蓋章服務完成的，蓋章完成後，檔案會有乙個id與之匹配。關於這樣乙個業務，研發的同學建了如下這樣一張表 create table dbo userfile id int identity 1,1 not n...
高併發業務場景下常見的解決方案
由於系統都是連線資料庫的，但是一般最多資料庫每秒只能支撐幾千的並非，如果業務量激增，會導致系統宕機 因此需要從一下幾點入手設計 系統拆分 快取 mq 分庫分表 讀寫分離 搜尋 將乙個系統進行功能拆分，如現在流行的微服務，每個服務連線的資料庫分開，分開部署。這樣可以將壓力進行拆分，緩解因為網路和資料庫...
乙個完整的SEO優化方案
乙個完整的seo優化方案主要由四個小組組成 一 前端 頁編人員 二 內容編輯人員 三 推廣人員 四 資料分析人員 接下來，我們就對這四個小組分配工作。首先，前端 頁編人員主要負責站內優化，主要從四個方面入手 合理規劃站點結構 1 扁平化結構 2 輔助導航 麵包屑導航 次導航 較快的載入速度 簡潔的頁...