本文主要根據(jù)美團(tuán)的技術(shù)博客《常見性能優(yōu)化策略的總結(jié)》整理而來。
代碼
之所以把代碼放到第一位，是因?yàn)檫@一點(diǎn)最容易引起技術(shù)人員的忽視。很多技術(shù)人員拿到一個性能優(yōu)化的需求以后，言必稱緩存、異步、JVM等。實(shí)際上，第一步就應(yīng)該是分析相關(guān)的代碼，找出相應(yīng)的瓶頸，再來考慮具體的優(yōu)化策略。有一些性能問題，完全是由于代碼寫的不合理，通過直接修改一下代碼就能解決問題的，比如for循環(huán)次數(shù)過多、作了很多無謂的條件判斷、相同邏輯重復(fù)多次等。
數(shù)據(jù)庫
數(shù)據(jù)庫的調(diào)優(yōu)，總的來說分為以下三部分：
SQL調(diào)優(yōu)
這是最常用、每一個技術(shù)人員都應(yīng)該掌握基本的SQL調(diào)優(yōu)手段（包括方法、工具、輔助系統(tǒng)等）。這里以MySQL為例，最常見的方式是，由自帶的慢查詢?nèi)罩净蛘唛_源的慢查詢系統(tǒng)定位到具體的出問題的SQL，然后使用explain、profile等工具來逐步調(diào)優(yōu)，最后經(jīng)過測試達(dá)到效果后上線。這方面的細(xì)節(jié)，可以參考MySQL索引原理及慢查詢優(yōu)化。
架構(gòu)層面的調(diào)優(yōu)
這一類調(diào)優(yōu)包括讀寫分離、多從庫負(fù)載均衡、水平和垂直分庫分表等方面，一般需要的改動較大，但是頻率沒有SQL調(diào)優(yōu)高，而且一般需要DBA來配合參與。那么什么時候需要做這些事情？我們可以通過內(nèi)部監(jiān)控報警系統(tǒng)（比如Zabbix），定期跟蹤一些指標(biāo)數(shù)據(jù)是否達(dá)到瓶頸，一旦達(dá)到瓶頸或者警戒值，就需要考慮這些事情。通常，DBA也會定期監(jiān)控這些指標(biāo)值。
連接池調(diào)優(yōu)
我們的應(yīng)用為了實(shí)現(xiàn)數(shù)據(jù)庫連接的高效獲取、對數(shù)據(jù)庫連接的限流等目的，通常會采用連接池類的方案，即每一個應(yīng)用節(jié)點(diǎn)都管理了一個到各個數(shù)據(jù)庫的連接池。隨著業(yè)務(wù)訪問量或者數(shù)據(jù)量的增長，原有的連接池參數(shù)可能不能很好地滿足需求，這個時候就需要結(jié)合當(dāng)前使用連接池的原理、具體的連接池監(jiān)控?cái)?shù)據(jù)和當(dāng)前的業(yè)務(wù)量作一個綜合的判斷，通過反復(fù)的幾次調(diào)試得到最終的調(diào)優(yōu)參數(shù)。
緩存
分類
本地緩存（HashMap/ConcurrentHashMap、Ehcache、Guava Cache等），緩存服務(wù)（Redis/Tair/Memcache等）。
使用場景
什么情況適合用緩存？考慮以下兩種場景：
- 短時間內(nèi)相同數(shù)據(jù)重復(fù)查詢多次且數(shù)據(jù)更新不頻繁，這個時候可以選擇先從緩存查詢，查詢不到再從數(shù)據(jù)庫加載并回設(shè)到緩存的方式。此種場景較適合用單機(jī)緩存。
- 高并發(fā)查詢熱點(diǎn)數(shù)據(jù)，后端數(shù)據(jù)庫不堪重負(fù)，可以用緩存來扛。
選型考慮
- 如果數(shù)據(jù)量小，并且不會頻繁地增長又清空（這會導(dǎo)致頻繁地垃圾回收），那么可以選擇本地緩存。具體的話，如果需要一些策略的支持（比如緩存滿的逐出策略），可以考慮Ehcache；如不需要，可以考慮HashMap；如需要考慮多線程并發(fā)的場景，可以考慮ConcurentHashMap。
- 其他情況，可以考慮緩存服務(wù)。目前從資源的投入度、可運(yùn)維性、是否能動態(tài)擴(kuò)容以及配套設(shè)施來考慮，我們優(yōu)先考慮Tair。除非目前Tair還不能支持的場合（比如分布式鎖、Hash類型的value），我們考慮用Redis。
設(shè)計(jì)關(guān)鍵點(diǎn)
什么時候更新緩存？如何保障更新的可靠性和實(shí)時性？
更新緩存的策略，需要具體問題具體分析。這里以門店P(guān)OI的緩存數(shù)據(jù)為例，來說明一下緩存服務(wù)型的緩存更新策略是怎樣的？目前約10萬個POI數(shù)據(jù)采用了Tair作為緩存服務(wù)，具體更新的策略有兩個：
- 接收門店變更的消息，準(zhǔn)實(shí)時更新。
- 給每一個POI緩存數(shù)據(jù)設(shè)置5分鐘的過期時間，過期后從DB加載再回設(shè)到DB。這個策略是對第一個策略的有力補(bǔ)充，解決了手動變更DB不發(fā)消息、接消息更新程序臨時出錯等問題導(dǎo)致的第一個策略失效的問題。通過這種雙保險機(jī)制，有效地保證了POI緩存數(shù)據(jù)的可靠性和實(shí)時性。
緩存是否會滿，緩存滿了怎么辦？
對于一個緩存服務(wù)，理論上來說，隨著緩存數(shù)據(jù)的日益增多，在容量有限的情況下，緩存肯定有一天會滿的。如何應(yīng)對？
① 給緩存服務(wù)，選擇合適的緩存逐出算法，比如最常見的LRU。
② 針對當(dāng)前設(shè)置的容量，設(shè)置適當(dāng)?shù)木渲?，比?0G的緩存，當(dāng)緩存數(shù)據(jù)達(dá)到8G的時候，就開始發(fā)出報警，提前排查問題或者擴(kuò)容。
③ 給一些沒有必要長期保存的key，盡量設(shè)置過期時間。
緩存是否允許丟失？丟失了怎么辦？
根據(jù)業(yè)務(wù)場景判斷，是否允許丟失。如果不允許，就需要帶持久化功能的緩存服務(wù)來支持，比如Redis或者Tair。更細(xì)節(jié)的話，可以根據(jù)業(yè)務(wù)對丟失時間的容忍度，還可以選擇更具體的持久化策略，比如Redis的RDB或者AOF。
緩存被“擊穿”問題
對于一些設(shè)置了過期時間的key，如果這些key可能會在某些時間點(diǎn)被超高并發(fā)地訪問，是一種非常“熱點(diǎn)”的數(shù)據(jù)。這個時候，需要考慮另外一個問題：緩存被“擊穿”的問題。
概念：緩存在某個時間點(diǎn)過期的時候，恰好在這個時間點(diǎn)對這個Key有大量的并發(fā)請求過來，這些請求發(fā)現(xiàn)緩存過期一般都會從后端DB加載數(shù)據(jù)并回設(shè)到緩存，這個時候大并發(fā)的請求可能會瞬間把后端DB壓垮。
-
如何解決：業(yè)界比較常用的做法，是使用mutex。簡單地來說，就是在緩存失效的時候（判斷拿出來的值為空），不是立即去load db，而是先使用緩存工具的某些帶成功操作返回值的操作（比如Redis的SETNX或者M(jìn)emcache的ADD）去set一個mutex key，當(dāng)操作返回成功時，再進(jìn)行l(wèi)oad db的操作并回設(shè)緩存；否則，就重試整個get緩存的方法。類似下面的代碼：
public String get(key) { String value = redis.get(key); if (value == null) { //代表緩存值過期 //設(shè)置3min的超時，防止del操作失敗的時候，下次緩存過期一直不能load db if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { //代表設(shè)置成功 value = db.get(key); redis.set(key, value, expire_secs); redis.del(key_mutex); } else {//這個時候代表同時候的其他線程已經(jīng)load db并回設(shè)到緩存了，這時候重試獲取緩存值即可 sleep(50); get(key); //重試 } } else { return value; } }
異步
使用場景
針對某些客戶端的請求，在服務(wù)端可能需要針對這些請求做一些附屬的事情，這些事情其實(shí)用戶并不關(guān)心或者用戶不需要立即拿到這些事情的處理結(jié)果，這種情況就比較適合用異步的方式處理這些事情。
作用
- 縮短接口響應(yīng)時間，使用戶的請求快速返回，用戶體驗(yàn)更好。
- 避免線程長時間處于運(yùn)行狀態(tài)，這樣會引起服務(wù)線程池的可用線程長時間不夠用，進(jìn)而引起線程池任務(wù)隊(duì)列長度增大，從而阻塞更多請求任務(wù)，使得更多請求得不到技術(shù)處理。
- 線程長時間處于運(yùn)行狀態(tài)，可能還會引起系統(tǒng)Load、CPU使用率、機(jī)器整體性能下降等一系列問題，甚至引發(fā)雪崩。異步的思路可以在不增加機(jī)器數(shù)和CPU數(shù)的情況下，有效解決這個問題。
常見做法
一種做法，是額外開辟線程，這里可以采用額外開辟一個線程或者使用線程池的做法，在IO線程（處理請求響應(yīng)）之外的線程來處理相應(yīng)的任務(wù)，在IO線程中讓response先返回。
如果異步線程處理的任務(wù)設(shè)計(jì)的數(shù)據(jù)量非常巨大，那么可以引入阻塞隊(duì)列BlockingQueue作進(jìn)一步的優(yōu)化。具體做法是讓一批異步線程不斷地往阻塞隊(duì)列里扔數(shù)據(jù)，然后額外起一個處理線程，循環(huán)批量從隊(duì)列里拿預(yù)設(shè)大小的一批數(shù)據(jù)，來進(jìn)行批處理（比如發(fā)一個批量的遠(yuǎn)程服務(wù)請求），這樣進(jìn)一步提高了性能。
另一種做法，是使用消息隊(duì)列（MQ）中間件服務(wù)，MQ天生就是異步的。一些額外的任務(wù)，可能不需要我這個系統(tǒng)來處理，但是需要其他系統(tǒng)來處理。這個時候可以先把它封裝成一個消息，扔到消息隊(duì)列里面，通過消息中間件的可靠性保證把消息投遞到關(guān)心它的系統(tǒng)，然后讓這個系統(tǒng)來做相應(yīng)的處理。
比如C端在完成一個提單動作以后，可能需要其它端做一系列的事情，但是這些事情的結(jié)果不會立刻對C端用戶產(chǎn)生影響，那么就可以先把C端下單的請求響應(yīng)先返回給用戶，返回之前往MQ中發(fā)一個消息即可。而且這些事情理應(yīng)不是C端的負(fù)責(zé)范圍，所以這個時候用MQ的方式，來解決這個問題最合適。
NoSQL
和緩存的區(qū)別
先說明一下，這里介紹的和緩存那一節(jié)不一樣，雖然可能會使用一樣的數(shù)據(jù)存儲方案（比如Redis或者Tair），但是使用的方式不一樣，這一節(jié)介紹的是把它作為DB來用。如果當(dāng)作DB來用，需要有效保證數(shù)據(jù)存儲方案的可用性、可靠性。
使用場景
需要結(jié)合具體的業(yè)務(wù)場景，看這塊業(yè)務(wù)涉及的數(shù)據(jù)是否適合用NoSQL來存儲，對數(shù)據(jù)的操作方式是否適合用NoSQL的方式來操作，或者是否需要用到NoSQL的一些額外特性（比如原子加減等）。
如果業(yè)務(wù)數(shù)據(jù)不需要和其他數(shù)據(jù)作關(guān)聯(lián)，不需要事務(wù)或者外鍵之類的支持，而且有可能寫入會異常頻繁，這個時候就比較適合用NoSQL（比如HBase）。
比如，美團(tuán)點(diǎn)評內(nèi)部有一個對exception做的監(jiān)控系統(tǒng)，如果在應(yīng)用系統(tǒng)發(fā)生嚴(yán)重故障的時候，可能會短時間產(chǎn)生大量exception數(shù)據(jù)，這個時候如果選用MySQL，會造成MySQL的瞬間寫壓力飆升，容易導(dǎo)致MySQL服務(wù)器的性能急劇惡化以及主從同步延遲之類的問題，這種場景就比較適合用Hbase類似的NoSQL來存儲。
JVM調(diào)優(yōu)
什么時候調(diào)？
通過監(jiān)控系統(tǒng)（如沒有現(xiàn)成的系統(tǒng)，自己做一個簡單的上報監(jiān)控的系統(tǒng)也很容易）上對一些機(jī)器關(guān)鍵指標(biāo)（gc time、gc count、各個分代的內(nèi)存大小變化、機(jī)器的Load值與CPU使用率、JVM的線程數(shù)等）的監(jiān)控報警，也可以看gc log和jstat等命令的輸出，再結(jié)合線上JVM進(jìn)程服務(wù)的一些關(guān)鍵接口的性能數(shù)據(jù)和請求體驗(yàn)，基本上就能定位出當(dāng)前的JVM是否有問題，以及是否需要調(diào)優(yōu)。
怎么調(diào)？
- 如果發(fā)現(xiàn)高峰期CPU使用率與Load值偏大，這個時候可以觀察一些JVM的thread count以及gc count（可能主要是young gc count），如果這兩個值都比以往偏大（也可以和一個歷史經(jīng)驗(yàn)值作對比），基本上可以定位是young gc頻率過高導(dǎo)致，這個時候可以通過適當(dāng)增大young區(qū)大小或者占比的方式來解決。
- 如果發(fā)現(xiàn)關(guān)鍵接口響應(yīng)時間很慢，可以結(jié)合gc time以及gc log中的stop the world的時間，看一下整個應(yīng)用的stop the world的時間是不是比較多。如果是，可能需要減少總的gc time，具體可以從減小gc的次數(shù)和減小單次gc的時間這兩個維度來考慮，一般來說，這兩個因素是一對互斥因素，我們需要根據(jù)實(shí)際的監(jiān)控?cái)?shù)據(jù)來調(diào)整相應(yīng)的參數(shù)（比如新生代與老生代比值、eden與survivor比值、MTT值、觸發(fā)cms回收的old區(qū)比率閾值等）來達(dá)到一個最優(yōu)值。
- 如果發(fā)生full gc或者old cms gc非常頻繁，通常這種情況會誘發(fā)STW的時間相應(yīng)加長，從而也會導(dǎo)致接口響應(yīng)時間變慢。這種情況，大概率是出現(xiàn)了“內(nèi)存泄露”，Java里的內(nèi)存泄露指的是一些應(yīng)該釋放的對象沒有被釋放掉（還有引用拉著它）。那么這些對象是如何產(chǎn)生的呢？為啥不會釋放呢？對應(yīng)的代碼是不是出問題了？問題的關(guān)鍵是搞明白這個，找到相應(yīng)的代碼，然后對癥下藥。所以問題的關(guān)鍵是轉(zhuǎn)化成尋找這些對象。怎么找？綜合使用jmap和MAT，基本就能定位到具體的代碼。
多線程與分布式
使用場景
離線任務(wù)、異步任務(wù)、大數(shù)據(jù)任務(wù)、耗時較長任務(wù)的運(yùn)行，適當(dāng)?shù)乩?，可達(dá)到加速的效果。
注意：線上對響應(yīng)時間要求較高的場合，盡量少用多線程，尤其是服務(wù)線程需要等待任務(wù)線程的場合（很多重大事故就是和這個息息相關(guān)），如果一定要用，可以對服務(wù)線程設(shè)置一個最大等待時間。
常見做法
如果單機(jī)的處理能力可以滿足實(shí)際業(yè)務(wù)的需求，那么盡可能地使用單機(jī)多線程的處理方式，減少復(fù)雜性；反之，則需要使用多機(jī)多線程的方式。
對于單機(jī)多線程，可以引入線程池的機(jī)制，作用有二：
- 提高性能，節(jié)省線程創(chuàng)建和銷毀的開銷
- 限流，給線程池一個固定的容量，達(dá)到這個容量值后再有任務(wù)進(jìn)來，就進(jìn)入隊(duì)列進(jìn)行排隊(duì)，保障機(jī)器極限壓力下的穩(wěn)定處理能力在使用JDK自帶的線程池時，一定要仔細(xì)理解構(gòu)造方法的各個參數(shù)的含義，如core pool size、max pool size、keepAliveTime、worker queue等，在理解的基礎(chǔ)上通過不斷地測試調(diào)整這些參數(shù)值達(dá)到最優(yōu)效果。
如果單機(jī)的處理能力不能滿足需求，這個時候需要使用多機(jī)多線程的方式。這個時候就需要一些分布式系統(tǒng)的知識了。首先就必須引入一個單獨(dú)的節(jié)點(diǎn)，作為調(diào)度器，其他的機(jī)器節(jié)點(diǎn)都作為執(zhí)行器節(jié)點(diǎn)。調(diào)度器來負(fù)責(zé)拆分任務(wù)，和分發(fā)任務(wù)到合適的執(zhí)行器節(jié)點(diǎn)；執(zhí)行器節(jié)點(diǎn)按照多線程的方式（也可能是單線程）來執(zhí)行任務(wù)。這個時候，我們整個任務(wù)系統(tǒng)就由單擊演變成一個集群的系統(tǒng)，而且不同的機(jī)器節(jié)點(diǎn)有不同的角色，各司其職，各個節(jié)點(diǎn)之間還有交互。這個時候除了有多線程、線程池等機(jī)制，像RPC、心跳等網(wǎng)絡(luò)通信調(diào)用的機(jī)制也不可少。后續(xù)我會出一個簡單的分布式調(diào)度運(yùn)行的框架。
度量系統(tǒng)（監(jiān)控、報警、服務(wù)依賴管理）
嚴(yán)格來說，度量系統(tǒng)不屬于性能優(yōu)化的范疇，但是這方面和性能優(yōu)化息息相關(guān)，可以說為性能優(yōu)化提供一個強(qiáng)有力的數(shù)據(jù)參考和支撐。沒有度量系統(tǒng)，基本上就沒有辦法定位到系統(tǒng)的問題，也沒有辦法有效衡量優(yōu)化后的效果。很多人不重視這方面，但我認(rèn)為它是系統(tǒng)穩(wěn)定性和性能保障的基石。
關(guān)鍵流程
如果要設(shè)計(jì)這套系統(tǒng)，總體來說有哪些關(guān)鍵流程需要設(shè)計(jì)呢？
① 確定指標(biāo)
② 采集數(shù)據(jù)
③ 計(jì)算數(shù)據(jù)，存儲結(jié)果
④ 展現(xiàn)和分析
需要監(jiān)控和報警哪些指標(biāo)數(shù)據(jù)？需要關(guān)注哪些？
按照需求出發(fā)，主要需要二方面的指標(biāo)：
- 接口性能相關(guān)，包括單個接口和全部的QPS、響應(yīng)時間、調(diào)用量（統(tǒng)計(jì)時間維度越細(xì)越好；最好是，既能以節(jié)點(diǎn)為維度，也可以以服務(wù)集群為維度，來查看相關(guān)數(shù)據(jù)）。其中還涉及到服務(wù)依賴關(guān)系的管理，這個時候需要用到服務(wù)依賴管理系統(tǒng)
- 單個機(jī)器節(jié)點(diǎn)相關(guān)，包括CPU使用率、Load值、內(nèi)存占用率、網(wǎng)卡流量等。如果節(jié)點(diǎn)是一些特殊類型的服務(wù)（比如MySQL、Redis、Tair），還可以監(jiān)控這些服務(wù)特有的一些關(guān)鍵指標(biāo)。
數(shù)據(jù)采集方式
通常采用異步上報的方式，具體做法有兩種：第一種，發(fā)到本地的Flume端口，由Flume進(jìn)程收集到遠(yuǎn)程的Hadoop集群或者Storm集群來進(jìn)行運(yùn)算；第二種，直接在本地運(yùn)算好以后，使用異步和本地隊(duì)列的方式，發(fā)送到監(jiān)控服務(wù)器。
數(shù)據(jù)計(jì)算
可以采用離線運(yùn)算（MapReduce/Hive）或者實(shí)時/準(zhǔn)實(shí)時運(yùn)算（Storm/Spark）的方式，運(yùn)算后的結(jié)果存入MySQL或者HBase；某些情況，也可以不計(jì)算，直接采集發(fā)往監(jiān)控服務(wù)器。
展現(xiàn)和分析
提供統(tǒng)一的展現(xiàn)分析平臺，需要帶報表（列表/圖表）監(jiān)控和報警的功能。
