所謂的大併發，是指QPS，大於1000,日活躍使用者量在千萬級別的業務系統。 快取就是其中的重中之重，沒有快取，分分鐘資料庫無法抗住系統壓力，直接掛了，從而影響別的業務響應。 1、把這個API介面的所有資料庫請求結果都快取起來，當然快取需要設計過期時間，在快取存在的情況下，資料庫的請求就大大減少，只有當過期的時候才會去請求一遍資料庫，採用非同步快取，快取結果是定期更新的，不會出現在過期臨界點上的響應波動。 1、記憶體快取，實際上就是一個map，封裝過後可以設定有效期，首先嚐試從cache中獲取資料，如果獲取的資料為空，則從資料庫中查詢結果，並放到快取中去。這種策略非常簡單，也非常有效。這種容易去出現的問題就是，快取剛好過期時的併發請求都會集中請求資料庫，這段時間API的響應會發生波動。 2、可以採用更復雜的多層次的快取，如Redis快取，本地快取，檔案快取相結合的快取策略。如每次介面返回的資料，做一個hash，使用一個記憶體快取來根據介面傳入的引數組合 ---->hash， 再通過hash ---->去獲取相應的資料。這一層資料都存放在Memcache中。為了避免在Memcache中key的衝突，需要在統一的入口為不同的key，加上唯一的字首，原理與java的包名體系類似。 取數時，首先引數組合，獲取hash值，然後到記憶體快取中獲取結果，如果獲取失敗，則前往Memcache中查詢結果，如果成功，更新本地快取，如果依然失敗，則只好去查詢資料庫了，查詢資料庫，得到結果後返回。如果仍然失敗，讀取本地檔案內容返回。但是，將API結果寫入檔案有一定講究，僅在API週期性更新時才寫入。 2、時刻考慮效能問題 從介面請求，到介面訪問結束，所有執行的程式碼都需要考慮能否進一步精簡，減少程式碼的執行時間消耗。同時結合1的策略，多做一些防禦措施，即使在各種出錯，失敗後，介面還是儘可能能返回結果。 3、與第三方系統互動的的優化，必須考慮到第三方的http請求是否會超時並hold請求，此時需要給對方的請求設定連線超時時間，讀寫超時時間，保護自己的程式。 4、API介面中的貼心設計，如何在移動環境下省流量 可以使用壓縮格式傳輸資料。 還可以，如果此次返回的介面資料與上次相同，則可以和接收方約定，每次請求時帶上上次返回資料的hash，服務端將介面的計算結果與上次相同，則不返回資料，直接返回請求的hash，這對於返回配置資訊的介面非常的有用，告訴請求方介面資料沒有發生變化，客戶端無需更新，使用者也省了流量。 5、與巨量使用者相關的介面，監控是必不可少的，加上效能統計模組，有問題第一時間處理。